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: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:119500:950530152717"@cl.cam.ac.uk>
i willl be at EuorTeX, the dear willing, and can TDSize if no-one
elsse does.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 May 1995 12:57:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 30 May 1995 13:56:59 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505301756.NAA19735@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: 0.78 comments
Reply-To: TWG-TDS@SHSU.edu
> Implementations can store implementation-specific files
>
> Implementations => Sites
Check.
> latter (directory-based) scheme
>
> Suggest deleting `(directory-based)'.
Check.
> an effort to determine
>
> an => the
Check.
Moving to version 0.98 and going public (without announcement yet).
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, 30 May 1995 13:01:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 30 May 1995 14:00:13 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505301800.OAA19764@jasper.ora.com>
To: David Aspinall <da@dcs.ed.ac.uk>
CC: TWG-TDS@SHSU.edu
Subject: Comments on TeX directory structure
Reply-To: TWG-TDS@SHSU.edu
David,
Your comments are very much appreciated. However, there will be no more
significant changes to the document before the first public release.
We will review your suggestions as soon as possible.
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, 31 May 1995 03:45:42 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: da@dcs.ed.ac.uk
Subject: Re: Comments on TeX directory structure
Date: Wed, 31 May 1995 09:43:38 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:232320:950531084401"@cl.cam.ac.uk>
I'd concur with David that reserving "local" is a good idea; and i'd
assumed that bst files would have a package structure too.
but your cs*.cls/sty should be a package called edinbcs, IMHO
>
> 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).
an interesting question. it should be addressed in the documenattion
for the new psfonts (have you seen fonts/psfonts.beta?). i'd propose
tex/latex/psfonts/<supplier>/<font> to mimic exactly the distribution
names. does that hit too many directory levels? unless Karl disagrees,
i'll document this somewhere. PSNFSS is a package of itself, as it
combines various fonts in one style file.
> (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
people can abuse anything. you cant *not* have a misc...
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 31 May 1995 05:09: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: <199505311003.MAA14101@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Comments on TeX directory structure
To: TWG-TDS@SHSU.edu
Date: Wed, 31 May 1995 12:03:31 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> (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 ...)
After the public review release, our new versions will be available as
CTAN:tds/working-paper/, to distinguish it from CTAN:tds/draft/ where
the version advertised for public review will stay.
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, 31 May 1995 05:13:54 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505311003.MAA14101@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Comments on TeX directory structure
To: TWG-TDS@SHSU.edu
Date: Wed, 31 May 1995 12:03:31 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> (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 ...)
After the public review release, our new versions will be available as
CTAN:tds/working-paper/, to distinguish it from CTAN:tds/draft/ where
the version advertised for public review will stay.
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, 31 May 1995 07:58:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 31 May 1995 08:57:41 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Comments on TeX directory structure
To: TWG-TDS@SHSU.edu
Message-ID: <801925061.61839.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
i'd like to second karl's suggestion for a tds.additions file, or
something like it.
actually, maybe tds.suggestions might be better -- it could list
suggestions with a brief comment about whether the item is new, is
planned for inclusion, or had been discussed previously and rejected.
i also like the idea of a specific "local" level -- first item in
the supplementary file?
-- bb
================================================================================
From owner-twg-tds@shsu.edu Wed, 31 May 1995 09:16:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 31 May 1995 10:16:03 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505311416.AA29055@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Comments on TeX directory structure
After the public review release, our new versions will be available as
CTAN:tds/working-paper/, to distinguish it from CTAN:tds/draft/ where
As a user, I would never guess that `draft' is more public than
`working-paper'.
I suggest tds/public-review-version and tds/working-drafts, or something
equally unequivocal.
Actually, I think I'd suggest the drafts don't go on CTAN at all,
but just on jasper.
================================================================================
From owner-twg-tds@shsu.edu Wed, 31 May 1995 09:18:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 31 May 1995 10:18:07 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505311418.AA29067@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Comments on TeX directory structure
tex/latex/psfonts/<supplier>/<font> to mimic exactly the distribution
names. does that hit too many directory levels? unless Karl disagrees,
*I* don't disagree, but I seem to remember latex folk preferring
other arrangements. I don't remember the details any more, and I'm too
worn out to look it up in the archives ...
From owner-twg-tds@shsu.edu Thu, 01 Jun 1995 08:14:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 1 Jun 1995 09:14:02 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199506011314.JAA19728@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: CTAN:/tds organization (YIKES!)
Reply-To: TWG-TDS@SHSU.edu
>
> After the public review release, our new versions will be available as
> CTAN:tds/working-paper/, to distinguish it from CTAN:tds/draft/ where
>
> As a user, I would never guess that `draft' is more public than
> `working-paper'.
>
> I suggest tds/public-review-version and tds/working-drafts, or something
> equally unequivocal.
>
> Actually, I think I'd suggest the drafts don't go on CTAN at all,
> but just on jasper.
I agree. Actually, I just looked at /tds on CTAN for the first time and
I'm a little disturbed by the volume of material. I think it's too confusing.
I'd like to recommend a sweeping reorganization of that area:
IMHO,
/tds/draft-standard should be a mirror of ftp://jasper.ora.com/pub/twg-tds
/tds/supplementary-materials should contain everything else (i.e., everything
that is currently in the /tds tree).
/tds/README should be a symlink to draft-standard/README
/tds/ANNOUNCE should be a symlink to draft-standard/ANNOUNCE
And let's get rid of the SGML files and other old versions and stuff that
are currently in /tds (and would go in /tds/supplementary-materials under
my scheme).
Comments?
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, 01 Jun 1995 08:15:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 1 Jun 1995 09:15:29 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199506011315.JAA19751@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Draft Standard 0.98 available publically
Reply-To: TWG-TDS@SHSU.edu
Folks,
I've installed the draft standard 0.98 in the "public" places on jasper:
ftp://jasper.ora.com/pub/twg-tds
and
http://jasper.ora.com/twg-tds
If no one finds errors in these files, I'll make the public announcement
on Monday morning.
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 Thu, 01 Jun 1995 18:15:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 1 Jun 1995 19:13:41 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506012313.AA29138@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: CTAN:/tds organization (YIKES!)
/tds/draft-standard should be a mirror of ftp://jasper.ora.com/pub/twg-tds
/tds/supplementary-materials should contain everything else (i.e., everything
that is currently in the /tds tree).
/tds/README should be a symlink to draft-standard/README
/tds/ANNOUNCE should be a symlink to draft-standard/ANNOUNCE
Comments?
Sounds good to me.
> Actually, I think I'd suggest the drafts don't go on CTAN at all,
> but just on jasper.
I agree.
I think doing this (keeping the commitee-only drafts only on jasper)
will do a lot to reduce confusion. I really hope this is how it ends up.
================================================================================
From owner-twg-tds@shsu.edu Thu, 01 Jun 1995 18:44: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: <199506012343.BAA16261@spock.iti.informatik.th-darmstadt.de>
Subject: Re: CTAN:/tds organization (YIKES!)
To: TWG-TDS@SHSU.edu
Date: Fri, 2 Jun 1995 01:43:18 +0200 (MESZ)
Content-Type: text
Norm wrote:
>
> I agree. Actually, I just looked at /tds on CTAN for the first time and
> I'm a little disturbed by the volume of material. I think it's too confusing.
The CTAN team can simply exclude tds/*archive* from mirroring, then
all the material you find confusing is gone.
But I want to mention that
-- I received quite some mails in the past week that told me that
they would like to see even more examples than those currently in
tds/archives/. Noone mentioned that it was too confusing.
-- I think it's important to have a backlog of old working papers
to be able to tell people about the history of our work. (More on
this below.)
> /tds/draft-standard should be a mirror of ftp://jasper.ora.com/pub/twg-tds
> /tds/supplementary-materials should contain everything else (i.e., everything
> that is currently in the /tds tree).
The CTAN team has to select the directory where they mirror my files
to, they can also stop to mirror them at all. I don't have any
problem with that, I will provide them on my ftp server anyhow. (With
currently 12 GB, ftp.th-darmstadt.de is one of the larger German
servers; the few megabytes do not matter.)
> /tds/README should be a symlink to draft-standard/README
On my ftp server, I would not do this. A README has to tell about
contents and structure of a respective subtree, to support (human)
clients that browse the archive. The README in draft-standard will
tell about the draft standard, not about the whole tds/ tree. If the
whole tds/ subtree has only the draft standard, one does not need
that subdirectory at all.
Of course, the CTAN team is free to think otherwise.
> /tds/ANNOUNCE should be a symlink to draft-standard/ANNOUNCE
That's a very good idea, OTOH.
> And let's get rid of the SGML files and other old versions and stuff that
> are currently in /tds
ftp.th-darmstadt.de:pub/tex/tds/draft/ is a direct (daily) mirror of
jasper.ora.com. If you delete the SGML files there, they will get
deleted here the next day.
As explained above, I think the drafts archive is very valuable, much
too many documents suffer from the fact that no proper history is
available for them.
In fact, when I come around to do it, I would even like to add
the complete mailing list backlog. IMHO, that's one of the most
important lessons we can learn from the TeX project: It's important
to have a good project diary, a backlog of decisions, and a
repository with old revisions. (The first two are available, and the
last is often badly missing.)
You've read the mail we recently received -- the one that puts up
lots of our old topics again? That's because the draft does not
mention the history of decisions, as standards usually do. IMO, the
mailing list backlog and draft archives are at least a small bit of a
working group memory.
Joachim
PS: I'm about to leave, and will not have Email connection until
Wednesday morning. We're going sailing for the next four days, and
won't have an Internet connection on our boat. ;-) So don't expect
further reactions from me, decide as you wish.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 02 Jun 1995 11:31:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 2 Jun 1995 09:29:37 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506021329.AA26035@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: CTAN:/tds organization (YIKES!)
As explained above, I think the drafts archive is very valuable, much
Archiving *past* drafts on CTAN:tds seems valuable.
(In a clearly-marked `past-drafts/' or some such directory.)
It's *future* drafts, that we are just messing around with,
that I don't think should appear on CTAN 24 hours after Norm releases one.
When we make the next public release, all the previous drafts can be put
in CTAN again (as past drafts). And so on. It's pretty trivial -- store
tds.tex in an RCS file.
In fact, when I come around to do it, I would even like to add
the complete mailing list backlog. IMHO, that's one of the most
I agree.
important lessons we can learn from the TeX project: It's important
to have a good project diary, a backlog of decisions, and a
repository with old revisions. (The first two are available, and the
last is often badly missing.)
Did anyone (Norm?) save the different drafts as they came out? I didn't.
You've read the mail we recently received -- the one that puts up
lots of our old topics again? That's because the draft does not
mention the history of decisions, as standards usually do. IMO, the
We have some rationale in there now. I'm not opposed to adding more;
especially in response to reader questions about why such-and-such is
like it is.
A simple ChangeLog for the tds directory would help.
Norm, did you keep anything like that?
================================================================================
From owner-twg-tds@shsu.edu Fri, 02 Jun 1995 15:31:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 2 Jun 1995 09:29:37 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506021329.AA26035@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: CTAN:/tds organization (YIKES!)
As explained above, I think the drafts archive is very valuable, much
Archiving *past* drafts on CTAN:tds seems valuable.
(In a clearly-marked `past-drafts/' or some such directory.)
It's *future* drafts, that we are just messing around with,
that I don't think should appear on CTAN 24 hours after Norm releases one.
When we make the next public release, all the previous drafts can be put
in CTAN again (as past drafts). And so on. It's pretty trivial -- store
tds.tex in an RCS file.
In fact, when I come around to do it, I would even like to add
the complete mailing list backlog. IMHO, that's one of the most
I agree.
important lessons we can learn from the TeX project: It's important
to have a good project diary, a backlog of decisions, and a
repository with old revisions. (The first two are available, and the
last is often badly missing.)
Did anyone (Norm?) save the different drafts as they came out? I didn't.
You've read the mail we recently received -- the one that puts up
lots of our old topics again? That's because the draft does not
mention the history of decisions, as standards usually do. IMO, the
We have some rationale in there now. I'm not opposed to adding more;
especially in response to reader questions about why such-and-such is
like it is.
A simple ChangeLog for the tds directory would help.
Norm, did you keep anything like that?
================================================================================
From owner-twg-tds@shsu.edu Sat, 03 Jun 1995 23:17:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 03 Jun 95 14:26:30 SET
From: GOOSSENS@CERNVM.cern.ch
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: TDS on CTAN
To: TWG-TDS@SHSU.edu
On Tue, 30 May 1995 16:23:38 +0200 (MESZ) Joachim Schrod said:
>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
>
Thanks, Joachim, so I shall write down your name as "rapporteur" of the
tds effort. It would be nice that you (together with your collaborators)
could write a few pages (or an extended abstract, since you have your
reference document) explaining the WG's work. Deadline: end of June (I shall
henceforth only contact Joachim about technical details relating to his
presentation at Papendaal). Sincerely, Michel Goossens
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
>Computer Science Department
>Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 06 Jun 1995 19:11:58 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506070011.CAA21376@spock.iti.informatik.th-darmstadt.de>
Subject: Re: CTAN:/tds organization (YIKES!)
To: TWG-TDS@SHSU.edu
Date: Wed, 7 Jun 1995 02:11:40 +0200 (MESZ)
Content-Type: text
You wrote:
>
> As explained above, I think the drafts archive is very valuable, much
>
> Archiving *past* drafts on CTAN:tds seems valuable.
That's the stuff that's currently available on CTAN. It's the stuff
that Norm said it should be deleted in his opinion.
> Did anyone (Norm?) save the different drafts as they came out? I didn't.
All drafts released by Norm are on CTAN. I attach a list below. The
new one has not been copied to the archive yet, I've just returned
from my sailing trip (literally).
Joachim
----------------
total 5482
-rw-rw-r-- 1 3001 102 25455 Feb 26 22:27 tds-0.3-940721.tar.gz
-rw-rw-r-- 1 3001 102 515674 Feb 26 22:27 tds-0.49-941010.tar.gz
-rw-rw-r-- 1 3001 102 95279 Feb 26 22:27 tds-0.50-941118.tar.gz
-rw-rw-r-- 1 3001 102 95331 Feb 26 22:27 tds-0.60-950201.tar.gz
-rw-rw-r-- 1 3001 102 97500 Feb 26 22:27 tds-0.61-950202.tar.gz
-rw-rw-r-- 1 3001 102 97355 Feb 26 22:32 tds-0.61-950210.tar.gz
-rw-rw-r-- 1 3001 102 99313 Mar 3 18:37 tds-0.62-950302.tar.gz
-rw-rw-r-- 1 3001 102 115299 Mar 9 12:27 tds-0.64-950308.tar.gz
-rw-rw-r-- 1 3001 102 118319 Mar 11 19:14 tds-0.66-950310.tar.gz
-rw-rw-r-- 1 3001 102 133856 Mar 16 12:15 tds-0.67-950315.tar.gz
-rw-rw-r-- 1 3001 102 133529 Mar 17 17:20 tds-0.68-950316.tar.gz
-rw-rw-r-- 1 3001 102 185239 Mar 22 17:33 tds-0.69-950321.tar.gz
-rw-rw-r-- 1 3001 102 177384 Mar 30 16:16 tds-0.70-950328.tar.gz
-rw-rw-r-- 1 3001 102 143590 Apr 14 15:11 tds-0.71-950413.tar.gz
-rw-rw-r-- 1 3001 102 145025 May 8 16:55 tds-0.72-950505.tar.gz
-rw-rw-r-- 1 3001 102 104487 May 13 16:47 tds-0.74-950512.tar.gz
-rw-rw-r-- 1 3001 102 135400 May 17 12:52 tds-0.75-950516.tar.gz
-rw-rw-r-- 1 3001 102 134388 May 18 18:16 tds-0.76-950518.tar.gz
-rw-rw-r-- 1 3001 102 140689 May 19 09:36 tds-0.77-950518.tar.gz
-rw-rw-r-- 1 3001 102 101839 May 26 12:19 tds-0.78-950525.tar.gz
----------------
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 13 Jun 1995 14:27:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 13 Jun 1995 15:22:01 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199506131922.PAA16088@jasper.ora.com>
To: texhax@tex.ac.uk, info-tex@shsu.edu, tex-archive@math.utah.edu, tex-implementors@math.ams.org
CC: twg-tds@shsu.edu
Subject: Announcing: TWG-TDS Draft Standard 0.98
Reply-To: TWG-TDS@SHSU.edu
The TUG Technical Working Group on a TeX Directory Structure is
pleased to announce that 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-standard/
(The `/tex-archive' may vary; see the end of this message for a list of
possible hosts.)
The draft standard is available in LaTeX, PostScript, TeXinfo, HTML,
and SGML formats.
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
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 Tue, 13 Jun 1995 19:23:00 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Tue, 13 Jun 1995 17:23:12 -0700
Message-ID: <199506140023.RAA15688@tashkent.berkeley.edu>
To: twg-tds@shsu.edu
Subject: TWG-TDS: some minor nits
I have a few comments about the TDS copy I got from SHSU today.
1. In tds.dvi, the table of contents is a blank page.
2. I tried to re-LaTeX tds.dvi, but couldn't because I could not find the
file tdsguide.cls, either on CTAN or in a limited search on jasper.
3. Bottom of page 3: "{\tt command} Commands are typeset in italics."
Shouldn't either \tt be changed to \it or italics be changed to typewriter
type?
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Jun 1995 03:08:49 CDT
Sender: owner-twg-tds@SHSU.edu
From: Bernard GAULLE <gaulle@idris.fr>
Reply-To: TWG-TDS@SHSU.edu
Date: Wed, 14 Jun 1995 10:08:53 +0200
Message-ID: <199506140808.KAA03873@murnau.idris.fr>
To: twg-tds@shsu.edu
Subject: Printer resolution
As far as i understood correctly the draft on TDS, i think that there
could be at least one problem in the future, due to the lack of no
printer resolution directory level. By now few PostScript printers can
work at various resolution, eg 300 and 600dpi, and obviously PK files
aren't the same:
????
texmf/fonts/pk/public/cm/r300/dpi300/cmr10.300pk
texmf/fonts/pk/public/cm/r600/dpi300/cmr10.300pk
????
And there is a strong probability that such facilities were
generalized by manufacturers in the next future.
Any solution?
--bg
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Jun 1995 03:18:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Jun 1995 10:20:57 +0200
From: Thomas Herter <Thomas.Herter@mch.sni.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506140820.KAA11106@pgtd0143.mch.sni.de>
To: info-tex@SHSU.edu, tex-archive@math.utah.edu, tex-implementors@math.ams.org, texhax@tex.ac.uk
CC: twg-tds@SHSU.edu
Subject: Re: Announcing: TWG-TDS Draft Standard 0.98
Content-Type: text
w> The TUG Technical Working Group on a TeX Directory Structure is
w> pleased to announce that a draft of the proposed TeX Directory
w> Structure standard is available for public review. You can get it by
w> FTP from:
w>
w> <CTAN host>:/tex-archive/tds/draft-standard/
Hallo Norman,
please note, that the file tdsguide.cls is missing in the tds/draft-standard/latex
subdirectory. Moreover, I can not find this file in the whole tds tree.
I think, I would be correct to provide this class file with the LaTeX source.
Thomas.
--
Thomas Herter email: thomas.herter@mch.sni.de
+89 636-49973 100275.541@compuserve.com
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Jun 1995 05: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: <199506141005.MAA24028@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Printer resolution
To: TWG-TDS@SHSU.edu
Date: Wed, 14 Jun 1995 12:05:20 +0200 (MESZ)
CC: gaulle@idris.fr
Content-Type: text
Beranrd wrote:
>
> As far as i understood correctly the draft on TDS, i think that there
> could be at least one problem in the future, due to the lack of no
> printer resolution directory level. [...]
It's in the mode name.
>
> texmf/fonts/pk/public/cm/r300/dpi300/cmr10.300pk
That's not a valid TDS name.
texmf/fonts/pk/cx/public/cm/dpi300/cmr10.pk
^^
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Jun 1995 05:40:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Jun 1995 11:40:36 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: gaulle@idris.fr, CHAA006@vms.rhbnc.ac.uk
Message-ID: <950614114036.2020341b@vms.rhbnc.ac.uk>
Subject: RE: Printer resolution
Dear Bernard --
Although not a member of TWG-TDS (merely an interested observer and
occasional contributor), I was interested yet puzzled by your recent comment:
>> As far as i understood correctly the draft on TDS, i think that there
>> could be at least one problem in the future, due to the lack of no
>> printer resolution directory level. By now few PostScript printers can
>> work at various resolution, eg 300 and 600dpi, and obviously PK files
>> aren't the same:
Firstly, if one is using a PostScript printer, presumably one is also using
the BaKoMa outline renditions of Computer Modern rather than PK-format
bitmaps? Secondly, it is not at all clear to me why it is obvious that
``PK files aren't the same'' when you cite as example:
>> ????
>> texmf/fonts/pk/public/cm/r300/dpi300/cmr10.300pk
>> texmf/fonts/pk/public/cm/r600/dpi300/cmr10.300pk
>> ????
Are you really suggesting that there should be two different versions of
CMR10.300PK, one for use at 300dpi and one at 600dpi for one and the same
printer? If you are, then (a) the CMR10.300PK when used at 600dpi will
be used only if the user asks for CMR10 scaled 500 (an unusual request),
and (b) even if he/she does ask for such a reduced size, it is not at all
clear to my why the `standard' CMR10.300PK for that printer (i.e. the 300dpi
version) will be any different to a custom 600dpi version scaled 500. The
MetaFont book, if I read it correctly, suggests that the two will be identical.
I am sure I am missing your point, but then perhaps so are many other readers,
so perhaps I could ask you to clarify?
Very best wishes,
* Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Jun 1995 05:55:00 CDT
Sender: owner-twg-tds@SHSU.edu
From: Bernard GAULLE <gaulle@idris.fr>
Reply-To: TWG-TDS@SHSU.edu
Date: Wed, 14 Jun 1995 12:53:55 +0200
Message-ID: <199506141053.MAA04440@murnau.idris.fr>
To: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
CC: TWG-TDS@SHSU.edu
Subject: Re: Printer resolution
>>>>> On Wed, 14 Jun 1995 12:05:20 +0200 (MESZ),
>>>>> Joachim Schrod <schrod@iti.informatik.th-darmstadt.de> write about "Re: Printer resolution":
JS> Beranrd wrote:
>
> As far as i understood correctly the draft on TDS, i think that there
> could be at least one problem in the future, due to the lack of no
> printer resolution directory level. [...]
JS> It's in the mode name.
JS> texmf/fonts/pk/cx/public/cm/dpi300/cmr10.pk
JS> ^^
Let's imagine you are using various device resolutions in the
same document, how could you specify that in order that your
MakeTeXPK shell run with the appropriate mode name, ie
device resolution ?
Phil's opinion "The MetaFont book, if I read it correctly, suggests that
the two will be identical" let me in a puzzled state. I wonder...
--bg
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Jun 1995 06:52:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Jun 1995 07:51:51 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506141151.AA06227@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu, gaulle@idris.fr
Subject: Re: Printer resolution
Let's imagine you are using various device resolutions in the
same document, how could you specify that in order that your
MakeTeXPK shell run with the appropriate mode name, ie
device resolution ?
Any given run of your dvi driver must have one and only one target
resolution. This is a logical necessity, so far as I can see. I don't
understand how it can be meaningful to generate a document for more than
one device at a time.
I think Joachim said it all: it's in the mode name.
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Jun 1995 06:59:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Jun 1995 12:58: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: <950614125856.20203302@vms.rhbnc.ac.uk>
Subject: Re: Printer resolution
>> Phil's opinion "The MetaFont book, if I read it correctly, suggests that
>> the two will be identical" let me in a puzzled state. I wonder...
OK, let me clarify: do we first of all agree that the three tuning parameters,
{blacker, fillin & o_correction} will be the same for the same rendering
engine regardless of resolution: that, for example, a hypothetical LaserJet V
with available resolutions of 300, 600 & 1200 dpi will need three mode_defs,
but the only difference between them will be the pixels_per_inch? If we
don't agree here, then it is clear why you might want two different versions
of CMR10.300PK for one and the same printer; if, however, we _do_ agree,
then the MetaFont book makes it plain that these three incantations will
generate identical versions of CMR10.300GF:
$ metafont \mode=ljvthreehundredppi; mag=1; input cmr10
$ metafont \mode=ljvsixhundredppi; mag=0.5; input cmr10
$ metafont \mode=ljvtwelvehundredppi; mag=0.25; input cmr10
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Jun 1995 07:13:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Jun 1995 08:11:31 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199506141211.IAA07412@jasper.ora.com>
To: texhax@tex.ac.uk, info-tex@SHSU.edu, tex-archive@math.utah.edu, tex-implementors@math.ams.org
CC: twg-tds@SHSU.edu
Subject: TWG-TDS: some minor nits
Reply-To: TWG-TDS@SHSU.edu
> From: vojta@math.berkeley.edu (Paul Vojta)
> Date: Tue, 13 Jun 1995 17:23:12 -0700
>
> I have a few comments about the TDS copy I got from SHSU today.
>
> 1. In tds.dvi, the table of contents is a blank page.
Fixed.
> 2. I tried to re-LaTeX tds.dvi, but couldn't because I could not find the
> file tdsguide.cls, either on CTAN or in a limited search on jasper.
Fixed. I added these files. (Joachim, if you have a more recent version
please let me know.)
> 3. Bottom of page 3: "{\tt command} Commands are typeset in italics."
> Shouldn't either \tt be changed to \it or italics be changed to typewriter
> type?
Yes. That will be corrected in the next draft.
Thanks, Paul.
These fixes are available immediately from ftp://jasper.ora.com/pub/twg-tds
They will be available from CTAN within a day or so.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The First Amendment is often inconvenient. But
Production Tools Specialist | that is besides the point. Inconvenience does
O'Reilly & Associates, Inc. | not absolve the government of its obligation to
90 Sherman Street | tolerate speech." -- Justice Anthony Kennedy, in
Cambridge, MA 02140 | 91-155
(617) 354-5800/661-1116 FAX |
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Jun 1995 07:15: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: <199506141015.MAA18431@spice.iti.informatik.th-darmstadt.de>
Subject: Re: TWG-TDS: some minor nits
To: TWG-TDS@SHSU.edu
Date: Wed, 14 Jun 1995 12:15:30 +0200 (MESZ)
CC: vojta@math.berkeley.edu
Content-Type: text
Paul wrote:
>
> 2. I tried to re-LaTeX tds.dvi, but couldn't because I could not find the
> file tdsguide.cls, either on CTAN or in a limited search on jasper.
As tds/README tells, the macros are in tds/misc/, in tdsguide-1.1.tar.gz.
An unpacked version of this tar file will be provided RSN, for the
convenience of those who search the class file by name.
Actually, it was planned that latex/tds.tex should be self-contained,
but this plan was dropped somewhere on the way.
Cheers,
Joachim
PS: Don't get me wrong, but it's quite common nowadays that one has
to use the base name of a style file to find it on CTAN.
PPS: TDS folks: I sent a respective mail privately to Thomas Herter,
too.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Jun 1995 09:36: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: <199506141425.QAA01680@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Printer resolution
To: TWG-TDS@SHSU.edu
Date: Wed, 14 Jun 1995 16:25:09 +0200 (MESZ)
Content-Type: text
Phil wrote:
>
> OK, let me clarify: do we first of all agree that the three tuning parameters,
> {blacker, fillin & o_correction} will be the same for the same rendering
> engine regardless of resolution: that, for example, a hypothetical LaserJet V
> with available resolutions of 300, 600 & 1200 dpi will need three mode_defs,
> but the only difference between them will be the pixels_per_inch?
No. For instance, concerning HP LaserJet 4:
mode_def cx = % Canon CX, SX, LBP-LX
mode_param (pixels_per_inch, 300);
mode_param (blacker, 0);
mode_param (fillin, .2);
mode_param (o_correction, .6);
mode_common_setup_;
enddef;
mode_def ljfour = % 600dpi HP LaserJet 4
mode_param (pixels_per_inch, 600);
mode_param (blacker, .25);
mode_param (fillin, 0);
mode_param (o_correction, 1);
mode_common_setup_;
enddef;
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Jun 1995 09:42: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: <199506141125.NAA22782@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Printer resolution
To: gaulle@idris.fr (Bernard GAULLE)
Date: Wed, 14 Jun 1995 13:25:54 +0200 (MESZ)
CC: schrod@iti.informatik.th-darmstadt.de, TWG-TDS@SHSU.edu
Content-Type: text
Bernard wrote:
>
> Let's imagine you are using various device resolutions in the
> same document,
???? Sorry, but I cannot parse that sentence.
I can't use various device resolutions in one document. (I can use
different magnifications, but that's another topic, cared for by the
dpiXXX/ directories.) That's because one uses one modedef, and the
device resolution is part of that modedef. MakeTeXPK gets the modedef
from the driver, btw.
Perhaps I wasn't clear enough in my first message. Yes, there exist
devices with two resolutions, most notably HP LJ 4s and many impact
printers. For each resolution a different modedef must be used. (That
is not something we invented, that's basic METAFONT functionality.)
As the modedef is part of the full file name, the device resolution
is part of it, too.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Jun 1995 11:08:53 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506141132.NAA21785@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Printer resolution
To: TWG-TDS@SHSU.edu
Date: Wed, 14 Jun 1995 13:32:22 +0200 (MESZ)
Content-Type: text
Phil wrote:
>
> Are you really suggesting that there should be two different versions of
> CMR10.300PK, one for use at 300dpi and one at 600dpi for one and the same
> printer?
Yes, Phil, there are.
E.g., one for the modedef cx, and one for the modedef ljfour. Due to
blacker (&c) differences, they might be even different. After all,
the device may (will?) render differently in 300dpi & 600dpi, too.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 14 Jun 1995 12:24:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Jun 1995 18:25:00 +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: <950614182500.20203081@vms.rhbnc.ac.uk>
Subject: Re: Printer resolution
>> E.g., one for the modedef cx, and one for the modedef ljfour. Due to
>> blacker (&c) differences, they might be even different. After all,
>> the device may (will?) render differently in 300dpi & 600dpi, too.
Ah well, I stand corrected. Whilst I was prepared to believe that in
principle one might need different mode defs, I am surprised to learn
that there really is a printer on which such subtle differences can
be observed.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Jun 1995 16:48:40 CDT
Sender: owner-twg-tds@SHSU.edu
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
Reply-To: TWG-TDS@SHSU.edu
Date: Thu, 15 Jun 1995 15:26:19 -0600
To: twg-tds@shsu.edu
CC: beebe@math.utah.edu
Subject: Remarks on ``A Directory Structure for TeX Files 0.98''
Message-ID: <CMM.0.91.0.803251579.beebe@plot79.math.utah.edu>
On p. 1, Introduction, paragraph 2, mention should be made of Windows NT
(it is mentioned later on).
On p. 10, end of section 4.1, it should be noted that dpi == dots per inch.
Too bad the US remains the only nation in the world using that obsolete
system of units.
On p. 10, section 4.1.1 and p. 17, section A.3, mention is made of
a filename cache. I've had such a cache implemented in my (still
unreleased) DVI driver family 3.0 since March 1992 and find that
it works quite well. The cache file is simple: just a list of
file names (mostly fonts) like this:
/usr/local/lib/tex/ams/amsfonts/pk-files/300dpi/cmbsy5.300pk
...
/usr/local/lib/tex/musictex/tfm/sluruu16.tfm
For convenience, TeX and UNIX shell style comments are supported. On
our systems, this file is about 4390 lines (208KB of file) in the
current version, covering all of our installed font files.
The final component acts as the key in a hash table lookup, and
provided the cache file is sorted, only one copy is made of the
directory path. Consequently, for our cache file, the amount of
memory required for filename strings is about 56KB, and for the hash
table itself, about 41KB, for a total of under 100KB, which is modest
in the workstation world.
Tests have shown that the time to read the cache file and internalize
it is well under a second; the contents can be tuned to local needs,
e.g. shortened to reduce internal memory use, and speed startup.
Every file open (other than for the cache file itself, and for startup
configuration files, because they might alter the cache file location)
goes through the cache algorithm:
(1) if the file is found in the cache, and can be opened
successfully, return success
(2) if the file is found in the cache, but cannot be opened,
issue a warning message about a stale cache, and go to (3)
(3) revert to directory path search
One disadvantage is that in order for the user to override the cached
location of a file, in order to provide a private replacement, s/he
must provide a modified (or empty) cache file, because the directory
order in the search path has no effect on a cache lookup. A
command-line option to the DVI driver program could do this as well,
but so far, the need has been infrequent. However, this is LESS
likely to be the case for TeX itself, since users often have modified
versions of system macro files, but rarely do for font files.
The warning message in (2) has proved to be important, because some of
our users port a portion of our TeX tree to off-campus machines,
possibly invalidating the cache.
A second disadvantage is that the 8+3 DOS filename length limitation
that led to the adoption in the TWG-TDS proposal of the
dpi300/cmr10.pk name flavor over cmr10.300pk conflicts with use of the
base filename as a key; solutions are to retain both flavors in the
tree, as proposal suggests, or to add a hack (ugh...) to my generic
file cache support code to build in knowledge of the equivalence of
dpixyz/foo.bar with foo.xyzbar. I suspect I'll stick with the former;
my DVI drivers can support both flavors of names.
A year or so ago, after I installed a new release of UNIX TeX with
directory searching, I got numerous user complaints about slow
startup. Timing tests, and use of the Sun SunOS trace, and Sun
Solaris truss, system call tracer, showed that every invocation of TeX
was taking 5 to 10 wall clock seconds to recursively read selected
directories in the TeX tree (I just counted a total of 16572 files in
455 directories). Given that we have high-performance RISC
workstations that can TeX the TeXbook at almost 20 pages/second (3 to
5 pages/sec is typical of entry-level UNIX workstations), this is a
TERRIBLE startup penalty. I therefore rebuilt TeX with the directory
path search code disabled, and thereby silenced user complaints.
While I applaud the effort at making a universal system-independent
TeX directory structure, I do caution that the performance hit at
large sites from the adoption of mandatory subdirectory path searching
in TeXware will certain make some end users unhappy. On the other
hand, it will certainly help to alleviate the problem of long search
paths; on our NeXT systems, we have already hit a stupid shell limit
of 1024 character in environment variable names, and had to trim the
default paths accordingly.
========================================================================
Nelson H. F. Beebe Tel: +1 801 581 5254
Center for Scientific Computing FAX: +1 801 581 4148
Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu
University of Utah URL: http://www.math.utah.edu/~beebe
Salt Lake City, UT 84112, USA
========================================================================
================================================================================
From owner-twg-tds@shsu.edu Thu, 15 Jun 1995 17:50:06 CDT
Sender: owner-twg-tds@SHSU.edu
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
Reply-To: TWG-TDS@SHSU.edu
Date: Thu, 15 Jun 1995 15:26:19 -0600
To: twg-tds@shsu.edu
CC: beebe@math.utah.edu
Subject: Remarks on ``A Directory Structure for TeX Files 0.98''
Message-ID: <CMM.0.91.0.803251579.beebe@plot79.math.utah.edu>
On p. 1, Introduction, paragraph 2, mention should be made of Windows NT
(it is mentioned later on).
On p. 10, end of section 4.1, it should be noted that dpi == dots per inch.
Too bad the US remains the only nation in the world using that obsolete
system of units.
On p. 10, section 4.1.1 and p. 17, section A.3, mention is made of
a filename cache. I've had such a cache implemented in my (still
unreleased) DVI driver family 3.0 since March 1992 and find that
it works quite well. The cache file is simple: just a list of
file names (mostly fonts) like this:
/usr/local/lib/tex/ams/amsfonts/pk-files/300dpi/cmbsy5.300pk
...
/usr/local/lib/tex/musictex/tfm/sluruu16.tfm
For convenience, TeX and UNIX shell style comments are supported. On
our systems, this file is about 4390 lines (208KB of file) in the
current version, covering all of our installed font files.
The final component acts as the key in a hash table lookup, and
provided the cache file is sorted, only one copy is made of the
directory path. Consequently, for our cache file, the amount of
memory required for filename strings is about 56KB, and for the hash
table itself, about 41KB, for a total of under 100KB, which is modest
in the workstation world.
Tests have shown that the time to read the cache file and internalize
it is well under a second; the contents can be tuned to local needs,
e.g. shortened to reduce internal memory use, and speed startup.
Every file open (other than for the cache file itself, and for startup
configuration files, because they might alter the cache file location)
goes through the cache algorithm:
(1) if the file is found in the cache, and can be opened
successfully, return success
(2) if the file is found in the cache, but cannot be opened,
issue a warning message about a stale cache, and go to (3)
(3) revert to directory path search
One disadvantage is that in order for the user to override the cached
location of a file, in order to provide a private replacement, s/he
must provide a modified (or empty) cache file, because the directory
order in the search path has no effect on a cache lookup. A
command-line option to the DVI driver program could do this as well,
but so far, the need has been infrequent. However, this is LESS
likely to be the case for TeX itself, since users often have modified
versions of system macro files, but rarely do for font files.
The warning message in (2) has proved to be important, because some of
our users port a portion of our TeX tree to off-campus machines,
possibly invalidating the cache.
A second disadvantage is that the 8+3 DOS filename length limitation
that led to the adoption in the TWG-TDS proposal of the
dpi300/cmr10.pk name flavor over cmr10.300pk conflicts with use of the
base filename as a key; solutions are to retain both flavors in the
tree, as proposal suggests, or to add a hack (ugh...) to my generic
file cache support code to build in knowledge of the equivalence of
dpixyz/foo.bar with foo.xyzbar. I suspect I'll stick with the former;
my DVI drivers can support both flavors of names.
A year or so ago, after I installed a new release of UNIX TeX with
directory searching, I got numerous user complaints about slow
startup. Timing tests, and use of the Sun SunOS trace, and Sun
Solaris truss, system call tracer, showed that every invocation of TeX
was taking 5 to 10 wall clock seconds to recursively read selected
directories in the TeX tree (I just counted a total of 16572 files in
455 directories). Given that we have high-performance RISC
workstations that can TeX the TeXbook at almost 20 pages/second (3 to
5 pages/sec is typical of entry-level UNIX workstations), this is a
TERRIBLE startup penalty. I therefore rebuilt TeX with the directory
path search code disabled, and thereby silenced user complaints.
While I applaud the effort at making a universal system-independent
TeX directory structure, I do caution that the performance hit at
large sites from the adoption of mandatory subdirectory path searching
in TeXware will certain make some end users unhappy. On the other
hand, it will certainly help to alleviate the problem of long search
paths; on our NeXT systems, we have already hit a stupid shell limit
of 1024 character in environment variable names, and had to trim the
default paths accordingly.
========================================================================
Nelson H. F. Beebe Tel: +1 801 581 5254
Center for Scientific Computing FAX: +1 801 581 4148
Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu
University of Utah URL: http://www.math.utah.edu/~beebe
Salt Lake City, UT 84112, USA
========================================================================
================================================================================
From owner-twg-tds@shsu.edu Fri, 16 Jun 1995 11:30:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 16 Jun 1995 10:31:48 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506161431.AA22985@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu, beebe@math.utah.edu
Subject: Re: Remarks on ``A Directory Structure for TeX Files 0.98''
A year or so ago, after I installed a new release of UNIX TeX with
directory searching, I got numerous user complaints about slow
Disk-based searching is unavoidably slow.
The TDS tree is less maintainable than the web2c 6.1 tree, precisely to
try to speed up this case. Personally, I think that is a futile effort,
but other developers did not want to implement caching -- even though,
as you say, that solves the problems, and it's easy to do. Sigh. But,
it's not going to change now, I very much doubt.
web2c 6.1 + the kpathsea 2.6 patch (which has the caching) doesn't have
the slow startup problems.
TERRIBLE startup penalty. I therefore rebuilt TeX with the directory
path search code disabled, and thereby silenced user complaints.
Disabling the code is certainly a draconian solution!
But, whatever worked.
Thanks for your comments, of course.
================================================================================
From owner-twg-tds@shsu.edu Fri, 16 Jun 1995 15:20:10 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Fri, 16 Jun 1995 13:20:30 -0700
Message-ID: <199506162020.NAA20939@tashkent.berkeley.edu>
To: twg-tds@shsu.edu
Subject: one more minor comment on TWG-TDS
I have one more minor comment on TWG-TDS:
On page 19, ``availble'' (spelling).
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Mon, 19 Jun 1995 18:24:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 19 Jun 1995 15:13:11 +0200
From: David Kastrup <dak@pool.informatik.rwth-aachen.de>
Reply-To: TWG-TDS@SHSU.edu
Subject: A few notes to the TDS-standard
To: twg-tds@shsu.edu
Message-ID: <199506191313.PAA14206@stan.goethe.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
The TDS standard specifies that the directories dpi??? contain the
resolution in dpi in the file name. However, it is never mentioned
*what* this means. The resolution, as seen by metafont, is a fixed
point number. The resolution in file names usually is a natural
number. Magstep calculation gives, exactly, irrational numbers.
So how to arrive at the integer to be used? Using metafont arithmetic,
or real arithmetic? Using truncation, or rounding?
Another point: I do find it dissatisfactorily that *all* ways to
generate fonts my non-Metafont ways are supposed to yield different
directory names. As the fonts have supposedly no other mode
information than the resolution, it seems dissatisfactory to separate
their font paths in a way which makes it necessary to mention all
tools when giving a typical search path.
For example, when using a deskjet and a laserjet, you will have to
specify the metafont-mode specific directories as well as *all*
directories for "device independent" 300dpi modes. I don't like
this.
--
David Kastrup, Goethestr. 20, D-52064 Aachen Tel: +49-241-72419
Email: dak@pool.informatik.rwth-aachen.de Fax: +49-241-79502
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Jun 1995 07:52:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Jun 1995 14:51:46 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Magnification
To: twg-tds@shsu.edu
Message-ID: <01HRXKZ7MOXU000O4Q@VzdmzA.ZDV.Uni-Mainz.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Well, the magnification is in fact well defined, and is always rational,
even in the case of \magstephalf. The authorative source of this is plain
TeX, where magstephalf is defined to be 1095. All other magsteps are of the
same accuracy (this matters only for magstep 4 and 5). I have changed the
Sauter tools in version 2.3 to reflect this policy, the new release of the
dc fonts will do so, too.
The dpi numbers are a problem, because they are even more rounded. Sensible
dvi-driver always examine a number `one off' if the initial load failed.
--J"org Knappen.
P.S. As far as <mode> in non-MF fonts is concerned, one could stretch the
notion of mode to the method of deriving a tfm file and vf files from the
original ps fonts, which would give us ``modes'' like afmtotfm, psnfss1,
psnfss2. And yes, there are good reasons to save the old versions of the
psfonts, say you want to print replacement pages for a already published
book.
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Jun 1995 15:40:17 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Tue, 20 Jun 1995 12:40:55 -0700
Message-ID: <199506201940.MAA24245@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Magnification
On Tue Jun 20 06:58:50 1995, KNAPPEN@VKPMZD.kph.Uni-Mainz.DE writes:
> Well, the magnification is in fact well defined, and is always rational,
> even in the case of \magstephalf. The authorative source of this is plain
> TeX, where magstephalf is defined to be 1095.
IMHO, the authoritative source is the TeXbook, which states on page 17:
There's also \magstephalf, which magnifies by $\sqrt{1.2}$, i.e.,
halfway between steps 0 and 1.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Jun 1995 15:55:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Jun 1995 16:55:03 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506202055.AA14732@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu, dak@pool.informatik.rwth-aachen.de
Subject: Re: A few notes to the TDS-standard
*what* this means. The resolution, as seen by metafont, is a fixed
point number. The resolution in file names usually is a natural
Clearly, you are right and we should clarify this in the next version.
The intent, at least in my mind, is that the ``dpi'' is the
resolution part of the name that Metafont generates. Which is to say,
the rounded integer of hppp at the first shipout time.
For example, when using a deskjet and a laserjet, you will have to
specify the metafont-mode specific directories as well as *all*
directories for "device independent" 300dpi modes. I don't like this.
I don't like it either. xdvi's path, for example, is complicated as it
stands in order to get bitmaps for PostScript fonts.
But, I don't know of a viable alternative. Can you offer one?
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Jun 1995 16:35: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: <199506202050.WAA20213@spice.iti.informatik.th-darmstadt.de>
Subject: Re: A few notes to the TDS-standard
To: TWG-TDS@SHSU.edu
Date: Tue, 20 Jun 1995 22:50:23 +0200 (MESZ)
CC: dak@pool.informatik.rwth-aachen.de
Content-Type: text
David wrote:
>
> The TDS standard specifies that the directories dpi??? contain the
> resolution in dpi in the file name. However, it is never mentioned
> *what* this means.
The same number as used by MF in its output file name.
Norman, do you add this clarification to the TODO list?
> Another point: I do find it dissatisfactorily that *all* ways to
> generate fonts my non-Metafont ways are supposed to yield different
> directory names. As the fonts have supposedly no other mode
> information than the resolution, it seems dissatisfactory to separate
> their font paths in a way which makes it necessary to mention all
> tools when giving a typical search path.
>
> For example, when using a deskjet and a laserjet, you will have to
> specify the metafont-mode specific directories as well as *all*
> directories for "device independent" 300dpi modes. I don't like
> this.
Any counter-proposals? How about
fonts/pk/non-mf/<utility>/dpi<dpi>/<font>.pk
? This way one would have only two directory (trees) in the search path.
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, 22 Jun 1995 19:27:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 23 Jun 1995 02:27:57 CET +0100
From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" <SPIELER@linac.ikp.physik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Message-ID: <00992499.6AF00BC4.1@linac.ikp.physik.th-darmstadt.de>
Subject: Comments and questions concerning draft 0.98, directory layout
Hello, Dear TWG-TDS committee!
I have tried to convert our local TeX installation (VMS) to the directory
layout as recommended by TDS draft 0.98. This work resulted in the
following comments and questions:
A) I do not like the name `source' for the root of the merged
METAFONT font sources (.mf) and property list (.pl) files tree.
I would prefer the name "/texmf/fonts/mf/" over "/texmf/fonts/source/".
And, the `property list' (.pl) files should get their own subtree,
headed with "/texmf/fonts/pl".
The name "..../source" is somehow inconsistent, since the other
subtrees <type> names specify the file type more precicely.
If you want to stay with `source', it would be consequent to
merge ALL font sources (namely: METAFONT, property list, and type1 (!!))
under this subtree root. Similary, the `afm' and `tfm' subtrees should
should then merged in a common subtree named something like `metric';
and all pixel file formats (.pk, .gf, and the obsolete .pxl) should
be located under a common `bitmap' root:
/texmf
/fonts
/source/<vendor>/<typeface> .mf, .pl, .pfa, .pfb, .mp (...) files
/metric/<vendor>/<typeface> .afm, .tfm (...) files
/bitmap/<vendor>/<typeface> .gf, .pk, .pxl (...) files
B) There are some `non-font' metric files (used for test purpose) that
do not fit well in the TDS structure, examples are `dummy.tfm' (supplied
with the AMS fonts, and used for syntax checking) and `trip.tfm'.
In my opinion, the TDS standard should specify a reserved <typeface>
name where these nonprintable font metrics and there respective
sources can be located.
(By the way, is there a reserved `misc' <typeface> name for
`single file font packages', similar to the `misc' package name in
the tex macro tree?)
C) In my eyes, the location of the .mft style files under the reserved format
name mft in the TeXinputs tree is a bad idea. These .mft files are not
used by TeX at all. Many implementations of the MFT program do not
automatically scan the TeXinputs path for .mft files (e.g. emTeX,
including the betatest releases; or Public MFT for DOS; or the DECUS VMS
implementation). The `tradition' mentioned in the TDS document seems
to be based solely on one or two (but quite popular) UNIX implementations
where MFT was modified to search the TeXinputs path for .mft style files.
The right solution would be a top level directory "mft/" under "/texmf/"
for the mft style files, the "mftmac.tex" macros should be put into
the same location as for example "webmac.tex" (probably
"/texmf/tex/plain/misc" , or "/texmf/tex/plain/base").
If do not want to specify a top level directory for the currently
available four mft style files (plain.mft, cmbase.mft, e.mft, and a
polish.mft; name are from CTAN), an alternative would be to
put them in the same directory as the .mf source files they accompany.
D) I have found some inconsistencies between the draft document and
Joachim Schrod's sample installation:
a) The draft locates the /hyphen directory below /generic, but
in map.files it is a <format> directory.
b) Should special files of a format package which are only used for
the IniTeX run located under <format>/base (as the documents recommends),
or should they put under <format>/initex (as in map.files)?
(This is problematic especially for LaTeX2e's ".ltx" files.)
c) In the sample installation, the config files for LaTeX are partly
collected in /texmf/tex/latex/config/, but texsys.cfg resides in
/texmf/tex/latex/initex/ !
(Where should I put my other IniTeX-only LaTeX config files, as
hyphen.cfg, fontmath.cfg ?)
A side remark:
When many different packages of a given format use local configuration
files, collecting all these files in the common "reserved package"
directory "config/" might lead to a quite (over)crowed configuration
directory. Somebody who is not familiar with the installed packages
may have difficulties to associate the config files with their
package directory.
E) A last question:
How should the `musictex' package get installed? The musictex macros
are primarily intended to be used with plain TeX, but there is an
additional LaTeX interface (usable for smaller sample insertions).
The LaTeX style files should probably go into /texmf/tex/latex/musictex/;
but the main macros, should the located under "plain" or under "generic"
(The main macros are needed by the LaTeX interface!).
I wish that my comments and questions help to clarify the TDS standard
document.
Many thanks,
Christian Spieler
================================================================================
From owner-twg-tds@shsu.edu Fri, 23 Jun 1995 03:02:36 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Fri, 23 Jun 1995 01:03:09 -0700
Message-ID: <199506230803.BAA26869@tashkent.berkeley.edu>
To: twg-tds@shsu.edu
Subject: A comment on the proposed TDS standard
The proposed TeX Directory Structure (TDS) standard discusses how a
subdirectory structure can help with system administration. However,
I would also like to see some provision for expanding the allowable name
space for TeX input files.
As I see it, TeX currently has a problem: the name space for \input files
is too small. For example, the TDS can accommodate at most one article.sty
file. This has the following disadvantages:
o Since LaTeX 209 has an ``article'' style, AmSTeX cannot have one;
instead they end up calling their article style ``amsart.''
o A smooth transition from LaTeX 209 to LaTeX2e was possible only because
style files changed their suffix from .sty to .cls. But I would
hate to be changing suffixes every time there's a major new release
of LaTeX.
What I would like to see would be something modeled after the way #include
files are handled in C. Specifically, one should be able to say, e.g.,
\input latex2e/article.sty
and have TeX look for files named article.sty within the directory
texmf/tex/latex2e instead of within the directory texmf/tex.
I first heard this idea (possibly slightly different) from Tomas Rokicki,
and I think it's a good one.
Given the lateness of this suggestion, it may be a bit much to expect this
to go in as a required part of the standard. But I feel that it should be
seriously considered at some point. One possibility would be to mention
it as an optional extension.
Sincerely,
Paul Vojta
vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Fri, 23 Jun 1995 04:43:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 23 Jun 95 10:43:27 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9506230943.AA19354@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: vojta@math.berkeley.edu
Subject: Re: A comment on the proposed TDS standard
> As I see it, TeX currently has a problem: the name space for \input files
> is too small. For example, the TDS can accommodate at most one article.sty
> file. This has the following disadvantages:
In fact this is not true (and there are article.sty files in both the
old 2.09 distribution, if you decide to keep it on your local machine)
and the current LaTeX distribution.
The TDS structure suggests setting separate TEXINPUT paths (in environment
variables or config files or dialog boxes or whatever) for each
format. So there may well be an article.sty under texmf/tex/latex and
another one under texmf/tex/latex209
> o A smooth transition from LaTeX 209 to LaTeX2e was possible only because
> style files changed their suffix from .sty to .cls. But I would
> hate to be changing suffixes every time there's a major new release
> of LaTeX.
Style files in 2e still mainly have .sty extension, (array.sty etc)
and even for the `main' style files which do become .cls under the new
LaTeX, we still distribute article.sty so as to support third party
files that were written by extending article.sty as in
\input{article.sty}
\renewcommand{.....}
> What I would like to see would be something modeled after the way #include
> files are handled in C. Specifically, one should be able to say, e.g.,
> \input latex2e/article.sty
> and have TeX look for files named article.sty within the directory
> texmf/tex/latex2e instead of within the directory texmf/tex.
This would not work for the example you give (although the extended
input searching might be useful in other contexts)
The LaTeX syntax for inputting `article' is \documentclass{article}
and putting explicit paths in a document is a `bad thing' as it messes
upo document portability. So in order for this to work the LaTeX
kernel would need to be changed so that \documentclass{article}
resolved down to \input latex2e/article.cls. However as we have to
make LaTeX work on a variety of machines (some without any notion of a
directory structure) I do not see how we could do this in any portable
way.
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 23 Jun 1995 10:55: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: <199506231102.NAA13158@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Comments and questions concerning draft 0.98, directory layout
To: TWG-TDS@SHSU.edu
Date: Fri, 23 Jun 1995 13:02:16 +0200 (MESZ)
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Content-Type: text
Christian wrote:
>
> A) I do not like the name `source' for the root of the merged
> METAFONT font sources (.mf) and property list (.pl) files tree.
`source-for-mfware' was too long and wasn't ISO 9660 compliant... :-)
> I would prefer the name "/texmf/fonts/mf/" over "/texmf/fonts/source/".
> And, the `property list' (.pl) files should get their own subtree,
> headed with "/texmf/fonts/pl".
> The name "..../source" is somehow inconsistent, since the other
> subtrees <type> names specify the file type more precicely.
Hmm, type1/ lumps together pfa/ & pfb/, too.
> If you want to stay with `source', it would be consequent to
> merge ALL font sources (namely: METAFONT, property list, and type1 (!!))
> under this subtree root. Similary, the `afm' and `tfm' subtrees should
> should then merged in a common subtree named something like `metric';
> and all pixel file formats (.pk, .gf, and the obsolete .pxl) should
> be located under a common `bitmap' root:
I wouldn't mind to change to such a layout. IMHO it's better than
introducing even more font-level directories.
> (By the way, is there a reserved `misc' <typeface> name for
> `single file font packages', similar to the `misc' package name in
> the tex macro tree?)
Good idea, we could put dummy.{tfm,pl} there. Btw, I think the best
place for trip.tfm is the texmf/source/ tree, as it is only needed for
the build of TeX.
> C) In my eyes, the location of the .mft style files under the reserved format
> name mft in the TeXinputs tree is a bad idea.
Full agreement.
> D) I have found some inconsistencies between the draft document and
> Joachim Schrod's sample installation:
>
> a) The draft locates the /hyphen directory below /generic, but
> in map.files it is a <format> directory.
Hmm, did we really decide to move hyphen/? Grmbl, I'm going to check
with the mail archive and will change it accordingly. (Or will come
back to the list for further discussion.)
> b) Should special files of a format package which are only used for
> the IniTeX run located under <format>/base (as the documents recommends),
> or should they put under <format>/initex (as in map.files)?
> (This is problematic especially for LaTeX2e's ".ltx" files.)
They shall be placed in <format>/base/. texsys.cfg goes to
latex/base/ if it's the unchanged version from the distribution, to
latex/config/ otherwise.
That problem with the example installation was brought to my attention
about 4 weeks ago. Since June was approaching, I decided to wait for
the new LaTeX release and fix it then. I.e., I'll do it in the
weekend, as the new release exists since two days. :)
> (Where should I put my other IniTeX-only LaTeX config files, as
> hyphen.cfg, fontmath.cfg ?)
latex/config/
> When many different packages of a given format use local configuration
> files, collecting all these files in the common "reserved package"
> directory "config/" might lead to a quite (over)crowed configuration
> directory. Somebody who is not familiar with the installed packages
> may have difficulties to associate the config files with their
> package directory.
You're completely right. OTOH, putting them in the package's directory
will yield problems when the package gets updated and one has to
decide which files must be kept and which ones can be deleted.
> [musictex] The LaTeX style files should probably go into /texmf/tex/latex/musictex/;
> but the main macros, should the located under "plain" or under "generic"
> (The main macros are needed by the LaTeX interface!).
Then they go in generic/.
> I wish that my comments and questions help to clarify the TDS standard
> document.
Thanks a lot for your comments.
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, 23 Jun 1995 12:38:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 23 Jun 1995 13:39:03 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199506231739.NAA02852@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Norm is on Vacation...
Reply-To: TWG-TDS@SHSU.edu
Folks,
I'll be on vacation from 6/24 (tomorrow) through 7/5. I won't
be reading mail or even thinking about computers...see you
(virtually) in a week.
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 Sat, 24 Jun 1995 10:09:11 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sat, 24 Jun 1995 08:09:51 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506241509.IAA20950@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, dak@pool.informatik.rwth-aachen.de
Subject: Re: A few notes to the TDS-standard
I am not sure I understand the question. The calculations in METAFONT yield
floating-point numbers a good deal of the time, but they are rounded
before they get to file names. There is the unfortunate fact that
some drivers at least in the past handled rounding in ways that resulted
in the tiresome conflict between 328 and 329 dpi---that used to cause
all sorts of tiresome messages---but standard magstep values, which are
hardwired into TeX (TeXbook p. 349) produce pretty standard results
nowadays. Convention has been to take the rounding done by METAFONT and
arbitrarily declare that to be "correct" for the indication of resolution.
A search on either side of the calculated value in a dvi interpreter is
going to pick up the METAFONT generated value pretty quickly.
One of the nice things about allowing a bit of fudging is that it permits
large magsteps in one series (e.g. 120dpi) to continue into another series
(e.g. 300dpi, since 120 * magstep(5.0) is 299dpi). It may not be "clean"
but it works, so long as a limited search on either side of the exact
calculated value is allowed for.
I join with Karl, of course, in deploring the complexity that has been
introduced into the pk tree, but the die is cast, the Rubicon is crossed,
the chips are down and judgement has been rendered. Long live the king.
%=======================================================================%
| 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 Sat, 24 Jun 1995 11:17:41 CDT
Sender: owner-twg-tds@SHSU.edu
From: dak@POOL.Informatik.RWTH-Aachen.DE (David Kastrup)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9506241617.AA29202@tabaqui>
Subject: Re: A few notes to the TDS-standard
To: mackay@cs.washington.edu (Pierre MacKay)
Date: Sat, 24 Jun 1995 18:17:45 +0200 (MET DST)
CC: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
>
> I am not sure I understand the question. The calculations in METAFONT yield
> floating-point numbers a good deal of the time, but they are rounded
> before they get to file names.
That's just it. The TDS does not specify that the directory resolutions
are to be the rounded MF numbers. This should be clarified.
> Convention has been to take the rounding done by METAFONT and
> arbitrarily declare that to be "correct" for the indication of resolution.
This convention has to find its way into the standard.
> A search on either side of the calculated value in a dvi interpreter is
> going to pick up the METAFONT generated value pretty quickly.
>
> One of the nice things about allowing a bit of fudging is that it permits
> large magsteps in one series (e.g. 120dpi) to continue into another series
> (e.g. 300dpi, since 120 * magstep(5.0) is 299dpi). It may not be "clean"
> but it works, so long as a limited search on either side of the exact
> calculated value is allowed for.
Ugh, ugh, ugh. This is *not* the tyupesetting quality we were bargaining
for when separating even, say, HPDeskJet and hplaser directories.
>
> I join with Karl, of course, in deploring the complexity that has been
> introduced into the pk tree, but the die is cast, the Rubicon is crossed,
> the chips are down and judgement has been rendered. Long live the king.
When a draft standard is announced? Hardly.
================================================================================
From owner-twg-tds@shsu.edu Sat, 24 Jun 1995 23:40:22 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Sat, 24 Jun 1995 20:49:41 -0700
Message-ID: <199506250349.UAA28878@tashkent.berkeley.edu>
To: twg-tds@shsu.edu
Subject: Re: A comment on the proposed TDS standard
CC: carlisle@cs.man.ac.uk
On Fri, 23 Jun 95 10:43:27 BST, David Carlisle <carlisle@cs.man.ac.uk> writes:
> > As I see it, TeX currently has a problem: the name space for \input files
> > is too small. For example, the TDS can accommodate at most one article.sty
> > file. This has the following disadvantages:
>
> In fact this is not true (and there are article.sty files in both the
> old 2.09 distribution, if you decide to keep it on your local machine)
> and the current LaTeX distribution.
I stand corrected.
> Style files in 2e still mainly have .sty extension, (array.sty etc)
> and even for the `main' style files which do become .cls under the new
> LaTeX, we still distribute article.sty so as to support third party
> files that were written by extending article.sty as in
> \input{article.sty}
> \renewcommand{.....}
Then perhaps the current transition from latex209 to latex2e is not so
smooth after all.
------
> > What I would like to see would be something modeled after the way #include
> > files are handled in C. Specifically, one should be able to say, e.g.,
>
> > \input latex2e/article.sty
>
> > and have TeX look for files named article.sty within the directory
> > texmf/tex/latex2e instead of within the directory texmf/tex.
>
> This would not work for the example you give (although the extended
> input searching might be useful in other contexts)
>
> The LaTeX syntax for inputting `article' is \documentclass{article}
> and putting explicit paths in a document is a `bad thing' as it messes
> upo document portability. So in order for this to work the LaTeX
> kernel would need to be changed so that \documentclass{article}
> resolved down to \input latex2e/article.cls.
That was what I had in mind. The user would say \documentclass{article}
and the LaTeX macro package would internally translate that into
\input latex2e/article.cls.
Or, someone who wanted to make up their own format called ``foobar'' would
be able to let their format have a style called ``article,'' and call
the style file ``article.sty.'' Users might then put
``\input foobar/article.sty'' in their documents, with the understanding
that directory foobar would contain the currently preferred version of the
input files for the foobar format. This is analogous to how
``#include <X11/Xlib.h>'' is handled.
> However as we have to
> make LaTeX work on a variety of machines (some without any notion of a
> directory structure)
On a variety of TeX implementations, you mean.
> I do not see how we could do this in any portable way.
How about (in the LaTeX macro package):
\def\inputdirectory{latex/}
\newread\foobar
\openin\foobar=\inputdirectory latex.tex
\ifeof\foobar % (TeXbook page 217)
\def\inputdirectory{}%
\fi
\closein\foobar
Then \documentclass{article} would eventually lead to:
\input \inputdirectory article.cls
More to the point, though, you seem to be saying, ``we can't do:
B. change \documentclass in LaTeX to expand to \input latex2e/...
right now because it requires
A. certain semantics for ``\input foo/bar[.ext]''
which is unsupported on many implementations.''
I am not asking you to change anything in LaTeX right now. I am asking
a standards body to consider change (A). Doing so would, after a period of
time, enable the LaTeX team (if they so decide) to implement (B), and give
certain benefits to other macro package authors.
That is how progress takes place in the presence of an installed base.
-------
> The TDS structure suggests setting separate TEXINPUT paths (in environment
> variables or config files or dialog boxes or whatever) for each
> format. So there may well be an article.sty under texmf/tex/latex and
> another one under texmf/tex/latex209
Suggests? In the sense of ``to mention or imply as a possibility,'' yes:
TDS> By providing a format directory, path searching can be
TDS> limited to only those directories that contain relevant files.
TDS> Although some of these formats can also
TDS> be used as macro packages, the \abbr{TDS} nevertheless stores them as
TDS> formats. By adjusting the {\TeX} inputs search
TDS> path, it is straightforward to use them as macro packages under
TDS> another format, whereas placing them in the tree of another format
TDS> would completely obscure their possible use as a format.
But, as I read it, it does not make a recommendation either for or against
this practice.
Also, later it says:
TDS> a recursive search beginning at \path|texmf/tex|
TDS> is a correct path for {\TeX} inputs in a \abbr{TDS} tree.
Putting separate paths in a config file is, IMHO, a real kludge. It means
you have to dig into the config file in order to install a format.
This makes it hard to automate such an installation. It also means that
% tex foobar
where foobar.tex contains:
\input amstex
\documentstyle{amsppt}
...
is not equivalent to
% amstex foobar
where foobar.tex contains:
\documentstyle{amsppt}
...
because the input paths will be different.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Mon, 26 Jun 1995 13:40:38 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 26 Jun 1995 11:15:22 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506261815.LAA18317@june.cs.washington.edu>
To: dak@POOL.Informatik.RWTH-Aachen.DE
CC: TWG-TDS@SHSU.edu
Subject: Re: A few notes to the TDS-standard
> One of the nice things about allowing a bit of fudging is that it permits
> large magsteps in one series (e.g. 120dpi) to continue into another series
> (e.g. 300dpi, since 120 * magstep(5.0) is 299dpi). It may not be "clean"
> but it works, so long as a limited search on either side of the exact
> calculated value is allowed for.
Ugh, ugh, ugh. This is *not* the tyupesetting quality we were bargaining
for when separating even, say, HPDeskJet and hplaser directories.
Don't get me wrong. This is a way around the endless proliferation of
SCREEN fonts, at least at this site. But I really don't expect the
difference between 299dpi and 300dpi will be noticeable in the rare
use of magstep(5.0) anyway, even if blacker and fillin values change a
bit. I found Brian Reid's diatribe about the corruption of taste
resulting from viewing fonts at 300dpi when I was cleaning up
recently. It is still true, even if he did join the corrupters.
>
> I join with Karl, of course, in deploring the complexity that has been
> introduced into the pk tree, but the die is cast, the Rubicon is crossed,
> the chips are down and judgement has been rendered. Long live the king.
When a draft standard is announced? Hardly.
The amount of momentum in a draft standard is usually overwhelming.
================================================================================
From owner-twg-tds@shsu.edu Mon, 26 Jun 1995 14:19:39 CDT
Sender: owner-twg-tds@SHSU.edu
From: "ALAN A DUNWELL" <DUNWELL@jnov.colorado.edu>
To: twg-tds@shsu.edu
Date: Mon, 26 Jun 1995 13:20:00 MST
Subject: TWG-TDS 0.98....
Reply-To: TWG-TDS@SHSU.edu
CC: Hammond@Solarz
Howdy All,
Having read through your proposal I congratulate you all on your
attempts to bring some order to chaos. For the most part, what you
are proposing is similar or in line with what we have been trying to
implement locally, since we must support Mac, DOS, Windows, VMS,
VMS/AXP, Ultrix, and OSF/1. A coherent structure is very much in our
interest.
Several comments:
- On your naming of the TeX Root as texmf, I find your reasoning
quite weak. For years anything with 'mf' referred to METAFONT, not
other pieces of the TeX family. What is wrong with something as
straight forward as tex or texroot (tex_root?)?
- Comments on the TeX Root also apply to the change from 'inputs' to
'tex'. What was wrong with 'inputs' or its alternate 'macros'?
- I understand your reasons for spreading out packages into various
branches such as source, doc, tex, a tough call there. I personally
prefer to have a package in just one area, but such is life. Having
chosen this split structure, I encourage you to try to get vendors
purveyors of a package to also provide 'clean-up' scripts that will
seek-and-destroy all old version files. Even with the old system,
packages tended to have pieces and parts all over the place with not
identifiable names (e.g. RevTeX). At the very least they should
provide a program that does a recursive search on any platform and
prepares a location list of all old files. This will help provide the
poor software managers with a hope of keeping the scrap piles under
control.
Alan Dunwell
Software Manager, JILA
(aka: Cosmic Center for Detritus Accretion?)
!-----------------------------------------------------------------------!
!Reply to: !
! Alan A. Dunwell, JILA - CB440, University of Colo., Boulder,Co. 80309 !
! E-Mail - DUNWELL@JNOV.COLORADO.EDU or DUNWELL@JILA.COLORADO.EDU !
! Voice - (303) 492-5308 FAX - (303) 492-5235 !
!-----------------------------------------------------------------------!
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Jun 1995 06:06:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 27 Jun 1995 12:06:34 +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: <950627120634.202022c7@vms.rhbnc.ac.uk>
Subject: Re: A comment on the proposed TDS standard
>> How about (in the LaTeX macro package):
>> \def\inputdirectory{latex/}
>> \newread\foobar
>> \openin\foobar=\inputdirectory latex.tex
>> \ifeof\foobar % (TeXbook page 217)
>> \def\inputdirectory{}%
>> \fi
>> \closein\foobar
>> Then \documentclass{article} would eventually lead to:
>> \input \inputdirectory article.cls
Unfortunately all of this is predicated on the assumption that a directory
can be specified as a prefix; whilst this is true for some operating systems
(MS/DOS, Unix, etc.), it is not true for others (e.g. VMS) unless the
`directory' is really a logical name. Thus for VMS one has two alternate
syntaces:
\input node::disc:[directory.subdirectory]filename.extension;version
and
\input logical_name:filename.extension;version
Only the latter could be supported using the mechanism suggested.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Jun 1995 05:12:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 28 Jun 1995 11:11:18 +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: <950628111118.2020463c@vms.rhbnc.ac.uk>
Subject: Sincere apologies...
... my neuron must have ceased firing when I wrote:
>> Unfortunately all of this is predicated on the assumption that a directory
>> can be specified as a prefix; whilst this is true for some operating systems
>> (MS/DOS, Unix, etc.), it is not true for others (e.g. VMS) unless the
>> `directory' is really a logical name. Thus for VMS one has two alternate
>> syntaces:
>> \input node::disc:[directory.subdirectory]filename.extension;version
>> and
>> \input logical_name:filename.extension;version
>> Only the latter could be supported using the mechanism suggested.
Only the brain-dead could have failed to realise that the directory is
a prefix in both cases; I simply cannot explain how I came to think that
it was not.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 29 Jun 1995 15:53:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Jun 1995 16:52:07 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506292052.AA02792@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu, Hammond%Solarz@niord.shsu.edu
Subject: Re: TWG-TDS 0.98....
- On your naming of the TeX Root as texmf, I find your reasoning
quite weak. For years anything with 'mf' referred to METAFONT, not
Web2c has used a default directory of `texmf' for ``years''. No one's
ever complained about it meaning only Metafont.
other pieces of the TeX family. What is wrong with something as
straight forward as tex or texroot (tex_root?)?
I find `texmf' more straightforward than `texroot'. I guess this is a
matter of opinion.
- Comments on the TeX Root also apply to the change from 'inputs' to
'tex'. What was wrong with 'inputs' or its alternate 'macros'?
`inputs' is inappropriate because programs other than TeX have input files.
`macros' likewise, to some extent. Also, we saw no reason not to use the
program name for TeX input files just as we did for every other kind of
file. And, Web2c and perhaps other implementations have used `tex' as
the ``inputs'' directory name for quite some time.
chosen this split structure, I encourage you to try to get vendors
purveyors of a package to also provide 'clean-up' scripts that will
I agree.
================================================================================
From owner-twg-tds@shsu.edu Thu, 29 Jun 1995 15:53:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Jun 1995 16:51:56 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506292051.AA02783@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Subject: Re: Comments and questions concerning draft 0.98, directory layout
merge ALL font sources (namely: METAFONT, property list, and type1 (!!))
I'm not sure type1's should be lumped with the others.
/source/<vendor>/<typeface> .mf, .pl, .pfa, .pfb, .mp (...) files
/metric/<vendor>/<typeface> .afm, .tfm (...) files
/bitmap/<vendor>/<typeface> .gf, .pk, .pxl (...) files
Seems like a good idea to me.
do not fit well in the TDS structure, examples are `dummy.tfm' (supplied
with the AMS fonts, and used for syntax checking) and `trip.tfm'.
dummy.tfm goes wherever Barbara says it goes.
As Joachim says, trip.tfm doesn't need to be installed anywhere (and
probably shouldn't be).
(By the way, is there a reserved `misc' <typeface> name for
`single file font packages', similar to the `misc' package name in
the tex macro tree?)
I don't see the need. A font always comes in multiple files, doesn't it?
The source, the metric, the glyphs. That's not true for macro packages.
C) In my eyes, the location of the .mft style files under the reserved format
name mft in the TeXinputs tree is a bad idea. These .mft files are not
I suppose. I'm not opposed to moving it to the top-level. I guess you're
right about the ``tradition'' being web2c-centric.
How should the `musictex' package get installed? The musictex macros
Can't you make a .fmt file out of it, thus texmf/tex/musictex/...?
I wish that my comments and questions help to clarify the TDS standard
Thanks for taking the trouble to send them.
================================================================================
From owner-twg-tds@shsu.edu Thu, 29 Jun 1995 15:55:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Jun 1995 16:52:26 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506292052.AA02872@terminus.cs.umb.edu>
To: schrod@iti.informatik.th-darmstadt.de
CC: TWG-TDS@SHSU.edu, dak@pool.informatik.rwth-aachen.de
Subject: Re: A few notes to the TDS-standard
Any counter-proposals? How about
fonts/pk/non-mf/<utility>/dpi<dpi>/<font>.pk
I guess this is a good idea. As David pointed out to me offline, it's
dubious that anyone would ever want to search on only the gsftopk fonts
and not ps2pk, or vice versa. (And they still could do this if they
wanted, anyway.)
We do definitely have to keep the <utility> directory level, though,
since someone might generate their 300dpi times-roman with both
utilities, and the fonts aren't the same. They may not care which one
they get, but they shouldn't overwrite each other.
As a picayune point, I don't like the name `non-mf'.
How about `modeless'?
================================================================================
From owner-twg-tds@shsu.edu Thu, 29 Jun 1995 23:34:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Jun 1995 16:51:56 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506292051.AA02783@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Subject: Re: Comments and questions concerning draft 0.98, directory layout
merge ALL font sources (namely: METAFONT, property list, and type1 (!!))
I'm not sure type1's should be lumped with the others.
/source/<vendor>/<typeface> .mf, .pl, .pfa, .pfb, .mp (...) files
/metric/<vendor>/<typeface> .afm, .tfm (...) files
/bitmap/<vendor>/<typeface> .gf, .pk, .pxl (...) files
Seems like a good idea to me.
do not fit well in the TDS structure, examples are `dummy.tfm' (supplied
with the AMS fonts, and used for syntax checking) and `trip.tfm'.
dummy.tfm goes wherever Barbara says it goes.
As Joachim says, trip.tfm doesn't need to be installed anywhere (and
probably shouldn't be).
(By the way, is there a reserved `misc' <typeface> name for
`single file font packages', similar to the `misc' package name in
the tex macro tree?)
I don't see the need. A font always comes in multiple files, doesn't it?
The source, the metric, the glyphs. That's not true for macro packages.
C) In my eyes, the location of the .mft style files under the reserved format
name mft in the TeXinputs tree is a bad idea. These .mft files are not
I suppose. I'm not opposed to moving it to the top-level. I guess you're
right about the ``tradition'' being web2c-centric.
How should the `musictex' package get installed? The musictex macros
Can't you make a .fmt file out of it, thus texmf/tex/musictex/...?
I wish that my comments and questions help to clarify the TDS standard
Thanks for taking the trouble to send them.
From owner-twg-tds@shsu.edu Sun, 02 Jul 1995 07:21: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: <199507021220.OAA21808@spock.iti.informatik.th-darmstadt.de>
Subject: Re: A few notes to the TDS-standard
To: TWG-TDS@SHSU.edu
Date: Sun, 2 Jul 1995 14:20:38 +0200 (MESZ)
CC: dak@pool.informatik.rwth-aachen.de
Content-Type: text
Pierre wrote:
>
> > One of the nice things about allowing a bit of fudging is that it permits
> > large magsteps in one series (e.g. 120dpi) to continue into another series
> > (e.g. 300dpi, since 120 * magstep(5.0) is 299dpi). It may not be "clean"
> > but it works, so long as a limited search on either side of the exact
> > calculated value is allowed for.
> Ugh, ugh, ugh. This is *not* the tyupesetting quality we were bargaining
> for when separating even, say, HPDeskJet and hplaser directories.
>
> Don't get me wrong. This is a way around the endless proliferation of
> SCREEN fonts, at least at this site.
Just a note: Of course, for _one_ modedef it's not possible to decide
when one wants to use 299dpi & when 300dpi. That's due to the
different mag computation of TeX & METAFONT.
The mail archive of the now-defunct DVI Driver Committee keeps an
analysis of Tom Rokicki how far dpi values may differ & still be the
same. I remember something about 2 pixels. (Sorry, can't look it up
currently, I'm writing this mail from home.)
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, 03 Jul 1995 12:07:02 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: mimi@scri.fsu.edu
Subject: draft copies at TUG95
Date: Mon, 03 Jul 1995 17:45:53 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:026720:950703164601"@cl.cam.ac.uk>
I have, i think, got my boss to pay for printed copies of the TDS
report, bound in with the UKTUG FAQ, to be distributed to all the
delegates at TUG95. I am just off on holiday, and it'll be toolate
when i get back, but i have left the job to be processed, so fingers
crossed i'll bring 100 copies to the US with me.
someone else can do the same for EuroTeX...
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 05 Jul 1995 08:02:25 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <drw@umassmed.UMMED.EDU>
From: drw@umassmed.UMMED.EDU (Doug Waud)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507051301.AA03279@umassmed.UMMED.EDU>
Subject: a typo?
To: twg-tds@shsu.edu
Date: Wed, 5 Jul 95 9:01:42 EDT
Hi
I have just finished reading ``A Directory Structure for TeX files''
(V 0.98, june 14, 1995). I am pleased you are trying to get some
standardization here. Good job.
At risk of seeming picky, I write to mention a minor typo/glitch. I
find I have trouble spotting my own such boo-boos and write in the
spirit that you too may appreciate some outside help. I confess also
to feeling somewhat guilty about always being a consumer of TeX
stuff and not able (still rather inexperienced) to contribute more.
In any case, at the bottom of page 10 you explain that
files are the names ...
but I believe there is no antecedent for that ``files''. Perhaps you
had intended to put it at the end of the line
texmf/metafont/package/
eight lines earlier.
(No need to waste time on a reply just to be polite!)
drw
--
******************************************************************************
Douglas R. Waud (S7-137) (Bitnet: drw@umassmed)
Department of Pharmacology (Internet: drw@ummed.edu)
U. Massachusetts Med. Sch. (aka 146.189.16.2)
55 Lake Avenue North (FAX: 508-856 5080)
Worcester, MA, 01655-0216 (Voice: 508 856 3339)
******************************************************************************
================================================================================
From owner-twg-tds@shsu.edu Wed, 05 Jul 1995 09:06:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 05 Jul 1995 16:06:01 CET +0100
From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" <SPIELER@linac.ikp.physik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Message-ID: <00992E79.AFD54F44.2700@linac.ikp.physik.th-darmstadt.de>
Subject: Names of the <type> level in fonts dir tree
Hello,
Joachim replied to my comment on the <type> name for Metafont/Property
list sources, where I `suggested' to merge all different types in
only three subdirs (source, metrics, bitmap):
> Christian wrote:
> > [...]
> > If you want to stay with `source', it would be consequent to
> > merge ALL font sources (namely: METAFONT, property list, and type1 (!!))
> > under this subtree root. Similary, the `afm' and `tfm' subtrees should
> > should then merged in a common subtree named something like `metric';
> > and all pixel file formats (.pk, .gf, and the obsolete .pxl) should
> > be located under a common `bitmap' root:
>
> I wouldn't mind to change to such a layout. IMHO it's better than
> introducing even more font-level directories.
>
It was not my intention to change the TDS layout in this direction. Perhaps
I was misunderstood.
In my eyes, the split of the font directory tree into different <type>
type=type1, tfm, afm, pk, etc.) branches has the intention to separate
the search paths for programs that read different formats (types) of
font information. I want the TDS to maintain this goal.
When you consider this intention, there is a difference between
`source' containing both Metafont and PLtoTF sources and `type1' containing
both binary and text PS font sources. Many programs that use PS font sources
(Postscript interpreters, or xx-to-postscript converters like `dvips') can
read both binary and text format PS sources, here it makes sense to
use a common directory branch. In contrast, I never managed to get
METAFONT processing a property list, nor does a Property List reader
(pltotf) produce anything usefull from a METAFONT source.
Therefore, my perfered suggestion is:
The branch `source' (whose name is too "generic", anyway) should be
splitted into `mf' and `pl'.
There are a lot of other examples in the TDS where the file extension
string is (re)used as a directory name (.tex, .pk, .gf, ...).
Best regards,
Christian Spieler
================================================================================
From owner-twg-tds@shsu.edu Wed, 05 Jul 1995 18:51:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 5 Jul 1995 19:50:14 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507052350.AA24282@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Subject: Re: Names of the <type> level in fonts dir tree
The branch `source' (whose name is too "generic", anyway) should be
splitted into `mf' and `pl'.
I don't have any big objection to this. Christian is certainly correct
that MF can't process PL files :-).
As I recall, the original reason for `source' was so things like awk
programs, fontinst inputs, etc., would legitimately go with the Metafont
sources where they belong. If we switch to `mf' and `pl', we should say
the directory name isn't necessary a 100% perfect reflection of the
files therein.
Pierre?
================================================================================
From owner-twg-tds@shsu.edu Thu, 06 Jul 1995 10:32:08 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Thu, 6 Jul 1995 08:31:32 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507061531.IAA24105@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Names of the <type> level in fonts dir tree
CC: mackay@cs.washington.edu
For METAFONTS, "source" is clearly *.mf files, almost exclusively,
but I think that is missing the point. I use "source" for uncompiled
"source" of whatever sort, together with program text (also source, in a
sense) for shell scripts, awk and sed. Reviewing the BaskervilleMT
and AGaramond "source" directories I have been working in, I find
that I have some face specific scripts that I haven't had time
to generalize, lots of vpls, which I use all the time, fully
disassembled font files with the ps suffix (this means fully
human-readable files derived from pfa files) and even mf files
made with ps2mf. If I had PL files they would be there too.
This collection seems to me entirely consistent, and it down not
(that's does not) overfill the directory. Every one of these
categories in human-readable, even the ps files derived from the
pfa files. I can see no purpose in breaking this directory down
into even smaller units. None of its content can be used directly for
output. It all has to be processed first.
So I am going to vote very strongly for keeping "source" and
defining it as something like "human readable program text sources
for compilation into fonts or metric files, together with any
related program text specific to that task."
At the very least, this means PL, VPL, MF, and disassembled font PS
files.
%=======================================================================%
| 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, 06 Jul 1995 10:52:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 6 Jul 95 16:51:24 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507061551.AA12775@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Names of the <type> level in fonts dir tree
I would generally favour splitting pl and mf. Looking at Pierre's
comments
... Reviewing the BaskervilleMT and AGaramond "source" directories
I have been working in, I find that I have some face specific
scripts that I haven't had time to generalize, lots of vpls, which
I use all the time, fully disassembled font files with the ps
suffix (this means fully human-readable files derived from pfa
files) and even mf files....
This seems to go back (Oh no!) to the whole discussion about the
organisation of the font tree.
I would say that someone `working' on a particular font should have
that font in some working directory and in that directory is quite
likly to keep all related scripts and files.
However it seems to me that the TDS tree is essentially a repository
for `fixed' installed files, and in that case it makes sense to split
the tree based on `search paths'.
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 06 Jul 1995 12:19:13 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Thu, 6 Jul 1995 10:18:32 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507061718.KAA05210@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Names of the <type> level in fonts dir tree
CC: mackay@cs.washington.edu
I admit that I wasn't thinking about the proliferation
of ./font/<types> that is now official, but the argument
four "human-readable source" still stands, even if
"source" is right down (my trees are rooted where roots normally
grow) in the ./fonts/ directory. Are we going to have
./fonts/vpl/...
./fonts/pl/...
./fonts/mf/..
./fonts/ps-from-pfa/...
and so on ad infinitum? Under ordinary circumstances, how often
do PL files get used anyway. Probably less often than vpl files.
I am increasingly unclear about what "search paths" means, but
it seems that we are getting to the point of saying that every
official suffix has a search patth?
In that case, we need $TEXMF/ltx/... $TEXMF/cls/... $TEXMF/sty/...
$TEXMF/dtx/... etc.
The argument is essentially the same, except that it requires
splitting up the LaTeX2e input files in ways that the LaTeX
consortium disapproves of.
Either we have some minimally intelligent path searching or
we don't. "source" is not a very broad category---no broader
than "base" or "contrib" which are also not suffiz-related
directory names. If path searching can find appropriate files
with a variety of files under the broad range of ./tex/latex/...
why is the much smaller ./fonts/source/... impossible.
The bare list of directories for the UnixTeX distribution has gone
from 24 pages to 30 pages with the proliferation of directories
and it is only about a quarter TDS-conformant as is. A sheaf
of 29 pages of directory names is already so bewildering that
I beg of you not to make it thicker by this sort of (what else to cal it)
hair-splitting.
%=======================================================================%
| 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, 06 Jul 1995 12:44:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 6 Jul 95 18:44:06 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507061744.AA12967@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Names of the <type> level in fonts dir tree
> I am increasingly unclear about what "search paths" means, but
> it seems that we are getting to the point of saying that every
> official suffix has a search patth?
Not extensions on the files, which are largely irrelevant here, but
the program doing the searching. ie the things that are traditionally
assigned to variables like TEXINPUT MFINPUT etc. The reason for having
(say) tfm as a top level directory is so that you can specify a tfm
search path that only consists of tfm files. The argument for
splitting off mf is the same. Your LaTeX cls/sty example is spurious
as the TDS tree does already allow the specification of an input path
for LaTeX files.
A top level mf directory is certainly more consistent with the way the
rest of the tds has evolved, but I can not say I am that bothered
either way as in practice, for a distributed TDS, the <source> tree will
most likely only consist of mf files (I dont see that many pl files
on ctan) and so setting the mf input path to be that tree will not
do too much harm.
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 06 Jul 1995 13:17:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 6 Jul 1995 14:15:57 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507061815.AA02405@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Names of the <type> level in fonts dir tree
Not extensions on the files, which are largely irrelevant here, but
the program doing the searching. ie the things that are traditionally
There isn't anything that searches for PL files (that I know of), unless
some implementations have modified pltotf to do both
searching. (Something that would have little value, as far as I can see.)
I don't see anything wrong with keeping mf's and pl's and awk scripts
and whatever else in a directory called `source'. As David says, there
aren't enough pl's etc. to matter (in terms of speed), so why
overspecify and say `only mf files go there'?
================================================================================
From owner-twg-tds@shsu.edu Thu, 06 Jul 1995 13:40:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 6 Jul 1995 14:39:56 -0400
From: jgealow@mtl.mit.edu (Jeffrey C. Gealow)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507061839.AA23304@mtl.mit.edu>
To: twg-tds@shsu.edu
Subject: commments on TDS
I have a few comments on the TDS version 0.98. I administer UNIX
workstations. We use several different platforms.
Given the constraints presented in Section 2.2, I think the
organization detailed in the TDS is very good.
Having all files under a single hierarchy (often /usr/local/texmf) is
very convenient. I prefer this approach to the use of both
/usr/local/bin and /usr/local/lib/texmf directories. The hierarchical
structure makes it easy to maintain copies of our installations using
rdist.
For Solaris 2.x systems, the natural location for the texmf directory
is /opt, not /usr/local. Perhaps this difference should be noted
in the TDS.
I'm glad texmf/fonts/type was chosen over texmf/fonts/supplier. Given
appropriate Makefiles or installation scripts, I don't think the
fonts/supplier organization would be any easier to administer than the
proposed fonts/type organization. I think it important to have a
standard that can be adopted quickly, with a minimum amount of
trouble. The primary authors of important packages like dvips and
xdvi don't seem to adopting sophisticated font-searching facilities.
Thank you for your efforts.
Jeff
================================================================================
From owner-twg-tds@shsu.edu Fri, 07 Jul 1995 03:00:52 CDT
Sender: owner-twg-tds@SHSU.edu
From: Bernard GAULLE <gaulle@idris.fr>
Reply-To: TWG-TDS@SHSU.edu
Date: Fri, 7 Jul 1995 09:59:50 +0200
Message-ID: <199507070759.JAA06572@murnau.idris.fr>
To: twg-tds@shsu.edu
CC: PICHERAL@univ-rennes1.FR
Subject: Where are the format files?
Hello dear "TSD workers",
As far as i can read, few changes have been made in the final TDS
description document.
In past drafts, specially in one of November, there was an "ini"
directory in which formats files could be placed. Some components
like "hyphen" are now elsewhere, no pb for that. But...
In the current document i don't see where i can put the format
files. May be, i'm blind?
--bg
PS: By the way what are the "mft" files?
================================================================================
From owner-twg-tds@shsu.edu Fri, 07 Jul 1995 04:42:00 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0sU9tt-0001iIC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 7 Jul 95 10:40 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Names of the <type> level in fonts dir tree
>There isn't anything that searches for PL files
fontinst does. When running fontinst, you need to munge your
TEXINPUTS path to include the AFM and PL directories. Of course,
fontinst is so slow that searching all the mf files probably isn't
going to make that much difference to performance...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 07 Jul 1995 09:09:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 7 Jul 1995 10:09:19 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507071409.AA20324@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Names of the <type> level in fonts dir tree
fontinst does. When running fontinst, you need to munge your
TEXINPUTS path to include the AFM and PL directories. Of course,
fontinst is so slow that searching all the mf files probably isn't
going to make that much difference to performance...
Indeed.
If anything separating mf/pl will make performance worse, because there
will be still more directories.
I still think combining the metrics, bitmaps, etc. would be a plausible
change (even though that isn't what Christian was suggesting). That
would cut down on the number of directories, and the directories
still won't get very large. In practice, all it means is combining afm+tfm,
I think.
================================================================================
From owner-twg-tds@shsu.edu Fri, 07 Jul 1995 09:12:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 7 Jul 1995 10:05:32 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507071405.AA20313@ra.cs.umb.edu>
To: gaulle@idris.fr
CC: twg-tds@shsu.edu
Subject: Re: Where are the format files?
In the current document i don't see where i can put the format
files. May be, i'm blind?
There's still an ini/ directory (or is initex/ now), I thought.
It's just one more directory down.
PS: By the way what are the "mft" files?
Used by Knuth's mft program. (Prettyprints Metafont sources.)
It'll probably be moved to the top level in the next version.
================================================================================
From owner-twg-tds@shsu.edu Fri, 07 Jul 1995 09:49:58 CDT
Sender: owner-twg-tds@SHSU.edu
From: Bernard GAULLE <gaulle@idris.fr>
Reply-To: TWG-TDS@SHSU.edu
Date: Fri, 7 Jul 1995 16:48:25 +0200
Message-ID: <199507071448.QAA07961@murnau.idris.fr>
To: "K. Berry" <kb@cs.umb.edu>
CC: twg-tds@shsu.edu, PICHERAL@univ-rennes1.FR
Subject: Re: Where are the format files?
>>>>> On Fri, 7 Jul 1995 10:05:32 -0400,
>>>>> "K. Berry" <kb@cs.umb.edu> write about "Re: Where are the format files?":
KB> In the current document i don't see where i can put the format
KB> files. May be, i'm blind?
KB> There's still an ini/ directory (or is initex/ now), I thought.
Unfortunately NO! in the current draft-standard V 0.98 of June,14.
--bg
================================================================================
From owner-twg-tds@shsu.edu Fri, 07 Jul 1995 10:22: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: <199507071517.RAA23587@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Where are the format files?
To: TWG-TDS@SHSU.edu
Date: Fri, 7 Jul 1995 17:17:13 +0200 (MESZ)
CC: kb@cs.umb.edu, PICHERAL@univ-rennes1.fr, gaulle@idris.fr
Content-Type: text
You wrote:
>
> >>>>> On Fri, 7 Jul 1995 10:05:32 -0400,
> >>>>> "K. Berry" <kb@cs.umb.edu> write about "Re: Where are the format files?":
> KB> In the current document i don't see where i can put the format
> KB> files. May be, i'm blind?
>
> KB> There's still an ini/ directory (or is initex/ now), I thought.
>
> Unfortunately NO! in the current draft-standard V 0.98 of June,14.
page 6, last item, bottom of page.
For each TeX port one directory is allocated. The sub-structure of
this directory is up to the author(s) of the respective port. I.e.,
it's the choice of Karl to name the directory web2c/ini/ or
web2c/initex/ or whatever [but see below].
As for the rational: The TDS fixes only the names of directories for
implementation-independent files. Nevertheless it recommends the
usage of a TeX port directory, as many people want to mount the same
TeX tree on different platforms, e.g., wants to use the same texmf
tree for both Unix & DOS systems. To have one ini/ top-level
directory would counterfeit that aim.
Concerning the naming of the web2c FMT subdir:
Karl -- if you take wishes: Please add a version number there as
well; e.g., web2c/ini/v7.0/. Or simply web2c/v7.0/. It's often not
possible to update the TeX port on every platform that's served by a
texmf file system in one rush. And if the FMT format changes one gets
an unusable installation. Placing texmf.cnf & the FMT files in a
version-specific subdirectory enables the smooth migration to a next
version of TeX.
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, 07 Jul 1995 13:32:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 7 Jul 1995 13:32:35 -0400
From: jgealow@mtl.mit.edu (Jeffrey C. Gealow)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507071732.AA00590@mtl.mit.edu>
To: mackay@cs.washington.edu
Subject: Re: commments on TDS
CC: twg-tds@shsu.edu
Pierre MacKay:
As you suspect, I have not had much interest in using different fonts.
Nor has anyone else at my research lab. We use cm fonts and LaTeX
fonts and might investigate use of PostScript fonts.
While I may not know what font organization works best for users
interested in fonts, I think I have a pretty good understanding of of
the issues as they relate to my site.
You said that /fonts/type/mode/supplier/typeface/dvi creates a
proliferation of subdirectories. Yet
/fonts/supplier/typeface/type/mode/dvi requires the same number of
subdirectories.
The primary authors of xdvi and dvips have not incorporated kpathsea
into their distributions. For each new xdvi or dvips release, someone
must re-incorporate kpathsea to create xdvik or dvipsk. There have
been no new releases of dvips for many months, so dvips and dvipsk
are in sync. But xdvi is at Patchlevel 20 while xdvik remains
at Patchlevel 18. So if we had a /fonts/supplier organization,
we would currently not be able to enjoy the support for PostScript
specials recently added to xdvi.
(Do you know why Rokicki and Vojta have not make kpathsea an integral
part of their packages?)
It appears that the complexity of kpathsea and the /fonts/supplier
organization may have made it much more difficult to maintain a
coherent UNIX TeX et al. distribution. The web2c archive is currently
very messy. The primary distribution is divided among several tar
files, some to be extracted into the target directory, some to be
extracted into the source directory. Then there is a newer "source"
distribution. And documentation divided among unixtex.ftp, a dozen
*.help files, and README files included in the tar files. Compare the
the difficulty of installing gcc or emacs-19 or the difficulty of
installing old University of Washington UnixTeX distributions to the
difficulty of installing the TeX et al. using the current web2c
archive.
You wrote, "I genuinely dislike ./fonts/<type> because it is enforced
in an attempt to make it easy for the machine and the hell with the
human user, which strikes me as the wrong way round for software."
But /fonts/supplier is not better for the user if it hinders software
development.
I recognize that Karl Berry has done a tremendous amount of work for
the good of the TeX community. I am very grateful to him, you, and
all the others who have worked on TeX. I intend my comments to be
constructive. If they are not, I apologize for my criticisms.
Jeff
================================================================================
From owner-twg-tds@shsu.edu Fri, 07 Jul 1995 14:22:34 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 7 Jul 1995 12:21:14 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507071921.MAA17811@june.cs.washington.edu>
To: jgealow@mtl.mit.edu
CC: twg-tds@shsu.edu
Subject: Re: commments on TDS
As you suspect, I have not had much interest in using different fonts.
Nor has anyone else at my research lab. We use cm fonts and LaTeX
fonts and might investigate use of PostScript fonts.
The availability of PostScript fonts is to a great extent the thing
that really drove the development of path-searching and hence
(ultimately) the TDS. Without them, a few flat directories are
adequate. I used to link all files of a specific category into
link-farms until path searching got as good as it is now. That
allowed me to continue using environment variables. In a purely CM
environment, the TEXPKS environment or something like is probably all
that is needed. Once a taste for fonts enters in, however, the
environment paths get too long very fast, and either the link-farm or
intelligent path-searching is needed. (Or, of course, a single
mile-wide directory of regular files.)
While I may not know what font organization works best for users
interested in fonts, I think I have a pretty good understanding of of
the issues as they relate to my site.
I suspect that your present organization is tuned very well to your
present needs. It probably doesn't need path-searching very much
at all. But if you branch out into things like fonts, you are almost
certain to find that, in the absence of path-searching, it becomes
a horrendous task to figure out what is filed where.
You said that /fonts/type/mode/supplier/typeface/dvi creates a
proliferation of subdirectories. Yet
/fonts/supplier/typeface/type/mode/dvi requires the same number of
subdirectories.
That's right, *once the path has been established*. But I was counting
the number of distinct inodes needed to accommodate a given font-rich
environment in either arrangement. I haven't had time to figure out just
why, but i actually tried both, and came up with almost a third more inodes
in the <type> first arrangement. The horror of dpiNNN proliferation
is another matter entirely, and I can only hope that the need for it will
ultimately wane. The directory list that I make up for UnixTeX increased
from 20 pages (I had thought the old listing was 24, but it was actually
20) to 30. Most of the extra pages are filled with dpiNNN directories.
The primary authors of xdvi and dvips have not incorporated kpathsea
into their distributions. For each new xdvi or dvips release, someone
must re-incorporate kpathsea to create xdvik or dvipsk. There have
been no new releases of dvips for many months, so dvips and dvipsk
are in sync. But xdvi is at Patchlevel 20 while xdvik remains
at Patchlevel 18. So if we had a /fonts/supplier organization,
we would currently not be able to enjoy the support for PostScript
specials recently added to xdvi.
(Do you know why Rokicki and Vojta have not make kpathsea an integral
part of their packages?)
In one case, because it comes under GNU licensing, though perhaps
the GNU library license might get around that. I am not sure in the
other.
It appears that the complexity of kpathsea and the /fonts/supplier
organization may have made it much more difficult to maintain a
coherent UNIX TeX et al. distribution.
the /fonts/supplier organization is no more complex than the /fonts/type
organization. Both are going to require intelligent path searching
if there are more branches on the tree than can be fit into an
environment path variable. This fact continues to be misunderstood.
If you are looking for Adobe Garamond in a tree which includes a
dozen or so faces each from a dozen or so suppliers there will be
approximately 144 final goal directories containing tfms. The difference is
simply in what the name of those final goal directories is. In
/fonts/supplier organization, they will all be named "tfm", while in
a /fonts/tfm organization they will presumably be named for the typeface.
There will still be 144 of them, and I doubt that any current operating
system will support an environment variable long enough to hold 144
paths strung end to end. At a certain point, intelligent path-searching
is an unavoidable necessity. Karl has pointed this out again and again,
It isn't a matter of whether it is done in kpathsea, it is a matter of
whether it is done at all.
The web2c archive is currently
very messy. The primary distribution is divided among several tar
files, some to be extracted into the target directory, some to be
extracted into the source directory. Then there is a newer "source"
distribution. And documentation divided among unixtex.ftp, a dozen
*.help files, and README files included in the tar files. Compare the
the difficulty of installing gcc or emacs-19 or the difficulty of
installing old University of Washington UnixTeX distributions to the
difficulty of installing the TeX et al. using the current web2c
archive.
I blush, and recall how wonderful it was to have Elizabeth keeping things
going. I still work on it, however, and have just made up a 3.14159
UnixTeX, with texmf runtime support that is about 1/4 TDS-conformant.
(Yes, the xdvi is a couple of revisions back of the leading edge, but
kpathsea-2.6 is incorporated into everything, and xdvi makes up bitmaps
from any PostScript font it can find.) I even did the cm files into
the DOS-compatible tree, but I am not sure I can face going on with that.
For one thing, once bitmaps are made up, it is a fairly complex business
arranging them into dpiNNN directories. Metafont still uses NNNgf as
its output suffix, and no one, I hope, is seriously considering changing
that. (Think of how it could cripple the running of a Metafont script
if every magstep came out as cmr10.pk.)
You wrote, "I genuinely dislike ./fonts/<type> because it is enforced
in an attempt to make it easy for the machine and the hell with the
human user, which strikes me as the wrong way round for software."
But /fonts/supplier is not better for the user if it hinders software
development.
I'm not sure it does. The problem seems to be one of making up the
specifications so that they express the real needs of users, future
as well as present. I sometimes think that on this subject only Karl (with
myself as an enthusiastic disciple) has an eye on the needs of the
future.
I recognize that Karl Berry has done a tremendous amount of work for
the good of the TeX community. I am very grateful to him, you, and
all the others who have worked on TeX. I intend my comments to be
constructive. If they are not, I apologize for my criticisms.
Pierre
%=======================================================================%
| 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, 07 Jul 1995 14:30:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 7 Jul 1995 13:32:35 -0400
From: jgealow@mtl.mit.edu (Jeffrey C. Gealow)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507071732.AA00590@mtl.mit.edu>
To: mackay@cs.washington.edu
Subject: Re: commments on TDS
CC: twg-tds@shsu.edu
Pierre MacKay:
As you suspect, I have not had much interest in using different fonts.
Nor has anyone else at my research lab. We use cm fonts and LaTeX
fonts and might investigate use of PostScript fonts.
While I may not know what font organization works best for users
interested in fonts, I think I have a pretty good understanding of of
the issues as they relate to my site.
You said that /fonts/type/mode/supplier/typeface/dvi creates a
proliferation of subdirectories. Yet
/fonts/supplier/typeface/type/mode/dvi requires the same number of
subdirectories.
The primary authors of xdvi and dvips have not incorporated kpathsea
into their distributions. For each new xdvi or dvips release, someone
must re-incorporate kpathsea to create xdvik or dvipsk. There have
been no new releases of dvips for many months, so dvips and dvipsk
are in sync. But xdvi is at Patchlevel 20 while xdvik remains
at Patchlevel 18. So if we had a /fonts/supplier organization,
we would currently not be able to enjoy the support for PostScript
specials recently added to xdvi.
(Do you know why Rokicki and Vojta have not make kpathsea an integral
part of their packages?)
It appears that the complexity of kpathsea and the /fonts/supplier
organization may have made it much more difficult to maintain a
coherent UNIX TeX et al. distribution. The web2c archive is currently
very messy. The primary distribution is divided among several tar
files, some to be extracted into the target directory, some to be
extracted into the source directory. Then there is a newer "source"
distribution. And documentation divided among unixtex.ftp, a dozen
*.help files, and README files included in the tar files. Compare the
the difficulty of installing gcc or emacs-19 or the difficulty of
installing old University of Washington UnixTeX distributions to the
difficulty of installing the TeX et al. using the current web2c
archive.
You wrote, "I genuinely dislike ./fonts/<type> because it is enforced
in an attempt to make it easy for the machine and the hell with the
human user, which strikes me as the wrong way round for software."
But /fonts/supplier is not better for the user if it hinders software
development.
I recognize that Karl Berry has done a tremendous amount of work for
the good of the TeX community. I am very grateful to him, you, and
all the others who have worked on TeX. I intend my comments to be
constructive. If they are not, I apologize for my criticisms.
Jeff
================================================================================
From owner-twg-tds@shsu.edu Mon, 10 Jul 1995 10:17:59 CDT
Sender: owner-twg-tds@SHSU.edu
From: Bart Childs <bart@cs.tamu.edu>
Reply-To: TWG-TDS@SHSU.edu
Date: Mon, 10 Jul 1995 10:17:15 -0500
Message-ID: <199507101517.KAA19738@lanczos>
To: twg-tds@shsu.edu
Subject: logo font
While reviewing the TDS document, I notice METAPOST presented in a font
that appears to be an entension of the logo10 font, the characters
P and S are new. Is this a new ``standard'' version of this font?
Good work! Bart Childs
================================================================================
From owner-twg-tds@shsu.edu Mon, 10 Jul 1995 10:46:09 CDT
Sender: owner-twg-tds@SHSU.edu
From: Bart Childs <bart@cs.tamu.edu>
Reply-To: TWG-TDS@SHSU.edu
Date: Mon, 10 Jul 1995 10:45:52 -0500
Message-ID: <199507101545.KAA18279@solar.cs.tamu.edu>
To: twg-tds@shsu.edu
Subject: TDS
On pages 9 and 10 the directory names
.../typeface/dpi/ are referenced. Something like
.../typeface/dpi#/ gives a stronger hint that resolution comes
in to affect it. The gentle use of sltt helps... You are precise in
calling such problems ``vexing'', but that is an understatement.
On page 11 in section 6, first paragraph.
..., except that it outputs PostScript; instead of bitmaps.
John Hobby wrote me that all of MetaFont is there in MetaPost and
that it indeed can output tfm files ...
I suggest a writing like:
..., except that its primary purpose is the output of an encapsulated
PostScript file for each figure.
Either I am confused or there is a discrepancy between pages
12 and 13 of draft TDS version 0.98.
On page 12 under `general' two examples are given by Schrod and Doob.
On page 13, these appear in general/texcomp and tex/, respectively.
I commend the committee on doing a great job on a much needed
project. You have had to make many compromises, but that is
necessary.
Regards, Bart Childs
================================================================================
From owner-twg-tds@shsu.edu Mon, 10 Jul 1995 10:47:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 10 Jul 95 17:49:49 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507101549.AA21023@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: Bart Childs <bart@cs.tamu.edu>
Subject: Re: logo font
> While reviewing the TDS document, I notice METAPOST presented in a font
> that appears to be an entension of the logo10 font, the characters
> P and S are new. Is this a new ``standard'' version of this font?
Well, this depends on what you call new. As far as I know, the letters
`P' and `S' were already included in the 1993 revison of Knuth's files
(see CTAN:systems/knuth/lib and CTAN:systems/knuth/local/lib).
Only the file logo.mf actually changed, all the other logoxx.mf files
remain unchanged and just need to be regenerated. For LaTeX2e, check
out the mflogo package in CTAN:macros/latex/contrib/supported/mflogo.
If I ever find time to update that package, I might consider providing
an archive files containing all the necessary logoxx.{mf,tfm} files
which are currently scattered around on CTAN in serveral places.
Cheers,
Ulrik Vieth. (the one who brough METAPOST into the TDS document)
================================================================================
From owner-twg-tds@shsu.edu Mon, 10 Jul 1995 10:52: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: <199507101530.RAA22814@spice.iti.informatik.th-darmstadt.de>
Subject: Re: logo font
To: TWG-TDS@SHSU.edu
Date: Mon, 10 Jul 1995 17:30:30 +0200 (MESZ)
CC: bart@cs.tamu.edu
Content-Type: text
You wrote:
>
> While reviewing the TDS document, I notice METAPOST presented in a font
> that appears to be an entension of the logo10 font, the characters
> P and S are new. Is this a new ``standard'' version of this font?
(a) yes. From DEK's current distribution.
(b) It's an oversight that the logo font is used. (Obviously my
explanations weren't good enough. ;-) Norm literally took the macro
distribution which has a configuration file (tdsguide.cfg) with code
to switch on the usage of logo fonts. The original intention was that
the distributed DVI file is TeXed without that configuration file so
that installations with old logo fonts won't have any problems with it.
Sigh. One should not implement too many fine-grained features.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 10 Jul 1995 15:39:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 10 Jul 95 17:49:49 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507101549.AA21023@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: Bart Childs <bart@cs.tamu.edu>
Subject: Re: logo font
> While reviewing the TDS document, I notice METAPOST presented in a font
> that appears to be an entension of the logo10 font, the characters
> P and S are new. Is this a new ``standard'' version of this font?
Well, this depends on what you call new. As far as I know, the letters
`P' and `S' were already included in the 1993 revison of Knuth's files
(see CTAN:systems/knuth/lib and CTAN:systems/knuth/local/lib).
Only the file logo.mf actually changed, all the other logoxx.mf files
remain unchanged and just need to be regenerated. For LaTeX2e, check
out the mflogo package in CTAN:macros/latex/contrib/supported/mflogo.
If I ever find time to update that package, I might consider providing
an archive files containing all the necessary logoxx.{mf,tfm} files
which are currently scattered around on CTAN in serveral places.
Cheers,
Ulrik Vieth. (the one who brough METAPOST into the TDS document)
================================================================================
From owner-twg-tds@shsu.edu Tue, 11 Jul 1995 15:23:50 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Tue, 11 Jul 1995 13:23:43 -0700
Message-ID: <199507112023.NAA16202@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: commments on TDS
On Fri Jul 7 11:50:14 1995, jgealow@mtl.mit.edu (Jeffrey C. Gealow) wrote:
> (Do you know why Rokicki and Vojta have not make kpathsea an integral
> part of their packages?)
The reasons I have not made kpathsea an integral part of xdvi are (1) it comes
with the GPL, which conflicts with my practice of putting xdvi on the X11R*
contrib tape, and (2) it's quite a bit larger than I'd like: 8000+ lines
vs. 800+ for font_open.c.
--Paul Vojta, vojta@math.berkeley.edu
From owner-twg-tds@shsu.edu Mon, 07 Aug 1995 08:55: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: <199508071354.PAA13483@spice.iti.informatik.th-darmstadt.de>
Subject: Re: EuroTeX proceedings (fwd)
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Mon, 7 Aug 1995 15:54:53 +0200 (MESZ)
Content-Type: text
Hi, as you might remember, I didn't say `no' when Michel asked me to
present the TDS draft at EuroTeX in Arnheim. Now I had to prepare a
memo to appear in the proceedings. Below is it, FYI. I hope I haven't
misrepresented the group's position.
May anybody who was at TUG '95 please summarize the TDS panel/BOF
there?
Cheers,
Joachim
---------------- snip snap ----------------------------------------
% tds/eurotex95/memo.tex 06 Aug 95
%------------------------------------------------------------
%
% Memo on the TDS presentation at EuroTeX '95
%
% [LaTeX]
\documentclass{article}
\usepackage{path}
\begin{document}
\title{The Proposed \TeX{} Directory Structure}
\author{Joachim Schrod}
\maketitle
The past has seen many discussions why \TeX{} is conceived to be so
difficult. Four years ago, at Euro\TeX{}~'91 in Paris, we even had a
panel on ``Why is \TeX{} unusable?'' A basic critic that came up in
almost all these discussions was (a)~the difficulty to install \TeX{}
and maintain the installed system afterwards, (b)~that there is no
agreement what components belong to an installed \TeX{} system, and
(c)~that the structure of \TeX{} installations is too different from
site to site, thereby making it difficult to maintain a \TeX{}
installation.
Over the last 15~months, a TUG working group was busy to prepare a
draft for a standard \TeX{} Directory Structure (TDS). We hope to
serve the \TeX{} community by attacking item~(c) mentioned above. In
fact, when the draft will be accepted, we hope that item~(a), the
difficulty to install and maintain \TeX{} systems, will be reduced as
well.
The TDS draft addresses primarily the \TeX{} system administrator at a
site and people preparing \TeX{} distributions. It explicates where
files of a package will reside in a final installation, thus making it
easier for the administrator to find his or her way around. If someone
is responsible for \TeX{} installations on more than one platform, it
will also reduce the needed time to find files as the structures will
all be the same.
One \TeX{} system can be used (e.g., via NFS mount or mounted from a
CD-ROM) for both Unix-based workstations and DOS-based PCs, thereby
reducing the maintenance time again. To support that aim, only the
location of implementation-independent files are fixed, locations for
implementation- and platform-dependent files are only recommended.
If developers of a package can assume a common directory structure,
the package's installation can be automated, or at least the
instructions can be made very specific. Last, but not least, many
users will be interested in a defined installation structure, as they
want to have a look at the system they are using.
The basic idea behind the TDS is that the files from a distributed
package may fall in different categories: macro files for one (or even
more) \TeX{} formats, fonts and font metrics, auxiliary files for
utility programs, etc. For each category, a package gets assigned a
set of directories where its files are placed. If more than one file
exists for a category, a whole (exclusive) directory is allocated
for that package. Otherwise this file is placed in a directory named
\texttt{misc}.
When an update for such a package arrives, the current files in the
assigned directories (or the one file in \texttt{misc}) may be thrown
away and the new ones may be installed. (It's as -- or even more --
important to know which files to remove on update, as to know which
files to install. Everybody, who has maintained any system for some
time, has stumbled over that problem.)
This distribution of files over a directory tree implies that both
\TeX{} ports and utility programs (like \texttt{DVI} drivers) must be
able to search a file recursively in a directory tree. A survey among
developers showed that most widely used \TeX{} software supports
subdirectory searching already, other implementations will get it
soon. Actually, the majority of developers were not willing to spend
much work in sophisticated cache and search strategies, so the
proposed layout pays attention to that restriction. As always, one had
to make compromises.
Members of the working group are Barbara Beeton, Karl Berry, Vicki
Brown, David Carlisle, Alan Jeffrey, Pierre MacKay, Rich Morin,
Sebastian Rahtz, Joachim Schrod, Elizabeth Tachikawa, Ulrik Vieth, and
Norman Walsh (chair). These members have either years of experience in
maintaining \TeX{} systems or they are active in preparing
distributions for important \TeX{} packages or they are engaged in the
preparation of complete \TeX{} distributions (or all of these points).
So we are reasonably confident that our proposal is no hot air; it is
in use already and we hope that it will be utilized by all important
\TeX{} distributions in the future.
The current TDS draft is available on any CTAN host, in various
formats (\LaTeX{}, \texttt{DVI}, \textsc{PostScript}, etc.) It is
placed in subdirectories of \path|/tex-archive/tds/|. Any feedback to
that draft should be sent by email to \path|twg-tds@shsu.edu| or by
paper mail to the chair of the working group (Norman Walsh, O'Reilly
\& Associates, Inc., 90~Sherman Street, Cambridge, MA~02140, USA)\@.
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% LocalWords: Euro package's Vicki Carlisle MacKay Morin Tachikawa Ulrik
% LocalWords: Vieth tds twg shsu edu
---------------- snip snap ----------------------------------------
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 07 Aug 1995 15:38:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 07 Aug 1995 16:38:01 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: EuroTeX proceedings (fwd)
To: TWG-TDS@SHSU.edu
Message-ID: <807827881.679606.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
joachim,
a few editorial comments ...
panel on ``Why is \TeX{} unusable?'' A basic critic that came up in
^^^^^^ criticism
Over the last 15~months, a TUG working group was busy to prepare a
^^^^^^^^^^^^^^^^^^^
has been busy preparing
fact, when the draft will be accepted, we hope that item~(a), the
^^^^^^^ is
location of implementation-independent files are fixed, locations for
^ ;
files to install. Everybody, who has maintained any system for some
^ don't need comma
time, has stumbled over that problem.)
^ don't need this one either
subdirectory searching already, other implementations will get it
^ ;
So we are reasonably confident that our proposal is no hot air; it is
^^ not
looks good. i'll be there to hear you present it.
my notes are in really bad shape, so unless nobody else volunteers
to summarize the tug'95 panel, i'd rather not.
cheers. -- bb
================================================================================
From owner-twg-tds@shsu.edu Tue, 08 Aug 1995 03:54:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 8 Aug 1995 09:52:14 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508080852.JAA05055@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: EuroTeX proceedings (fwd)
References: <199508071354.PAA13483@spice.iti.informatik.th-darmstadt.de>
Joachim Schrod writes:
> May anybody who was at TUG '95 please summarize the TDS panel/BOF
> there?
It was relatively quiet. Norm presented the TDS, which everybody had
been given copies of, and there was general happines at the concept, I
think. The most significant comment (to my mind) came from Peter
Breitenlohner, who questioned whether the search *was* in fact
genuinely recursive, or could be implemented in other ways. in
essence, the argument is that fancyheadings.sty will *always* be found
at
<root>/tex/latex/fancyheadings/fancyheadings.sty
(silly example, apply an 8+3 algorithm), and we dont permit it to be
in
<root>/tex/latex/fancyheadings/something/fancyheadings.sty
because of our ISO limits on depth. The question is, *do* we mean
this? or can people use subdirectories ad nauseam? I'd argue that
Peter is essentially right, that we dont want and dont permit a
genuinely endless recursive search, but that such a system will find
stuff correctly in our system
there was also discussion about local files, whether they go in the
main TDS tree or in a parallel sparse tree. i think it was agreed that
the latter is preferable.
Don Knuth asked everyone to please start all paths with (Unixified)
.:.. because it was so useful a concept. whether one agrees or not, i
dont think this is our job
Norm, does this correspond with your memories?
Joachim, i think your draft is fine.
my personal view of the situation is that the *principles* of the TDS
are widely accepted and approved, and will be seen widely in the next
year. during that year people will break it in various interesting
ways, and a revision will be needed after experience
the important thing now is that we make a few changes (a ruling on the
Breitenlohner question is needed), taking into account the last couple
of months remarks, and issue the damn thing as version 1.0 in the next
month, with a firm agreement that it will remain unchanged for 6 or 12
months. dont lets let the "draft" label hang on any longer than at all
necessary
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 08 Aug 1995 08:06:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 8 Aug 1995 14:01:45 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508081301.OAA10249@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: EuroTeX proceedings (fwd)
References: <199508071354.PAA13483@spice.iti.informatik.th-darmstadt.de>
Joachim Schrod writes:
> May anybody who was at TUG '95 please summarize the TDS panel/BOF
> there?
I just found my notes, and i see that someone also asked that we
suggest a standard list of environment variable names for TeX-related
tools. I am inclined to agree that an appendix giving a comprehensive
list for people to follow would be no bad thing
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 08 Aug 1995 09:32:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 8 Aug 1995 10:32:02 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508081432.AA05317@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: EuroTeX proceedings (fwd)
Peter is essentially right, that we dont want and dont permit a
genuinely endless recursive search, but that such a system will find
I would say the TDS does not ``require'' a genuinely recursively search,
not that it does not ``want'' or ``permit'' such.
I certainly don't think we should recommend a hack implementation that does
not do real recursion. Better to keep silent on the subject, as we are now.
Ruling? I don't quite understand. Yes, the TDS says the file is in
tex/latex/fancyheadings/fancyheadings.sty. No, we do not recommend
implementors take short cuts and ``know'' about the subdirectory
structure. How does that sound?
there was also discussion about local files, whether they go in the
main TDS tree or in a parallel sparse tree. i think it was agreed that
the latter is preferable.
It's a real pain, either way. In reality, I bet most smallish sites will
just put their files in the main tree. I know I will.
Don Knuth asked everyone to please start all paths with (Unixified)
.:.. because it was so useful a concept. whether one agrees or not, i
dont think this is our job
We can't require it, but this wouldn't be a bad thing to
recommend. (Perhaps in this new environment variable section :-)
issue the damn thing as version 1.0 in the next month,
Norm, have you been keeping a list of the outstanding things to be
resolved? Or do we go back through the mail archives? Will you have time
to start making updates soon?
================================================================================
From owner-twg-tds@shsu.edu Tue, 08 Aug 1995 09:49:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 8 Aug 1995 15:46:38 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508081446.PAA10897@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: EuroTeX proceedings (fwd)
References: <199508081432.AA05317@ra.cs.umb.edu>
> Ruling? I don't quite understand. Yes, the TDS says the file is in
> tex/latex/fancyheadings/fancyheadings.sty. No, we do not recommend
> implementors take short cuts and ``know'' about the subdirectory
> structure. How does that sound?
but why not take a "shortcut", if our number of directory levels means
that the position of fancyheadings.sty *is* fixed? we *dont* need a
recursive search
> It's a real pain, either way. In reality, I bet most smallish sites will
> just put their files in the main tree. I know I will.
until you get your CD version...
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 08 Aug 1995 11:36:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 8 Aug 1995 10:21:33 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508081421.AA05264@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: EuroTeX proceedings (fwd)
I am inclined to agree that an appendix giving a comprehensive
list for people to follow would be no bad thing
I agree. Here's my current list, as a start.
If the meaning of any isn't clear, let me know.
(If I was really motivated, I'd write a draft for the section, but ...)
In addition to these, all my programs use one more font variable, named
for the program: DVIPSFONTS, XDVIFONTS, DVILJFONTS. This overrides
everything else.
KPSE_GF_ENVS "GFFONTS", KPSE_GLYPH_ENVS
KPSE_PK_ENVS "PKFONTS", "TEXPKS", KPSE_GLYPH_ENVS
KPSE_GLYPH_ENVS "GLYPHFONTS", "TEXFONTS"
KPSE_BASE_ENVS "MFBASES", "TEXMFINI"
KPSE_BIB_ENVS "BIBINPUTS", "TEXBIB"
KPSE_BST_ENVS "BSTINPUTS"
KPSE_CNF_ENVS "TEXMFCNF"
KPSE_FMT_ENVS "TEXFORMATS", "TEXMFINI"
KPSE_MEM_ENVS "MPMEMS", "TEXMFINI"
KPSE_MF_ENVS "MFINPUTS"
KPSE_MFPOOL_ENVS "MFPOOL", "TEXMFINI"
KPSE_MP_ENVS "MPINPUTS"
KPSE_MPPOOL_ENVS "MPPOOL", "TEXMFINI"
KPSE_MPSUPPORT_ENVS "MPSUPPORT"
KPSE_PICT_ENVS "TEXPICTS", KPSE_TEX_ENVS
KPSE_TEX_ENVS "TEXINPUTS"
KPSE_TEXPOOL_ENVS "TEXPOOL", "TEXMFINI"
KPSE_TFM_ENVS "TFMFONTS", "TEXFONTS"
KPSE_TROFF_FONT_ENVS "TRFONTS"
KPSE_VF_ENVS "VFFONTS", "TEXFONTS"
KPSE_DVIPS_CONFIG_ENVS "TEXCONFIG"
KPSE_DVIPS_HEADER_ENVS "DVIPSHEADERS"
================================================================================
From owner-twg-tds@shsu.edu Tue, 08 Aug 1995 15:24:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 8 Aug 1995 16:23:47 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508082023.AA07710@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: EuroTeX proceedings (fwd)
but why not take a "shortcut", if our number of directory levels means
that the position of fancyheadings.sty *is* fixed? we *dont* need a
recursive search
I'd put it differently: I'd say we don't *need* a recursive search.
It still seems like the best thing to implement to me. What will happen
when the CD-ROM standard changes and we don't have to live with these
stupid restrictions? Why shoot ourselves in the foot by recommending an
inferior implementation?
Anyway, what exactly is Breit. planning? He wants to write something
that will fail if fancyheadings.sty is not in the appointed place, but
in a subdirectory thereof? Why? What's the gain?
Note I'm not talking about *requiring* a completely recursive
search. Any algorithm that finds the files in the places we say is
acceptable within the TDS world, I suppose. It's just a question of
what we recommend. I suggest we either be silent on this issue or
recommend a true recursive search.
> It's a real pain, either way. In reality, I bet most smallish sites will
> just put their files in the main tree. I know I will.
until you get your CD version...
I'll make a link farm.
================================================================================
From owner-twg-tds@shsu.edu Tue, 08 Aug 1995 15:31:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 8 Aug 1995 10:24:24 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508081424.AA05276@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: EuroTeX proceedings (fwd)
we suggest a standard list of environment variable names for TeX-related
Sorry, didn't see this before. As for what we should suggest, I wouldn't
``suggest'' the TEXPKS and TEXBIB envvars in the previous
list. I'd also love to replace TEXPOOL/MFPOOL/MPPOOL with a single
TEXMFPOOL, but I don't think that's feasible at this point.
================================================================================
From owner-twg-tds@shsu.edu Wed, 09 Aug 1995 13:59:12 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508091858.UAA08090@spice.iti.informatik.th-darmstadt.de>
Subject: Re: EuroTeX proceedings (fwd)
To: TWG-TDS@SHSU.edu
Date: Wed, 9 Aug 1995 20:58:40 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> Anyway, what exactly is Breit. planning? He wants to write something
> that will fail if fancyheadings.sty is not in the appointed place, but
> in a subdirectory thereof? Why? What's the gain?
In my personal opinion, Peter plans nothing. The TeX port he maintains
does full recursive directory searching since years. Peter just loves
to argue, as everybody who has spent an evening with him knows. (That
can be fun, and that can be horrible if you want to flirt with the
woman besides you... :-)
I had discussions on this topic three times with him; every time I've
told him that the TDS draft specifies a directory structure and not
any algorithm to handle that. It is descriptive and not prescriptive.
(I hope I got these English words right. ;-)
As with every standard, it is reasonable practice to check if the
descriptive specs may be implemented effectively enough. That has been
done.
I don't have the TDS draft here, perhaps we should emphasize the
above point more strongly. I would vote against any recommendation
for any algorithm. (You remember my insistence on good algorithms? I
would demand to fix caching and search tree pruning in the standard.
And then the whole topic of font layout is on the table again. You
won't open that box, will you? :-)
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, 09 Aug 1995 14:01:34 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508091901.VAA08101@spice.iti.informatik.th-darmstadt.de>
Subject: Re: EuroTeX proceedings (fwd)
To: TWG-TDS@SHSU.edu
Date: Wed, 9 Aug 1995 21:01:01 +0200 (MESZ)
Content-Type: text
sebastian wrote:
>
> the important thing now is that we make a few changes (a ruling on the
> Breitenlohner question is needed), taking into account the last couple
> of months remarks, and issue the damn thing as version 1.0 in the next
> month, with a firm agreement that it will remain unchanged for 6 or 12
> months. dont lets let the "draft" label hang on any longer than at all
> necessary
I would prefer to wait until Arnheim has passed. (Partly for
political reasons, there are Europeans who want to be asked. They
won't have special answers or demands, but they want to be asked...)
But we could start to incorporate the requested changes already, to
publish the fixed document soon after Arnheim.
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, 09 Aug 1995 23:32:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 9 Aug 1995 17:32:17 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508092132.AA19966@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: EuroTeX proceedings (fwd)
told him that the TDS draft specifies a directory structure and not
any algorithm to handle that. It is descriptive and not prescriptive.
(I hope I got these English words right. ;-)
You did. I think we all agree on this. If Peter or someone else would
like to recommend wording changes, fine. If not, I am not opposed to
letting the current draft stand (in this area).
================================================================================
From owner-twg-tds@shsu.edu Thu, 10 Aug 1995 04:17:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 10 Aug 1995 09:02:02 +0100
Message-ID: <9508100802.AA13648@philips.nl>
From: c753330@nlzcl1.decnet.philips.nl (Alex Kok)
Reply-To: TWG-TDS@SHSU.edu
To: "twg-tds@shsu.edu"@NLZMS.decnet.philips.nl
CC: C753330@nlzcl1.decnet.philips.nl
Subject: Experience with TWG-TDS
Dear TWG-TDS people,
Having heard and read about TDS, I thought that the best way to comment on TDS
is to implement it and report the findings. I have done so. My configuration is
a MicroVAX II running OpenVMS V6.2, TeX, Version 3.1415 [PD VMS 3.6], LaTeX2e
<1994/12/01> patch level 3. Page numbers refer to the PostScript version of the
TDS document (v0.98) as available on CTAN.
Of course, I found some things that seemed unclear or inconsistent. I also have
suggestions for improvement of the document, and the occasional typo. Some of
the additions I suggest may not be appropriate for TDS itself, but please
consider adding them in an appendix or a separate "TDS user guide" for
non-TeXperts. After all, the TDS document states it "...will also help TeX
users..." (Introduction, last line). There are many persons who just want to
get LaTeX to work, without having to delve into the details of MF, fonts, font
files, etc. The current TDS document is not understandable to them (I know, I'm
one of them).
I have done this kind of thing before, and for some items, I fully expect
reactions like "Wow, this guy is negative.", "Hey, yes, but everybody knows
such-and-such!" and "Yeah, but this is about TDS and TDS has nothing to do, in
principle, with specific applications like LaTeX!". In this case, I urge you
consider my points to be real, as they are to me. Everybody does NOT know.
Quite a few people want just LaTeX, and consider the rest unavoidable hassle.
Regards, and keep up the good work!
Alex Kok (c753330@nlzcl1.decnet.philips.nl)
====
TDS is a major improvement over previous practice with files scattered all over
the place in an inconsistent manner. Some people seem to object to the way TDS
scatters files. I do not find the "TDS scattering" of files (e.g. of packages:
in the TeX subtree and the doc subtree; and of fonts: in the fonts/pk and
fonts/tfm subtrees) objectionable; I'd rather say it is unavoidable. I'm glad a
decision has been made!
Suggestion: Add a list of file types and where to put them according to TDS.
This list should include these file types at least: .afm .base .cfg .clo .cls
.dat .def .drv .dtx .el .err .exe .fd .fmt .ini .ins .ist .lis .ltx .map .mf
.pk .pool .ppl .pro .ps .sty .tex .tfm .vf. This is to clear things up for types
like me who are not TeXperts and have never used MetaFont, Web, Tangle, Weave
etc. and do not know what all these file types are for.
Suggestion: Add a list of "packages" (like psnfss, lw35nfss, babel, tools,
graphics) and where to put them. I for one cannot say if e.g. Babel should go
in tex/generic/babel or tex/latex/babel.
It is unclear to me what is to be considered source in the case of LaTeX. There
are .DTX and .LTX files. Both can be considered source code, and the .DTX files
are ALSO documentation, hence should go in the doc tree...? This specific
example needs clarification.
I suggest to NOT clutter up the texmf directory with dvi driver program
directories, but to add a layer e.g. texmf/dvidrivers. This would lead to e.g.
texmf/dvidrivers/dvips/ (well, "dvidrivers" is too long, obviously, so you can
see I use a VMS system).
Why is there no indication where the format files go (e.g. latex.fmt)?? TDS
seems to shrug it off somewhere saying it is something local. If TDS does not
specify it, TDS should say explicitly that it is up to the TeX administrator.
Page 3, last line reads: "command Commands are typeset in italics" but the word
"command" is NOT set in italics but in roman (typewriter font).
Page 3, section 1.2: "packages": it is most unfortunate that this term is
different from what people are used to. This is confusing! Certainly for "the
TeX user"! I find it astonishing that you *acknowledge* that it is confusing
instead of changing this. Just as bad as Unix documentation (well, almost :-).
And now the single most confusing paragraph of the whole document:
Page 6, 2nd/3rd line from bottom: "configuration files" and where to put them
is in conflict with page 15: "config/ configuration files for format..."
Page 6, last paragraph: the terms "directories" and "subdirectories" are used
for (if I understand correctly) the same thing: a subdirectory of /texmf/.
Confusing.
Page 6, last paragraph: "... implementations ... in their own directories.".
What is an implementation other than a set of programs including binaries?
Should they not go in /texmf/bin/ or outside the texmf tree as specified on
page 7?
Page 7: The bin directory description may lead to different interpretations. It
does not make entirely clear where the executables go, and this is worse if
applied to "scripts" (e.g. Unix shell scripts, VMS DCL programs, MSDOS .BAT
files) like maketexpk. It leads to this:
Digital Unix executables: bin/axp
OpenVMS/AXP executables: bin/axp (oh dear, this is the same directory!)
Windows/NT AXP executables: bin/axp (oh dear, this is the same directory!)
OpenVMS VAX executables: bin/vax
OpenVMS VAX scripts: bin/? (common to VAX and AXP; I use bin/vms)
Unix scripts: bin/unix ?
HPUX specific scripts: bin/hpux ?
HPUX executables: bin/hpux or bin/parisc ?
The TDS is as good as useless here. I suggest to make this bit more specific or
to leave it out (almost) entirely (e.g. "the bin subtree can be used for
binaries as the local TeX admin sees fit."). Add something for the scripts
(strictly speaking, they are not covered in TDS as it is now). Maketexpk is
indispensible! An possibility would be to use bin/os for operating system
specific things (e.g. bin/vms/, bin/unix/, bin/hpux/) with optional
subdirectory for hardware architecture (e.g. bin/vms/axp/, bin/vms/vax/).
Page 7: A "specification" like TDS should SPECIFY, not say things like
"administrators may wish..." as in section 2.4.
Page 7, section 3: refers to mft files. What on earth are they? Never heard of
them. I have checked several TeX installations but I could not find any *.mft
files (there are *.tfm and *.fmt files, of course).
Page 7, section 3, bottom paragraph: doesn't plain.tex belong in the source
tree? An explanation or change is in order here.
Page 8, section 4: "As with macros, fonts need ...". TDS is about FILES not
FONTS and a non-TeXpert needs to read "font files" here, or an explanation what
a "font" is in relation to TDS (during implementation I have been forced to
learn about .gf, .pk, .tfm, .vf ...).
Page 12: "man is reserved for manual pages (Unix-style documentation)." What is
so special about Unix that it gets mentioned specifically? TeX runs on more
platforms than Unix. Consider adding "vmshelp is reserved for VMS help
libraries" and similar for other OSs.
Page 15, section 10: "binaries, by system type" is called "optional". I think
that a number of other things are also optional, e.g. some sites do not need
Metafont (just use LaTeX, no math, PS fonts), others do not need LaTeX (use
Metafont and plain TeX). This calls for more consistency.
Page 15, Section 10: I do not think DVIPS is a TeX application. It is a DVI
driver. AMSTeX, SliTeX, and LaTeX are TeX applications. I suggest to change the
wording.
Page 19, 8th line from below: "availble" should read "available". Don't you
guys use a spelling checker :-?
Page 20: The Email address of Sebastian Rahtz is incorrect (as you know
probably better than me). I have: s.rahtz@elsevier.co.uk
That's all folks!
================================================================================
From owner-twg-tds@shsu.edu Thu, 10 Aug 1995 05:53:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 10 Aug 1995 12:44:03 +0200
Message-ID: <9508101044.AA06365@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: Experience with TWG-TDS
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
Akex Kok wrote:
> Dear TWG-TDS people,
> Of course, I found some things that seemed unclear or inconsistent. I also have
> suggestions for improvement of the document, and the occasional typo. Some of
> the additions I suggest may not be appropriate for TDS itself, but please
> consider adding them in an appendix or a separate "TDS user guide" for
> non-TeXperts. After all, the TDS document states it "...will also help TeX
> users..." (Introduction, last line). There are many persons who just want to
> get LaTeX to work, without having to delve into the details of MF, fonts, font
> files, etc. The current TDS document is not understandable to them (I know, I'm
> one of them).
Thanks for your useful comments and suggestions. Let me try to answer a few of them:
> Suggestion: Add a list of file types and where to put them according to TDS.
> This list should include these file types at least: .afm .base .cfg .clo .cls
> .dat .def .drv .dtx .el .err .exe .fd .fmt .ini .ins .ist .lis .ltx .map .mf
> .pk .pool .ppl .pro .ps .sty .tex .tfm .vf. This is to clear things up for types
> like me who are not TeXperts and have never used MetaFont, Web, Tangle, Weave
> etc. and do not know what all these file types are for.
I think this was discussed, but the plan to produce a file format appendix was
never put into practice for the present TDS draft. If I remember correctly,
Norm even obtained permission from his publisher to reproudce the relevant
appendix from ``Making TeX work'' in the TDS draft, but I'm afraid it doesn't
list *all* file extensions. (Besides your list above isn't complete either.)
Correlating the file format extensions with a hint where they should go seems
a very good idea to me.
> Suggestion: Add a list of "packages" (like psnfss, lw35nfss, babel, tools,
> graphics) and where to put them. I for one cannot say if e.g. Babel should go
> in tex/generic/babel or tex/latex/babel.
Good question. I have installed Babel in /tex/generic/babel, because it's supposed
to be generic, but I've put a symbolic link into tex/latex/babel, because it's
distributed on CTAN below macros/latex/packages/babel. (Of course, this assumes
that you have symbolic links. If not you'll have to decide either way.)
> It is unclear to me what is to be considered source in the case of LaTeX. There
> are .DTX and .LTX files. Both can be considered source code, and the .DTX files
> are ALSO documentation, hence should go in the doc tree...? This specific
> example needs clarification.
I think it was agreed that .DTX files are considered source files even thogh
they also contain documentation. .DVI or .PS files produced from .DTX files
for viewing or printing as online doucumentation should got in the doc tree.
The .LTX are produced by stripping the documentation from the .DTX files.
Since they are used to generate the LaTeX format the .LTX files belong into
the tex tree, i.e into tex/latex/base, where TeX searches for the files.
> I suggest to NOT clutter up the texmf directory with dvi driver program
> directories, but to add a layer e.g. texmf/dvidrivers. This would lead to e.g.
> texmf/dvidrivers/dvips/ (well, "dvidrivers" is too long, obviously, so you can
> see I use a VMS system).
I think this depends on how many DVI drivers use auxilliary files that need
to be stored somewhere in the texmf tree. dvips uses quite a number of
configuration files and encoding files whereas other drivers might not.
> Why is there no indication where the format files go (e.g. latex.fmt)?? TDS
> seems to shrug it off somewhere saying it is something local. If TDS does not
> specify it, TDS should say explicitly that it is up to the TeX administrator.
Hmm, I thought it was mentioned somewhere that this is implemntation-specific,
i.e. left to the implementor of the TeX distribution for specific platform.
> Page 6, last paragraph: "... implementations ... in their own directories.".
> What is an implementation other than a set of programs including binaries?
> Should they not go in /texmf/bin/ or outside the texmf tree as specified on
> page 7?
I think "implentation" includes binaries as well as batch files or shell scripts,
pool files, configuration files for path searching, and even format and base files
that are machine-architecture dependent.
> Page 7, section 3: refers to mft files. What on earth are they? Never heard of
> them. I have checked several TeX installations but I could not find any *.mft
> files (there are *.tfm and *.fmt files, of course).
MFT is a utility program for pretty-printing METAFONT source files. *.mft files
are files that control how certatin keywords are formatted. The Unix TeX
implementation searches for them in the tex subtree, but I think it was agreed
that it would be cleaner to introduce another top-level directory texmf/mft
for these files. For more than 99% of the average TeX users this will be
totally uninteresting and irrelevant, of course.
> Page 12: "man is reserved for manual pages (Unix-style documentation)." What is
> so special about Unix that it gets mentioned specifically? TeX runs on more
> platforms than Unix. Consider adding "vmshelp is reserved for VMS help
> libraries" and similar for other OSs.
I think it's simply that the Unix TeX implentation usually comes with man pages
that focus on the description of command line options, environment variables
and the location of some important files, whereas the status of system-specific
documentation of other TeX implementations isn't that clear. Are the VMS help
libraries part of the standard distribution or are they contributed documentation
from other sources?
> Page 15, section 10: "binaries, by system type" is called "optional". I think
> that a number of other things are also optional, e.g. some sites do not need
> Metafont (just use LaTeX, no math, PS fonts), others do not need LaTeX (use
> Metafont and plain TeX). This calls for more consistency.
I think the "optional" means that implementors are free to put binaries and
other implementation-specific stuff outside the texmf tree if they wish.
And by the way, if you want to run automatic font generation with MakeTeXPK,
METAFONT is definitely needed and no longer optional.
> That's all folks!
Thanks again for your comments. I think we definitely need such detailed
feedback as yours that points out the weak points, so that we can fix them.
Cheers,
Ulrik Vieth.
================================================================================
From owner-twg-tds@shsu.edu Fri, 11 Aug 1995 05:08:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 11 Aug 1995 11:01:32 +0100
Message-ID: <9508111001.AA13626@philips.nl>
From: c753330@nlzcl1.decnet.philips.nl (Alex Kok)
Reply-To: TWG-TDS@SHSU.edu
To: "twg-tds@shsu.edu"@NLZMS.decnet.philips.nl
CC: C753330@nlzcl1.decnet.philips.nl
Subject: Re: Experience with TWG-TDS
Dear all,
(whoever you are -- I don't know who's on the mailing list) On request of Ulrik
Vieth I send my reply to his mail to the twg-tds mailing list. It is included
below. He already answered some of my questions.
Regards, Alex Kok (c753330@nlzcl1.decnet.philips.nl)
====
Dear Ulrik,
You wrote:
> Good question. I have installed Babel in /tex/generic/babel, because it's supposed
> to be generic, but I've put a symbolic link into tex/latex/babel, because it's
> distributed on CTAN below macros/latex/packages/babel. (Of course, this assumes
> that you have symbolic links. If not you'll have to decide either way.)
Links are not anything to use in a platform-independent standard like
TDS is supposed to be. Unix has it, VMS has something similar that the
supplier advises not to use (and most VMS people hardly know about). The
rest I don't know.
> I think it was agreed that .DTX files are considered source files even thogh
> they also contain documentation. .DVI or .PS files produced from .DTX files
> for viewing or printing as online doucumentation should got in the doc tree.
> The .LTX are produced by stripping the documentation from the .DTX files.
> Since they are used to generate the LaTeX format the .LTX files belong into
> the tex tree, i.e into tex/latex/base, where TeX searches for the files.
Interesting. I'll check if I did it right.
> Hmm, I thought it was mentioned somewhere that this is implemntation-specific,
> i.e. left to the implementor of the TeX distribution for specific platform.
That's right. But I disagree, I think they merit specific mention. After
all, no installation can do without them. Is there a specific reason NOT
to specify it, apart from its being generated locally? I have simply
used /texmf/tex/formats/ and I can't think what's wrong with that. Would
also ensure cross-platform consistency. In future it is well possible
that multiple platforms will use the same installation, so I think it
would be best to prepare for that.
> I think it's simply that the Unix TeX implentation usually comes with man pages
> that focus on the description of command line options, environment variables
> and the location of some important files, whereas the status of system-specific
> documentation of other TeX implementations isn't that clear. Are the VMS help
> libraries part of the standard distribution or are they contributed documentation
> from other sources?
The VMS TeX help library is part of the DECUS TeX distribution
(available from CTAN) and of much help (at least to me). This is the
"standard distribution" for VMS. It includes the description of command
line options, logical names (comparable to Unix environment variables)
(the location of important files is taken care of in the installation
procedure, this is automatic. Alas, NOT TDS-compliant :-( ).
Is there no member in TWG-TDS who knows about VMS??? The remark you made
about symbolic links also gave that impression. Do you need a
volunteer?
> Thanks again for your comments. I think we definitely need such detailed
> feedback as yours that points out the weak points, so that we can fix them.
I'm happy to contribute. I'm looking forward to the next version of TDS.
Any idea when it can be expected?
Regards, Alex Kok (c753330@nlzcl1.decnet.philips.nl)
================================================================================
From owner-twg-tds@shsu.edu Fri, 11 Aug 1995 13:57:58 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508111855.UAA17297@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Experience with TWG-TDS
To: c753330@nlzcl1.decnet.philips.nl
Date: Fri, 11 Aug 1995 20:55:18 +0200 (MESZ)
CC: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Content-Type: text
[As Ulrik has reacted on a few points, I react to other ones here.]
Alex wrote:
>
> Suggestion: Add a list of "packages" (like psnfss, lw35nfss, babel, tools,
> graphics)
Please note your use of `package' here, I'll come back to that below.
> and where to put them. I for one cannot say if e.g. Babel should go
> in tex/generic/babel or tex/latex/babel.
That's a nice example -- it depends on the version.
3.4 goes in tex/generic/babel,
3.5 goes partly in tex/generic/babel, partly in tex/latex/babel.
That's because 3.4 could be used with plain TeX, whereas 3.5 is
LaTeX-specific. When 3.6 can be used with plain TeX again, it will be
moved back to tex/generic/babel. :-)
> I suggest to NOT clutter up the texmf directory with dvi driver program
> directories, but to add a layer e.g. texmf/dvidrivers.
Why? What's so special about dvi drivers that doesn't hold for
MakeIndex or BibTeX? I think the general rule ``each application gets
its directory'' a very good one.
> Page 3, section 1.2: "packages": it is most unfortunate that this term is
> different from what people are used to. This is confusing! Certainly for "the
> TeX user"!
*No*. _This_ usage is the one that people are used to, as a term to
denote a couple of files that do something. A unit of distribution,
most often. That LaTeX 2e used that term for something completely
different (for a module), is something one should make them pay a
bottle of wine for each TeX user. The selection of this term caused
more confusion than any other change introduced by LaTeX.
(You pushed a button, in case you didn't notice... :-)
> Page 7: A "specification" like TDS should SPECIFY, not say things like
> "administrators may wish..." as in section 2.4.
No. It's very usual for standards that they recommend things. In
fact, that's done in _every_ standard I've ever read.
In particular for the case at hand, binaries, it's problematic. The
TDS will not specify the location of binaries, that's a topic where
many adminitrators have local policies. Binaries are on the
borderside of the TDS domain anyhow, as they are not
implementation-independent. The decision to use bin/ and the
structure below is up to an administrator.
> Page 7, section 3, bottom paragraph: doesn't plain.tex belong in the source
> tree? An explanation or change is in order here.
Can you explain where you got the impression from that TeX macro
files belong in the source/ tree? We might need to improve that.
Currently, the source/ item tells: This includes both traditional
program sources and LaTeX dtx sources. Macro files are not mentioned
here.
> Page 12: "man is reserved for manual pages (Unix-style documentation)." What is
> so special about Unix that it gets mentioned specifically? TeX runs on more
> platforms than Unix. Consider adding "vmshelp is reserved for VMS help
> libraries" and similar for other OSs.
The person who puts together a TDS-compliant VMS-TeX distribution has
to tell us the name of the directory he wants there. As long as this
does not happen, we won't fix the name... I think, an additional
sentence that outlines that new system-specific directories might be
introduced here is needed.
> Page 15, section 10: "binaries, by system type" is called "optional". I think
> that a number of other things are also optional, e.g. some sites do not need
> Metafont (just use LaTeX, no math, PS fonts), others do not need LaTeX (use
> Metafont and plain TeX). This calls for more consistency.
`Optional' is here meant in the sense of `the specification is not
definitive here'. Binaries are by definition outside the strict target
domain of TDS.
> Page 15, Section 10: I do not think DVIPS is a TeX application. It is a DVI
> driver. AMSTeX, SliTeX, and LaTeX are TeX applications.
Hmm, in all texts I know an application is something that comes with a
program. No, IMO AMSTeX, SliTeX, and LaTeX are not TeX applications,
they are TeX formats.
I think we need a glossary, in particular, as many of our readers are
not from an English background.
------------------------------------------------------------
The following points are actually mentioned in the TDS draft:
> It is unclear to me what is to be considered source in the case of LaTeX. There
> are .DTX and .LTX files. Both can be considered source code, and the .DTX files
> are ALSO documentation, hence should go in the doc tree...? This specific
> example needs clarification.
p. 7, at the introduction of source/.
LTX files are not source files, btw. They are TeX macro files.
> Why is there no indication where the format files go (e.g. latex.fmt)??
p. 6, they are stored in the directories reserved for specific TeX
implementations (i.e., TeX ports). The structure there is made up by
the person who does the port, it's not our beef to get in conflict
with developers.
tex/formats is impossible, btw. Formats are not implementation-
independent.
------------------------------------------------------------
> That's all folks!
Thanks for your detailed comments. They are very helpful.
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, 11 Aug 1995 14:06:49 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508111904.VAA16299@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Experience with TWG-TDS
To: TWG-TDS@SHSU.edu
Date: Fri, 11 Aug 1995 21:04:40 +0200 (MESZ)
CC: c753330@nlzcl1.decnet.philips.nl
Content-Type: text
Ulrik wrote:
>
> > Suggestion: Add a list of "packages" (like psnfss, lw35nfss, babel, tools,
> > graphics) and where to put them. I for one cannot say if e.g. Babel should go
> > in tex/generic/babel or tex/latex/babel.
[The actual answer is in my previous mail.]
> Good question. I have installed Babel in /tex/generic/babel, because it's supposed
> to be generic, but I've put a symbolic link into tex/latex/babel, because it's
> distributed on CTAN below macros/latex/packages/babel. (Of course, this assumes
> that you have symbolic links. If not you'll have to decide either way.)
For heavens sake, no.
As LaTeX will search the generic area, too, it is not necessary to put
any special symbolic link or other things in the latex/ area for
generic packages. Where they are on CTAN is irrelevant for that decision.
The problem with babel is the ``is supposed to be generic''. That's
not the parameter of decision, it must be ``is generic''. The *.sty
files are not generic and therefore must not be placed in generic/.
The *.def files are generic and are placed in generic/.
> The .LTX are produced by stripping the documentation from the .DTX files.
I know that Ulrik knows it, but I want to emphasize it: There's more
to it than stripping documentation. LTX files are not LaTeX sources
any more, they are the macro files (objects) produced by compiling
(some) DTX files.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 11 Aug 1995 14:21: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: <199508111919.VAA16349@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Experience with TWG-TDS
To: TWG-TDS@SHSU.edu
Date: Fri, 11 Aug 1995 21:19:16 +0200 (MESZ)
CC: c753330@nlzcl1.decnet.philips.nl
Content-Type: text
Alex wrote:
>
> > Hmm, I thought it was mentioned somewhere that this is implemntation-specific,
> > i.e. left to the implementor of the TeX distribution for specific platform.
>
> That's right. But I disagree, I think they merit specific mention. After
> all, no installation can do without them. Is there a specific reason NOT
> to specify it, apart from its being generated locally?
It's a matter of the TeX port. The TeX port has an area in the TDS and
is asked to place the FMT/Base files there. Different TeX ports will
use different sub-structures, as they have different demands. That's
the realm of a developer, not of the TDS.
> I have simply
> used /texmf/tex/formats/ and I can't think what's wrong with that.
That does not work if you use it for mutliple platforms. You can't use
a VMS FMT-file on Unix or on DOS. And it is important that we can use
the same texmf tree on many platforms. (E.g., mounted via NFS,
Netware, etc.) The current layout allows for such cross-platform
mounts. (It works, I use it this way for both Unix and DOS systems.)
> Is there no member in TWG-TDS who knows about VMS??? The remark you made
> about symbolic links also gave that impression.
There are several VMS folks on the discussion list. We have feedback
from Christian Spieler, Phil Taylor can be mentioned as a True
Believer as well. As for the direct members, I worked for six years
under VMS, two years as a VMS system administrator for a VAX cluster;
I hope that qualifies as `knows'. :-)
Again, somebody involved in the VMS-TeX-distribution must name the
specific directory he needs.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Sun, 13 Aug 1995 15:45:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun,13 Aug 95 17:54:41 BST
From: David.Rhead@vme.ccc.nottingham.ac.uk
Reply-To: TWG-TDS@SHSU.edu
Subject: Examples files for end-users
To: twg-tds@shsu.edu
Message-ID: <13_Aug_95_17.54.41.A14BBE@VME.NOTT.AC.UK>
Version 0.98 of the directory structure draft does not seem consistent
in its treatment of example files.
* Near the bottom of page 7, it envisages that Knuth's story.tex would
live in texmf/tex/plain/story.tex
* However, on page 13, it envisages that a Martian example would live in
texmf/doc/latex/martian/example.tex.
(I'm not clear where it envisages that example files such as LaTeX's
sample2e.tex and small2e.tex would fit into the 0.98 scheme.)
Doesn't the argument used for documentation apply equally to examples?
I.e.,
a separate, but parallel, structure for examples would (1) keep the
examples together and (2) make it as straightforward as possible
for users to find the particular examples they are after.
It might be suggested that the role of texmf/doc should be expanded to
include examples. (This view seems implicit in the Martian example.) I'm
skeptical about this, since the simple .tex files to be used as examples of
a particular point would often share directories with internally
complicated .tex files that act as documentation. It would be better to
keep
stuff that the novice can study, and copy as a starting point for
his/her .tex file
separate from
stuff whose gobbledegook the novice doesn't need to understand (they
might just as well have been given a .dvi file), since the idea is
just that the novice blindly sticks it through (La)TeX, and then
prints it and reads it, ignoring whatever complications were used to
produce it.
E.g., on one of our systems, we have a LaTeX examples directory that
contains subdirectories like:
bibtex - a minimal (but complete) example that shows the .tex and .bib
files involved in the LaTeX+BibTeX procedure
diy-bibs - a minimal/complete example that shows the use of \cite and
thebibliography for both author-date and `reference by number'
CVs - curriculum vitae. The idea is the novice copies a file from
here and replaces the example details by their own details.
lamport - sample2e.tex and small2e.tex
class-test - files for use when testing .cls files
tables - illustrations of how to get details (e.g., footnotes) right
in and around tables
thesis - a `thesis kit', containing a root file and some \included
chapter files. The idea is that the novice goes, e.g.,
cp * $HOME/thesis/.
and thus gets a ready-made `skeleton thesis' in $HOME/thesis.
They can start on their own thesis by changing the text in
one of the example chapter files.
title-pages - unfortunately, it doesn't seem easy to provide a single
title-page example as part of the thesis kit, so this
directory contains examples that meet the requirements
of different departments, faculties, etc. The student
just has to copy a suitable example and change the text.
other - solutions to odd typesetting problems that don't merit
a directory of their own (e.g., celestial co-ordinates for
astronomers).
In the next draft, how about saying the following?
* Analogously to
texmf/doc/category
there should be
texmf/examples/category
* Knuth's story.tex would go in
texmf/examples/tex
* Lamport's sample2e.tex and small2e.tex would go in
texmf/examples/latex
* the Martian example.tex would go in
texmf/examples/latex/martian
* local example .tex and (perhaps) .bib files that illustrate the
subleties needed to produce LaTeX-ed documents in the house-style of
O'Reilly & Associates (page 7 of version 0.98) would go in `a separate
tree' under
oratex/examples
David Rhead
University of Nottingham
david.rhead@nottingham.ac.uk
================================================================================
From owner-twg-tds@shsu.edu Sun, 13 Aug 1995 15:45:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun,13 Aug 95 20:27:35 BST
From: David.Rhead@vme.ccc.nottingham.ac.uk
Reply-To: TWG-TDS@SHSU.edu
Subject: Roles of texmf and oratex (or analogue)
To: twg-tds@shsu.edu
Message-ID: <13_Aug_95_20.27.35.A14BCA@VME.NOTT.AC.UK>
Philosophically, there seem to be some difficulties with version 0.98 of
the draft along the
unofficial, local, mortal, site-dependent, us, ... , standard,
God-given, official, site-independent, Them
spectrum.
Continuing the example on page 7 of the draft, the end-user seeing the
division into /usr/local/oratex and /usr/local/texmf might be led to
believe that:
texmf - is all official God-given stuff and is bound to be right
oratex - is `just your local TeX administrator', who is human and fallible.
In fact:
* the individual stuff under texmf is produced by fallible humans
* the collection under texmf is likely to be put together by people
who have powerful software for collecting files into directories,
but have little time to look at what is in those files. The CTAN
people don't have time to `exert editorial control', to `get
stuff refereed', or to weed out `dead wood': this is likely
to be reflected in what is found under texmf.
E.g.
* suppose that under tex/doc/latex there is something that purports to
be an introduction to LaTeX, but which overemphasises visual
formatting. No-one is likely to delete it. Will anyone have time to
`balance' it by putting a read.me file in the same directory saying
`if you want to use LaTeX, you really ought to go and buy the Lamport
and/or Goossens et al. books!'?
* Somewhere under texmf, there is likely to be a FAQ file that -- about
"how to get a double-spaced thesis" -- says "argue fiercely with the
people who draft the outdated regulations". Somewhere else under
texmf, there is likely to be a .cls file that contradicts the FAQ by
meekly aiming to produce a double-spaced thesis.
* Whether something is under the oratex or texmf tree may depend on how
shy or otherwise the O'Reilly people are about putting stuff into the
public domain. But once under texmf, it may acquire an mystique --
even though it's just the same as it was under oratex.
Version 0.98 seems to imply a rigid division into
site-dependent versus standard
whereas I think reality has elements of a gradual spectrum.
On the other hand, I appreciate that you've got to decide something, and
that directory structures require files to be in one directory rather than
another. They can't sit on the boundary.
----------
Secondly, there are practical questions about things like dvips's
config.ps. (I appreciate that you're primarily concerned with macros,
fonts and implementation-independent TeX files, but there is "the matter of
practicality". There are also other things that need local configuration
files: maybe if I thought long enough I could think of one that was more to
do with "macros, fonts and implementation-independent TeX files".)
Suppose that config.ps arrives at a site in a form that is suitable for
"Karl and Kathy's printer" with a comment saying "edit at will".
Would the local administrator (e.g., at O'Reilly) hack at it under
texmf
or would s/he leave the copy under texmf as it is and put the
"editted at will" version under
oratex
?
Similarly (and this is more to do with macros, fonts and
implementation-independent TeX files), what happens if someone at O'Reilly
wants to submit a paper to a journal whose .cls file is not available
under texmf (in web2c or on the Prime Time CD). Suppose that the
journal-publisher supplies O'Reilly with the pre-print .cls file.
Faced with this `neither local nor standard' .cls file, does the local
administrator put it under
texmf/tex/latex/misc
or under
oratex/tex/latex/misc
?
----------
I wonder whether the practicalities of CDs give a de facto answer to
questions such as the above.
With CDs, one has the option of `running it off the CD', but doesn't have
the option of hacking at the files on the CD.
Thus:
* stuff under texmf is to be regarded as a "drop-in distribution
package" (as you say on page 15). Although reputable, it was compiled
by a human who had limited time for "editorial control". It is their
personal judgement of what should go on. To give a consistent
treatment of stuff supplied on CD and stuff supplied otherwise, the
stuff under texmf is not to be altered locally. (E.g., config.ps
stays as supplied for Karl and Kathy's printer.)
Different humans (Karl Berry, the NTG, ... ) will judge differently
about what is supplied to "drop in", but whatever it is will keep to
the TDS.
* local stuff is to go under the local analogue of oratex, which goes on
the search path before texmf. (E.g., the config.ps that is actually
used is below oratex, and it gets found before the Karl/Kathy one.)
* when a new distribution comes along (e.g., new NTG CD or new web2c),
all local hacks to the previous distribution are to be found under the
local analogue of oratex. The local administrator should check whether:
- bug-fixed software under oratex can be deleted, because the
bug-fix has at last made it into the "drop-in distribution" and
hence into texmf
- local hacks at stuff in texmf (e.g., dvips's config.ps) need
re-doing, because the version in the "drop-in distribution" has
changed.
* web2c gets regarded as read-only (even if it isn't on a CD). The
local administrator doesn't put extra .cls files under
texmf/tex/latex/misc
(where they might get clobbered by some future web2c). S/he puts
extra .cls files under
oratex/tex/latex/misc
(where they won't get clobbered if the web2c distribution is replaced).
* the contents of the local tree (oratex, or whatever) will depend to
some extent on what "drop-in distribution" someone relies on, since
the contents of the texmf tree will depend to some extent on the
judgement of whoever is assembling the "drop-in distribution".
----------
Could the next draft clarify what you envisage about such matters (whether
it is along the lines of the "de facto answer" I mentioned above, or along
some other lines)?
David Rhead
================================================================================
From owner-twg-tds@shsu.edu Mon, 14 Aug 1995 10:17: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: <199508141515.RAA14510@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Examples files for end-users
To: TWG-TDS@SHSU.edu
Date: Mon, 14 Aug 1995 17:15:12 +0200 (MESZ)
CC: david.rhead@vme.ccc.nottingham.ac.uk (David Rhead)
Content-Type: text
Concerning the examples/ proposal of David:
I think, examples are an integral part of documentation and should
therefore go in the doc/ area. If they contain of more than one file,
a subdirectory in the respective doc/-directory might be in order. But
that decision should be made by the documentation author, not by us.
We shouldn't spread the files targeted to human readers widely.
David wrote:
>
> * Near the bottom of page 7, it envisages that Knuth's story.tex would
> live in texmf/tex/plain/story.tex
IMO, that file should go in doc/plain/. (Or doc/plain/base/?)
> (I'm not clear where it envisages that example files such as LaTeX's
> sample2e.tex and small2e.tex would fit into the 0.98 scheme.)
doc/latex/base/ (again IMO). They are no macro files and thus don't
belong in tex/.
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, 14 Aug 1995 10:25:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 14 Aug 1995 12:58:12 +0200
Message-ID: <9508141058.AA08643@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: David.Rhead@vme.ccc.nottingham.ac.uk
Subject: Re: Examples files for end-users
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
> Version 0.98 of the directory structure draft does not seem consistent
> in its treatment of example files.
> * Near the bottom of page 7, it envisages that Knuth's story.tex would
> live in texmf/tex/plain/story.tex
> * However, on page 13, it envisages that a Martian example would live in
> texmf/doc/latex/martian/example.tex.
> (I'm not clear where it envisages that example files such as LaTeX's
> sample2e.tex and small2e.tex would fit into the 0.98 scheme.)
Some time ago, I've suggested to put story.tex into both texmf/doc/tex
and texmf/tex/plain. texmf/doc/tex is the place for users to look at
the source file (and other documentation such as texbook.tex), whereas
texmf/tex/plain is the place where the file is found when running it
through TeX. If it weren't in texmf/tex/somewhere, users reading
The TeXbook would be suprised that "tex story" would suddenly fail.
(Same for "mf io" and "latex sample2e".)
Your suggestion of texmf/examples looks nice, but I'm uncertain
whether it is really needed. If the files are in texmf/doc and
there is a good navigational aid for first-time users to find these
examples, e.g. some sort of WWW front-end, this might be sufficient,
I think.
Thanks for your suggestions anyway.
Cheers,
Ulrik Vieth.
(Just a personal opinion, not speaking for TWG-TDS in general.)
================================================================================
From owner-twg-tds@shsu.edu Mon, 14 Aug 1995 10:49:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 14 Aug 95 16:47:26 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9508141547.AA07326@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: david.rhead@vme.ccc.nottingham.ac.uk
Subject: Re: Examples files for end-users
> I think, examples are an integral part of documentation and should
> therefore go in the doc/ area.
Agreed, I dont think the TDS can start to categorise what kind of
documentation is supplied.
> IMO, that file [story.tex] should go in doc/plain/. (Or
> doc/plain/base/?)
Agreed again probably. I seem to recall that the idea of putting
story.tex (and possibly the latex sample2e.tex) in the TeX input tree
is that joe user can type
tex story
when following that bit of the TeXbook, without having to copy the
file first, although this seems a slightly week argument especially in
the case of story.tex where the texbok suggests editing (a copy of)
the file in anycase.
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 14 Aug 1995 10:58:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 14 Aug 1995 16:55:09 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508141555.QAA06834@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
CC: david.rhead@vme.ccc.nottingham.ac.uk
Subject: Re: Examples files for end-users
References: <199508141515.RAA14510@spice.iti.informatik.th-darmstadt.de>
Joachim Schrod writes:
> >
> > * Near the bottom of page 7, it envisages that Knuth's story.tex would
> > live in texmf/tex/plain/story.tex
>
> IMO, that file should go in doc/plain/. (Or doc/plain/base/?)
well, i bet many TeX guides say
"try typing
tex story
and view the result"
thats the problem. but i agree with Joachim, we stamp out this sort of
thing. doc/plain/knuth, IMHO
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 14 Aug 1995 11:14:49 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508141601.SAA17427@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Examples files for end-users
To: TWG-TDS@SHSU.edu
Date: Mon, 14 Aug 1995 18:01:56 +0200 (MESZ)
Content-Type: text
Ulrik wrote:
>
> [story.tex]
> texmf/tex/plain is the place where the file is found when running it
> through TeX. If it weren't in texmf/tex/somewhere, users reading
> The TeXbook would be suprised that "tex story" would suddenly fail.
As they are told one page earlier that they shall ``Use your favorite
text editor to create a file called story.tex that contains the
following 18 lines of text'', they shouldn't be surprised if it fails
without that first step.
Nowhere in the TeXbook is it mentioned that the file story.tex is
available on-line, so I'm not willing to accept a postulate that we
are bound by the TeXbook in that matter.
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, 14 Aug 1995 12:03:32 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508141601.SAA17427@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Examples files for end-users
To: TWG-TDS@SHSU.edu
Date: Mon, 14 Aug 1995 18:01:56 +0200 (MESZ)
Content-Type: text
Ulrik wrote:
>
> [story.tex]
> texmf/tex/plain is the place where the file is found when running it
> through TeX. If it weren't in texmf/tex/somewhere, users reading
> The TeXbook would be suprised that "tex story" would suddenly fail.
As they are told one page earlier that they shall ``Use your favorite
text editor to create a file called story.tex that contains the
following 18 lines of text'', they shouldn't be surprised if it fails
without that first step.
Nowhere in the TeXbook is it mentioned that the file story.tex is
available on-line, so I'm not willing to accept a postulate that we
are bound by the TeXbook in that matter.
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, 14 Aug 1995 12:06: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: <199508141601.SAA17427@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Examples files for end-users
To: TWG-TDS@SHSU.edu
Date: Mon, 14 Aug 1995 18:01:56 +0200 (MESZ)
Content-Type: text
Ulrik wrote:
>
> [story.tex]
> texmf/tex/plain is the place where the file is found when running it
> through TeX. If it weren't in texmf/tex/somewhere, users reading
> The TeXbook would be suprised that "tex story" would suddenly fail.
As they are told one page earlier that they shall ``Use your favorite
text editor to create a file called story.tex that contains the
following 18 lines of text'', they shouldn't be surprised if it fails
without that first step.
Nowhere in the TeXbook is it mentioned that the file story.tex is
available on-line, so I'm not willing to accept a postulate that we
are bound by the TeXbook in that matter.
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, 15 Aug 1995 11:27:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 15 Aug 1995 18:26:42 CET +0100
From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" <SPIELER@linac.ikp.physik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@shsu.edu
CC: c753330@nlzcl1.decnet.philips.nl, SPIELER@linac.ikp.physik.th-darmstadt.de
Message-ID: <00994EC5.22498DE0.2@linac.ikp.physik.th-darmstadt.de>
Subject: implementation specific part of a TDS layout for VMS TeX
In response to "Alex's" (VMS) user comment, I want to introduce my solution
of a TDS compliant directory structure for the implementation specific
part of a VMS TeX installation:
All VMS specific files (executables; command procedures;
help files, - libraries; string pools, formats, bases; various management
stuff; etc.) are collected in a subtree below a top level directory
TEX_ROOT:[VMS] (`texmf/vms/' in UNIX notation).
Note that I do NOT use a top level `bin' directory.
(NB: The directory name 'bin' is one of those misleading terms introduced
by bad UNIX habits: The UNIX bin directories do not contain `binary'
files, but `executable' files. Many of those executable files are
in fact binaries (compiled and linked programs), but in most cases,
a 'bin' directory contains shell scripts as well, and these are
ordinary text files! For VMS, I use `exe' instead of `bin'.)
My current layout in a bit more detail:
texmf/
vms/ : VMS implementation specific stuff (*1)
exe/ : `end user' commands
common/ : command procedures, command definition
files,...
axp/ : binary executables for Alpha AXP
vax/ : binary executables for VAX
formats/ : pool and dump files (formats resp. bases)
for TeX and METAFONT (see Remark *2)
help/ : VMS help library, and (currently)
miscellanous help sources;
perhaps other VMS specific docs.
mgr/ : Miscellanous files for TeX system
management purpose (command procedures,
programs, and docs), not intended for
ordinary end users.
Remarks:
*1 In case there appears another VMS implementation besides Public DECUS
TeX, the top level implementation directory name should be modified
to something more specific. (e.g.: vms/ -> vms_decus/)
*2 It is a VMS (DECUS TeX) specific tradition to keep TeX and MF dump files
in a common directory (they do not interfere), but there is no objection
to use a separate directory bases/ for METAFONT's pool and dump files.
Note that the VMS help files are NOT kept in the (top level) `doc/' area.
The VMS help files are not intended for direct reading or printing
(although this could be done, they are ASCII text files); they should
rather be used with the VMS help utility.
(An explanation for those not familiar with VMS:
The VMS help utility read the help texts from special text libraries
("help libraries") which are created and maintained with the VMS Librarian
utility. The help libraries (.HLB files) are `binary' files (not
printable/readable). In contrast, an individual module extracted from a
help library -- a .HLP file -- is an editable ASCII text file in a special
format. But, im most cases, the source for a help text is produced as
a `runoff' file (.RNH file); the .HLP module for the help library is the
result of applying the RUNOFF utility to the .RNH source file.)
The VMS help sources are partly supplied together with program sources
(in the `source/' tree). In those cases where a help source is not
associated with a distinct program, the sources are currently stored
in the `help' directory, too.
My next (CTAN) release of VMS DECUS TeX will use the shown directory
layout. With the exception of the directory structure for PK font files,
this release should then conform to the TDS draft.
I want to suggest a generalization of this approach:
a) The top level `doc/' area (as part of the implementation independent
TDS specification) is overly crowded. In my eyes, this area should
only carry (mostly) implementation independent documentation and
example files. These files should be intended for direct reading
as normal text files (.TXT, read.me, etc.), for printing (Postscript
files), or for processing with the TeX system's own utilities
(aka: TeX source files, Texinfo source files, .DVI files...).
b) Documentation files in a system specific format should be kept in
the implementation specific part of the TeX installation, somewhere
below a top level `implementation' directory.
Examples are:
- UNIX implementation (web2c): man pages
(man pages are not intended for direct reading, they should be
used through a man page formatter which is not standard on many
non-UNIX systems.)
- VMS implementation (DECUS): help library files
- OS/2 (emTeX): BOOK files, INF files for the OS/2 WPS shell.
- MAC: ???
c) The top level 'bin' directory as starting point for implementation
specific subtrees should be removed; its implication that only
"binary" files may be implementation specific is definitely wrong.
Instead, each implementation should put its specific files in a
subtree, starting with a unique top level directory specifying the
implementation. The organisation of these system specific subtrees
is up to the implementor and not target of the TDS specification.
(This does not exclude hints in the TDS text how things ``could''
be organized. In my eyes, some typical examples are welcome. These
may help different implementors to choose similar looking structures,
so that the installing/maintaining tasks of different implementations
do not differ too much.
d) In addition to those file formats mentioned above (item a)), the
doc/ area may contain ready-to-use GNU info files (.info) and
WWW (.html) browser files. Althought special utilities are needed
to effectly use/read these documentation files, they are not system
specific, since both WWW and GNU info readers are available for many
of the more popular OS systems.
Some examples of possible implementation specific trees:
i) VMS DECUS TeX: see above
ii) Unix TeX (web2c):
texmf/
web2c/ : web2c specific files
First, web2c files that do not depend on a particular
UNIX version or CPU type:
/bin : common scripts, not depending on
a particular CPU or OS version;
e.g.: MakeTeXPK
/bases : MF base dump files (and mf.pool)
/formats : TeX format dump files (and tex.pool)
/man .. : web2c man pages
Now, there are (one ore more) OSversion/CPU specific subdirs
which contain the nonportable binaries:
/sun_os : SUN computers (older OS versions)
/bin : binary program executables
/sparc_solaris : SUN sparc, running Solaris
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
/dec_mips_ultrix : Decstations based on MIPS cpu
/bin : binary program executables
/dec_axp_osf : DEC Alpha AXP under OSF (DEC Unix)
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
/hp{xxx} : HP computers
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
/ibm_aix : IBM 6000 workstations, under AIX
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
/linux_intel : IBM PC (386 up) under Linux
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
/linux_alpha : Linux on Alpha PCs
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
/linux_motorola : Linux on 68xxx computers (Amiga?)
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
/BSD386 : IBM PC (386 up) under FreeBSD...
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
Remark: Some of the UNIX systems support (in principle) shareable libraries.
If (a future version of) web2c is configured to produce and use
private shareable libraries, one may need/want a separate directory
where these "DLLs" are stored. This is expressed with those "/lib"
subdirectory lines.
(I do not really know how/where shareable libraries are stored
on these newer UNIX systems, this was just a guess.)
iii) MSDOS and OS/2 (emTeX):
texmf/
emtex/ : E. Mattes joined DOS&OS/2 implementation
/bin : binary executables (both systems),
.BAT files (DOS), .CMD files (OS/2)
/btexfmts : BigTeX (64bit) dump files and pool
/texfmts : SmallTeX (32bit) dump files and pool
/bmfbases : BigMF (64bit) dump files and pool
/mfbases : SmallMF (32bit) dump files and pool
/mfjob : control scripts for MFJOB utility
/data : misc support and config files
/dll : dynamic link libraries (OS/2)
/book : OS/2 online documentation books (.INF)
/german
/english
/doc ... : emTeX program documentation files.
/german
/english
/help : OS/2 WPS help files (.hlp)
Remark: The emTeX specific documentation files (those that describe how
to install and use the em implementations of the programs) are kept
in the system specific tree despite the fact that they are directly
readable/printable ASCII text files. But, their information is of
no use for non-emTeX users.
iv) MSDOS PubliC-TeX (DOS-TP, Copyleft Turbo Pascal implementation):
texmf/
dos_tp/ : P. Breitenlohner's TP implementation
/bin : binary executables, and (possibly)
.BAT files
/formats : TeX dump files and pool
/bases : METAFONT dump files and pool
/doc : (optional) area for installation
readme files.
================================================================================
From owner-twg-tds@shsu.edu Tue, 15 Aug 1995 11:59:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 15 Aug 1995 18:27:57 CET +0100
From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" <SPIELER@linac.ikp.physik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@shsu.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Message-ID: <00994EC5.4EF78AE0.7@linac.ikp.physik.th-darmstadt.de>
Subject: Suggestion: differenciate "package" and "program" sources
Hello again,
In addition to my suggestions concerning the implementation specific
part of the texmf tree, I would like to have an additional categorizing
level below the "source/" top level directory:
In my opinion, it would be helpful to differentiate between
sources that are to be processed (mainly) by the TeXMF system's own
programs and sources where you need system supplied compilers to process
them. For the first category, I used a subdirectory "packages/", the latter
was named "progs/" ("programs/"):
texmf/
source/ : source distributions...
packages/ : `macro' type source sets
latex/
base/
mfnfss/
graphics/
tools/
babel/
latex209/ ....
fontinst/ ....
progs/ : `program' type source sets (to be compiled)
bibtex/
dviware/
dvips/
xdvi/
makeindex/
tex_mf/
tex/
mf/
texware/
mfware/
web/
The "progs/" part of the source tree gives rise to an additional problem:
At least for some programs, the "source" is implementation specific. This
is the case for all programs written in Web. Depending on the implementation,
change files and (optional) compiling procedures are different.
(See, for example, the web2c distribution and the DOS-TP distribution of
TeX and METAFONT.)
For other programs, the canonic source distribution contains support
for many different OS environments (e.g.: Makeindex, (non-k) dvips and xdvi,
Beebe DVI drivers, Ghostscript).
Maybe, for "prog" type of source sets, there should be a recommendation
where differentiations between different implemenation adaptations could
be introduced.
One might consider to introduce the same differentiation between "progs"
and "packages" in the doc area. On a large TeX system with many installed
pachages and programs, the top level doc/ directory list gets rather long,
making it difficult to find documentation for a particular program/package.
(On the other hand, do we get short of directory levels when this
additional hierarchy level is introduced?)
Best regards
Christian Spieler
================================================================================
From owner-twg-tds@shsu.edu Wed, 16 Aug 1995 12:27: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: <199508161727.TAA14530@spice.iti.informatik.th-darmstadt.de>
Subject: Re: implementation specific part of a TDS layout for VMS TeX
To: TWG-TDS@SHSU.edu
Date: Wed, 16 Aug 1995 19:27:26 +0200 (MESZ)
CC: c753330@nlzcl1.decnet.philips.nl
Content-Type: text
Christian wrote:
>
> In response to "Alex's" (VMS) user comment, I want to introduce my solution
> of a TDS compliant directory structure for the implementation specific
> part of a VMS TeX installation:
I like that summary a lot. I would agree to his proposal that bin/
should be dropped from the TDS draft.
And I would like to see (yet another ;-) appendix that presents the
outlines from Christian as example(s) of structures below the <TeX
implementation dir>. We had quite some question about that area and
that might clarify the point.
Of course, we do it only if Karl agrees to look over the web2c
example. :-) (E.g., the distinction of bases/ and formats/ is bogus,
web2c uses ini/ traditionally and will hopefully use something with a
version number in the future.)
Concerning the additional points raised by Christian: I don't care
where the man pages are. They may go under web2c/ -- I think most
system administrators will copy them to some local man page tree
anyhow. (At least, all admins I know do.)
Cheers,
Joachim
PS: Christian, still reluctant to put your name on the TDS paper, as
a group member? You provided lots of feedback about the VMS stuff, we
should acknowledge your contribution.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 16 Aug 1995 13:24:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 16 Aug 1995 20:22:35 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: implementation specific part of a TDS layout for VMS TeX
To: TWG-TDS@SHSU.edu
Message-ID: <01HU5JD7UO1U0003RO@VzdmzA.ZDV.Uni-Mainz.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Joachim Schrod wrote:
> Of course, we do it only if Karl agrees to look over the web2c
>example. :-) (E.g., the distinction of bases/ and formats/ is bogus,
>web2c uses ini/ traditionally and will hopefully use something with a
>version number in the future.)
I don't think, that the distinction formats vs. bases is bogus. I use to
store the log files from format/base generation together with the formats/
bases, and there is a conflict concerning the file plain.lis (oops, that
was VMSish, it should read plain.log), which could stem from plain.fmt or
plain.base. Okay, on a system with long filenames it could be named in a
unique way, like plain.log_bas and plain.log_fmt, however there are well
known computers where this possibility is not present.
--J"org Knappen
================================================================================
From owner-twg-tds@shsu.edu Wed, 16 Aug 1995 15:06:22 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508162002.WAA14358@spice.iti.informatik.th-darmstadt.de>
Subject: Re: implementation specific part of a TDS layout for VMS TeX
To: TWG-TDS@SHSU.edu
Date: Wed, 16 Aug 1995 22:02:35 +0200 (MESZ)
Content-Type: text
You wrote:
>
> Joachim Schrod wrote:
>
> > Of course, we do it only if Karl agrees to look over the web2c
> >example. :-) (E.g., the distinction of bases/ and formats/ is bogus,
> >web2c uses ini/ traditionally and will hopefully use something with a
> >version number in the future.)
>
> I don't think, that the distinction formats vs. bases is bogus.
That statement was meant strictly in the realm of Unix & web2c.
I don't want to imply any implications for any other TeX ports.
(Cautious enough? :-)
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, 18 Aug 1995 10:55:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 18 Aug 1995 11:54:21 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508181554.AA00781@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation specific part of a TDS layout for VMS TeX
I would agree to his proposal that bin/
should be dropped from the TDS draft.
I agree, too. bin/ and man/ can go under web2c/ or be dropped altogether.
info/, I'm not sure about moving to doc/. Doesn't seem quite right to me.
Of course, we do it only if Karl agrees to look over the web2c
I dunno, is it necessary to provide the complete substructure for any of
the implementation dirs? I mean, sure, I'll do it, but not sure it's
right for the draft.
web2c uses ini/ traditionally and will hopefully use something with a
version number in the future.)
As we discussed, I think dealing with different versions is beyond the
scope of TDS and web2c, and the way to do it is to make texmf/web2c a
link to web2c-7.0 or whatever.
================================================================================
From owner-twg-tds@shsu.edu Fri, 18 Aug 1995 10:55:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 18 Aug 1995 11:54:21 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508181554.AA00789@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: David.Rhead@vme.ccc.nottingham.ac.uk
Subject: Re: Roles of texmf and oratex (or analogue)
unofficial, local, mortal, site-dependent, us, ... , standard,
God-given, official, site-independent, Them
This is an important question; we don't want the TDS to give this
impression (at least *I* don't want it to). I agree with everything
(more or less :-) David says. We can and should do *something* about
local files. /usr/local/oratexmf isn't enough. The stuff David says at
the end about what to do seems reasonable to me.
Sorry, but I can't dream up any real wording changes right now.
P.S. From what I read of David's implementations, they're better
maintained than anyone else's ... maybe we should just declare those
standard and forget the TDS :-) :-) ?
================================================================================
From owner-twg-tds@shsu.edu Mon, 21 Aug 1995 04:06:53 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508141601.SAA17427@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Examples files for end-users
To: TWG-TDS@SHSU.edu
Date: Mon, 14 Aug 1995 18:01:56 +0200 (MESZ)
Content-Type: text
Ulrik wrote:
>
> [story.tex]
> texmf/tex/plain is the place where the file is found when running it
> through TeX. If it weren't in texmf/tex/somewhere, users reading
> The TeXbook would be suprised that "tex story" would suddenly fail.
As they are told one page earlier that they shall ``Use your favorite
text editor to create a file called story.tex that contains the
following 18 lines of text'', they shouldn't be surprised if it fails
without that first step.
Nowhere in the TeXbook is it mentioned that the file story.tex is
available on-line, so I'm not willing to accept a postulate that we
are bound by the TeXbook in that matter.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 23 Aug 1995 02:58:12 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <199508230757.RAA09913@asgard.mlb.dmt.csiro.au>
To: twg-tds@shsu.edu
Subject: TDS-0.98 and multiple format/pool files
Date: Wed, 23 Aug 1995 17:57:49 +1000
From: Robin Kirkham <rjk@mlb.dmt.csiro.au>
Reply-To: TWG-TDS@SHSU.edu
Hello
I'm assembling a TeX system at our site at present, and I am attempting to
follow the draft TDS standard 0.98. We will soon have a hetrogeneous NFS
filesystem, with several different workstations/operating systems accessing the
TeX tree.
The TDS document suggests sub-directories texmf/bin/<system> for binaries
(executables) for different systems (CPU/operating system combinations). For
instance, I would probably have
texmf/bin/sparc-sunos4
texmf/bin/sparc-solaris
texmf/bin/i486-linux
(ignoring filename-length for the time being). This is a reasonable approach,
and one used elsewhere. The problem is, where do the format and pool files go?
Different systems cannot in general share format and pool files, so they need
to be segregated and named in a consistent fashion.
The TDS document gives no advice on this subject, as far as I can tell, and the
sample TDS tree on the CTAN archive suggests that these file go in (I think)
texmf/web2c/ini, or something like that.
My preference would be for these system-dependent files to go in with the
executables, i.e. texmf/bin/<system>.
Any comments?
Robin Kirkham CSIRO Division of Manufacturing Technology
Project Engineer Locked Bag 9, Preston 3072, Australia
robin.kirkham@mlb.dmt.csiro.au Phone: +61 3 9662-7756 Fax: +61 3 9662-7853
================================================================================
From owner-twg-tds@shsu.edu Wed, 23 Aug 1995 05:39: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: <199508231037.MAA20763@spice.iti.informatik.th-darmstadt.de>
Subject: Re: TDS-0.98 and multiple format/pool files
To: TWG-TDS@SHSU.edu
Date: Wed, 23 Aug 1995 12:37:00 +0200 (MESZ)
CC: rjk@mlb.dmt.csiro.au
Content-Type: text
Robin Kirkham wrote:
>
> The TDS document suggests sub-directories texmf/bin/<system> for binaries
> (executables) for different systems (CPU/operating system combinations). For
> instance, I would probably have
>
> texmf/bin/sparc-sunos4
> texmf/bin/sparc-solaris
> texmf/bin/i486-linux
>
> (ignoring filename-length for the time being). This is a reasonable approach,
> and one used elsewhere. The problem is, where do the format and pool files go?
> Different systems cannot in general share format and pool files, so they need
> to be segregated and named in a consistent fashion.
Please note that all web2c-based TeX implementations may use the
_same_ format and pool files, independent of hardware architecture and
operating system.
This is one of the reasons why we recommend putting such files in a
subdirectory that's specific for the TeX implementation, i.e.,
somewhere below web2c/. Where it is put there is not decided by the
TDS effort, this is up to the system's author.
Actually, there is a discussion about discarding the bin/ directory
in the TDS draft, and moving executables to the
TeX-implementation-directory (here: web2c/) as well, most probably in
subdirectories thereof. (The name `bin/' is a Unix-centric notion,
and folks from other OS backgrounds have mentioned their discomfort.)
Bottom line: How about
texmf/web2c/
bin/<platform>/ for executables
ini/ for formats, bases, and pool files
Btw, _I_ wouldn't restrict myself to 8 characters in <platform>. The
TDS does not restrict the file name length. It merely acknowledges
the problem connected to the length issue in particular in the realm
of CD-ROM distributions, names the constraints we found, and makes
sure that the directory names fixed in the draft adhere to this
restriction.
If one makes an installation that is only stored on real operating
systems, one can use long names. Even if that installation is
accessed by DOS (e.g, via PC-NFS), there is no problem -- the DOS TeX
should never look into texmf/web2c/. One should just not assume that
one can transport such an installation file-wise via DOS floppies
afterwards without loss of information.
Hope this helps,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 23 Aug 1995 09:17:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 23 Aug 1995 10:17:20 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508231417.AA21376@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: rjk@mlb.dmt.csiro.au
Subject: Re: TDS-0.98 and multiple format/pool files
Please note that all web2c-based TeX implementations may use the
_same_ format and pool files, independent of hardware architecture and
operating system.
I believe pool files are even sharable across implementations ... modulo
the pesky CRLF stuff.
Also, it's possible to turn off the creation of sharable (read:
BigEndian) format files. This speeds up execution on LittleEndian
machines. If you do this, some kind of distinction needs to be made,
clearly ... but I don't think the TDS could recommend anything. It would
cause more harm than good.
================================================================================
From owner-twg-tds@shsu.edu Wed, 23 Aug 1995 11:30:46 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 23 Aug 1995 10:17:20 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508231417.AA21376@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: rjk@mlb.dmt.csiro.au
Subject: Re: TDS-0.98 and multiple format/pool files
Please note that all web2c-based TeX implementations may use the
_same_ format and pool files, independent of hardware architecture and
operating system.
I believe pool files are even sharable across implementations ... modulo
the pesky CRLF stuff.
Also, it's possible to turn off the creation of sharable (read:
BigEndian) format files. This speeds up execution on LittleEndian
machines. If you do this, some kind of distinction needs to be made,
clearly ... but I don't think the TDS could recommend anything. It would
cause more harm than good.
================================================================================
From owner-twg-tds@shsu.edu Wed, 23 Aug 1995 22:39:21 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <199508240255.MAA01015@asgard.mlb.dmt.csiro.au>
To: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
CC: TWG-TDS@shsu.edu
Subject: Re: TDS-0.98 and multiple format/pool files
Date: Thu, 24 Aug 1995 12:55:15 +1000
From: Robin Kirkham <rjk@mlb.dmt.csiro.au>
Reply-To: TWG-TDS@SHSU.edu
Joachim/Karl,
Thank you for your quick replies. Pool/format files seem less of a problem
to me now, and texmf/web2c/ini looks reasonable.
Joachim Schrod writes:
> Actually, there is a discussion about discarding the bin/ directory
> in the TDS draft, and moving executables to the
> TeX-implementation-directory (here: web2c/) as well, most probably in
> subdirectories thereof. (The name `bin/' is a Unix-centric notion,
> and folks from other OS backgrounds have mentioned their discomfort.)
>
> Bottom line: How about
>
> texmf/web2c/
> bin/<platform>/ for executables
> ini/ for formats, bases, and pool files
This has some sense to it, but I see some problems. Firstly, the logical
extension to this is that you would have
texmf/web2c/bin/<platform>/
texmf/dvips/bin/<platform>/
texmf/xdvi/bin/<platform>/
texmf/makeindex/bin/<platform>/
...
that is, one bin/ (or exe/ or exec/ or whatever) for each TeX-related program.
I don't think this is a good idea at all, because users would have to have all
these directories in their PATH (or equivalent). It certainly isn't standard
UNIX or MSDOS practice.
You could side-step this be retaining texmf/bin/, and placing in it symbolic
links, shell scripts, batch files (or whatever) which pointed to/executed the
appropriate binary. If scripts were used, they could be clever enough to
determine <platform> as well (at least within a shared UNIX tree), which is
handy for the users. (I am considering doing this at my site, no matter where
the binaries actually end up).
Another snag is for systems that use shared transparent file systems or
automounters. With these (among other things) you can have a file tree which is
part shared and part platform-specific. In other words, different platforms
would share most of the texmf/ tree, but the automounter/file-system would
transparently substitute the appropriate bin/ directory for the user's
platform, and they don't have to worry about what platform they are on.
If there are a lot of texmf/*/bin/ directories then this starts to get messy,
as the file-system configuration has to change whenever a new TeX-related
program is installed. The maintainer of texmf/ (as the TWG-TDS 0.98 correctly
points out) is not always the system administrator.
So, given that pool/format files can in fact be shared, at least across
platforms for a given TeX implementation, (Norman Walsh's Making_TeX_Work
pp48-49 notwithstanding), I would suggest retaining the texmf/bin/, with
optional texmf/bin/<platform>/, as in the TDS 0.98.
As far as "bin/" goes, it is true that it is UNIX-centric, but MSDOS and
Windows packages in my experience use either nothing extra at all (i.e., they
use a directory named after the name of the package). Frequently, all the
package's files---executable or otherwise---are tossed in the same directory,
which is exactly what the TDS is trying to avoid. I don't know enough about
other operating systems to comment further on that issue.
Robin Kirkham CSIRO Division of Manufacturing Technology
Project Engineer Locked Bag 9, Preston 3072, Australia
robin.kirkham@mlb.dmt.csiro.au Phone: +61 3 9662-7756 Fax: +61 3 9662-7853
================================================================================
From owner-twg-tds@shsu.edu Thu, 24 Aug 1995 04:34: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: <199508240903.LAA11184@spock.iti.informatik.th-darmstadt.de>
Subject: Re: TDS-0.98 and multiple format/pool files
To: rjk@mlb.dmt.csiro.au (Robin Kirkham)
Date: Thu, 24 Aug 1995 11:03:34 +0200 (MESZ)
CC: schrod@iti.informatik.th-darmstadt.de, TWG-TDS@shsu.edu
Content-Type: text
You wrote:
>
> > Actually, there is a discussion about discarding the bin/ directory
>
> This has some sense to it, but I see some problems. Firstly, the logical
> extension to this is that you would have
>
> texmf/web2c/bin/<platform>/
> texmf/dvips/bin/<platform>/
> texmf/xdvi/bin/<platform>/
> texmf/makeindex/bin/<platform>/
> ...
>
> that is, one bin/ (or exe/ or exec/ or whatever) for each TeX-related program.
Yes, we need to go into more detail. Probably, it's best to describe a
set of possibilities except of _the_ one. Placement of executables
cannot be standardized yet, IMO; we just may give hints to existing
practice.
Cheers, and thanks a lot for your valuable feedback,
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, 28 Aug 1995 16:27:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon,28 Aug 95 16:25:14 BST
From: David.Rhead@vme.ccc.nottingham.ac.uk
Reply-To: TWG-TDS@SHSU.edu
Subject: Examples files for end-users
To: twg-tds@shsu.edu
Message-ID: <28_Aug_95_16.25.14.A16A9C@VME.NOTT.AC.UK>
I saw several messages in response to my mail of 13th August about
`examples files for end-users',
The consensus seemed to be that you're not convinced that there needs
to be a
texmf/examples
as well as the
texmf/doc
On the other hand, you agree that things like story.tex, small2e.tex and
sample2e.tex shouldn't be hidden away where people can't find them.
Generally, you're inclined to put such examples files into the same
directory as documentation.
Version 0.98 of the draft argues for texmf as the name for the root of
the tree on the grounds that it contains files for `not just TeX itself'.
If examples files go in the same directory as documentation, does a similar
argument apply? Should one say that, since the directory is not just for
documentation but also for examples, its name should signify both roles?
This might lead to a name such as
texmf/doc_ex
which hints at documentation, and examples, and `documentation containing
examples'.
Given such a hint, the user might be better able to cope with a directory
that may contain a mixture of:
examples - simple .tex files whose TeX commands the novice can
understand and imitate
documentation - (possibly) extremely complicated .tex files whose
TeX commands might frighten the novice. But the novice doesn't
actually need to be frightened, because these .tex files exist
purely so that the end-user can get instructions by [La]TeXing
the .tex file, and reading the resulting typeset document.
David Rhead
================================================================================
From owner-twg-tds@shsu.edu Tue, 29 Aug 1995 06:07: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: <199508291107.NAA17256@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Examples files for end-users
To: TWG-TDS@SHSU.edu
Date: Tue, 29 Aug 1995 13:07:02 +0200 (MESZ)
CC: david.rhead@vme.ccc.nottingham.ac.uk (David Rhead)
Content-Type: text
You wrote:
>
> I saw several messages in response to my mail of 13th August about
> `examples files for end-users',
>
> The consensus seemed to be that you're not convinced that there needs
> to be a
> texmf/examples
> as well as the
> texmf/doc
> On the other hand, you agree that things like story.tex, small2e.tex and
> sample2e.tex shouldn't be hidden away where people can't find them.
For the record: That can't be the `consensus' as at least one person
does not agree with that. (Guess whom. ;-)
As my viewpoint obviously wasn't expressed clear enough: Examples
_are_ documentation. They are not even a special part of
documentation, they are an integral part of it.
Documents like small2e.tex and sample2e.tex are neither less nor
more important than usrguide.tex or the Local Guide. Neither them nor
the user manual should be hidden away and both should be found. I
cannot see why we should force users to search for such basic
documents at two different locations.
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, 07 Sep 1995 11:23:22 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0sqjhH-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 7 Sep 95 17:21 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Installing TDS at Sussex
I've just spent a merry few days installing a TDS compliant TeX using
web2c TeX. Oh what fun it was. The main customization I had to do
was produce a new MakeTeXPK, which I'll attatch for those interested.
It's not exactly a work of art, and it's site-specific, but it may be
of some use for others...
There's no TDS directory specified for images, which is odd, since
they have to be on the TEXINPUTS path in order for graphics.sty to
pick them up. I ended up using texmf/images/<type>/<group>/<file>, eg
texmf/images/epsf/sussex/ssxcrest.eps for our crest.
The main point where I disagreed with TDS was the specification that
local files should be put outside the heirachy. There's no way on
earth I'm going to duplicate all of the TDS structure, so I used files
like texmf/tex/latex/sussex/ssxlet.cls for our letter class.
This makes our TEXINPUTS .:$TEXMF/tex//:$TEXMF/images//
Anyway, it all worked, the punters haven't complained too much so
far...
Alan.
--- that MakeTeXPK script in full ---
#!/bin/sh
#
# Filename: MakeTeXPK
# Author: Alan Jeffrey
# Date: 1995/09/05
#
VERSION=1.0
#
# This is the COGS script to generate missing PK files.
# It's based very loosely on Karl Berry's, but is almost entirely new.
#
# This script must echo the name of the generated PK file (and nothing
# else) to standard output.
#
# Parameters:
# name dpi bdpi magnification [mode]
#
# `name' is the base name of the font, such as `cmr10'.
# `dpi' is the resolution the font is needed at.
# `bdpi' is the base resolution, used to intuit the mode to use.
# `magnification' is a string to pass to MF as the value of `mag'.
# `mode', if supplied, is the mode to use. Unless it's `default', in
# which case we guess. (This is so people can specify a destdir
# without a mode.)
#
# Any other parameters are ignored (in particular, other MakeTeXPKs
# accept an optional destination directory argument, which we ignore).
# Where to find fonts
: ${TYPEONEDIR=/local/texmf/fonts/type1}
: ${MFDIR=/local/texmf/fonts/source}
: ${AFMDIR=/local/texmf/fonts/afm}
# Where to put fonts
: ${PKDIR=/local/texmf/fonts/pk}
# Where to find helper applications
: ${METAFONT=/local/texmf/bin/solaris/mf}
: ${GFTOPK=/local/texmf/bin/solaris/gftopk}
: ${GSFTOPK=/local/texmf/bin/solaris/gsftopk}
: ${FIND=/usr/bin/find}
# Where the psfonts.map file is
: ${PSFONTSMAP=/local/texmf/dvips/psfonts.map}
# TEMPDIR needs to be unique for each process because of the possibility
# of processes simultaneously running this script.
TEMPDIR=${TMPDIR-/tmp}/mtpk.$$
# Check we've got enough arguments.
if test $# -lt 4; then
echo "Usage: $0 name dpi bdpi mag [mode]." >&2
exit 1
fi
NAME=$1
DPI=$2
BDPI=$3
MAG=$4
MODE=$5
# Print out a `friendly' banner.
echo "" >&2
echo "This is MakeTeXPK, COGS Version $VERSION." >&2
echo "" >&2
echo "This script is called because you are the first person at COGS" >&2
echo "to use the bitmapped font $NAME.$DPI""pk." >&2
echo "It will take a few moments to make the bitmap." >&2
echo "The bitmap will be filed, so it will not be created by this script again." >&2
echo "" >&2
# If MODE is empty or "default", then make it cx.
if test -z "$MODE" || test "$MODE" = default; then
MODE=cx
fi
# OK, now we try to find the font, first looking for a MF font.
FONTHOME=`$FIND $MFDIR -name $NAME.mf -print`
if test -z "$FONTHOME" ; then
#
# If we can't find an MF font, then we look in the psfonts.map
# file to see if we can find an entry with a downloaded .pfa or .pfb
#
TYPEONEFILE=`egrep "^$NAME .*\.pfa" $PSFONTSMAP | sed 's/.*\([a-zA-Z0-9]*\.pf.\).*/\1/'`
if test -z "$TYPEONEFILE" ; then
#
# Otherwise, the font is a resident font, and we search for
# an AFM file that is the same, possibly with the encoding
# 8r replaced by 8a.
#
AFMFILE=`echo $NAME | sed -e 's/8r/8a/'`
FONTHOME=`$FIND $AFMDIR -name $AFMFILE.afm -print`
else
#
# If we can, we use find to find the file.
#
FONTHOME=`$FIND $TYPEONEDIR -name $TYPEONEFILE -print`
fi
fi
# If we've still got an empty FONTHOME, then we give up.
if test -z "$FONTHOME"; then
echo "$0: Failed to find $NAME." >&2
echo "$0: This shouldn't happen!" >&2
echo "$0: Please send a bug report to texpert@cogs." >&2
exit 1
fi
# We now tear FONTHOME apart to get the location of the font.
echo "Font source: $FONTHOME" >&2
set `echo $FONTHOME | sed -e 's/^.*\([^/.]*\)\/\([^/.]*\)\/\([^/.]*\)\/\([^/.]*\)\.\([^/.]*\)$/\2 \3 \5/'`
SOURCE=$1
FAMILY=$2
TYPE=$3
if test "$TYPE" != "mf"; then
MODE=gsftopk
fi
DESTDIR=$PKDIR/$MODE/$SOURCE/$FAMILY/dpi$DPI
PKNAME=$NAME"."$DPI"pk"
GFNAME=$NAME"."$DPI"gf"
echo "Font target: $DESTDIR/$PKNAME" >&2
echo "" >&2
# Allow fonts to be read and written (especially in case we make
# directories) by everyone.
umask 0
# Make sure the destination directory exists.
test -d $PKDIR/$MODE/$SOURCE || mkdir $PKDIR/$MODE/$SOURCE
test -d $PKDIR/$MODE/$SOURCE/$FAMILY || mkdir $PKDIR/$MODE/$SOURCE/$FAMILY
test -d $PKDIR/$MODE/$SOURCE/$FAMILY/dpi$DPI || mkdir $PKDIR/$MODE/$SOURCE/$FAMILY/dpi$DPI
# Clean up on normal or abnormal exit.
trap "cd /; rm -rf $TEMPDIR $DESTDIR/pktmp.$$" 0 1 2 15
# Go to the unique working directory.
test -d $TEMPDIR || mkdir $TEMPDIR
cd $TEMPDIR || exit 1
# Make that bitmap!
if test "$TYPE" = "mf" ; then
# Got a Metafont source, so run Metafont.
echo $METAFONT "\mode:=$MODE; mag:=$DPI/300; scrollmode; input $NAME;" >&2
$METAFONT "\mode:=$MODE; mag:=$DPI/300; scrollmode; input $NAME;" >&2 || exit 1
echo $GFTOPK $GFNAME >&2
$GFTOPK $GFNAME >&2 || exit 1
else
# Got a Type 1 source, so run gsftopk.
echo $GSFTOPK $NAME $DPI >&2
$GSFTOPK $NAME $DPI >&2 || exit 1
fi
# Look to see if another MakeTeXPK job has already made the bitmap
if test -r $DESTDIR/$PKNAME; then
echo "$0: $DESTDIR/$PKNAME already exists." >&2
echo $DESTDIR/$PKNAME
exit 0
fi
# Install the PK file carefully, since others may be working simultaneously.
mv $PKNAME $DESTDIR/pktmp.$$ \
|| { echo "$0: Could not mv $PKNAME $DESTDIR/pktmp.$$." >&2; exit 1; }
cd $DESTDIR || exit 1
mv pktmp.$$ $PKNAME
echo "" >&2
echo "Installation successful" >&2
# If this line (or an equivalent) is not present, dvipsk/xdvik/dviljk
# will think MakeTeXPK failed. Any other output to stdout will also lose.
echo $DESTDIR/$PKNAME
# That's it!
================================================================================
From owner-twg-tds@shsu.edu Fri, 08 Sep 1995 10:36:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 8 Sep 1995 16:34:09 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509081534.QAA16377@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
CC: alanje@cogs.susx.ac.uk
Subject: Re: Installing TDS at Sussex
References: <m0sqjhH-0001iBC@csrj.crn.cogs.susx.ac.uk>
> was produce a new MakeTeXPK, which I'll attatch for those interested.
oh dear another one....
> There's no TDS directory specified for images, which is odd, since
> they have to be on the TEXINPUTS path in order for graphics.sty to
> pick them up. I ended up using texmf/images/<type>/<group>/<file>, eg
> texmf/images/epsf/sussex/ssxcrest.eps for our crest.
i personally
dont like this much. why not with your departmental style file? but
its an interesting point
> earth I'm going to duplicate all of the TDS structure, so I used files
why not? whats the problem
> like texmf/tex/latex/sussex/ssxlet.cls for our letter class.
i think there is a difference between "local", as in "university of
sussex" and "local" as in "Alans hacks". BUT if you choose "sussex"
rather than "local" you should REGISTER the name sussex so that its
unambiguous all over the world. "sussex" is a fair choice, "cs" or
"mathsdept" is not....
> : ${MFDIR=/local/texmf/fonts/source}
with a trailing /mf//, surely?
> : ${AFMDIR=/local/texmf/fonts/afm}
trailing // please!
> : ${PSFONTSMAP=/local/texmf/dvips/psfonts.map}
hmm. i have about 70 map files....
> # Got a Type 1 source, so run gsftopk.
> echo $GSFTOPK $NAME $DPI >&2
> $GSFTOPK $NAME $DPI >&2 || exit 1
you lose the choice of using ps2pk?
and, Alan, you of all people to forget to allow for 8r re-encoding????
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 08 Sep 1995 11:30:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 8 Sep 1995 12:01:01 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509081601.AA28401@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
rather than "local" you should REGISTER the name sussex so that its
Is there anywhere to register it? We're not maintaining such a list in
the TDS doc, are we? Maybe let the local organization names fall where
they may?
================================================================================
From owner-twg-tds@shsu.edu Fri, 08 Sep 1995 11:57:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 8 Sep 1995 18:55:54 +0200
Message-ID: <9509081655.AA05569@macbeth.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Input from EuroTeX (for the record)
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
Before I forget it, let me summarize some input I got from the 4allTeX
people during the EuroTeX meeting. During the coffee-break on Wednesday
morning I was approached by one of them (can't remember who it was),
asking me about TDS. As far as I remember their main points were the
following:
1.) They think, as a CD producer, they should be represented somehow
in the TWG-TDS group.
2.) They think the TDS standard shouldn't leave open important questions
about the location of the format files. Instead it should specify
everything, perhaps as a set of separate specifications for different
platforms, but, in their view, the only way to achieve standardization
was a concrete specification rather than just a recommendation.
3.) They weren't happy about the layout of the font tree, but I didn't find
out what they actually wanted. So far, they are centered on emTeX only,
and maybe this has to do with the fact that subdirectory searching in
emTeX isn't as fast as Eberhard Mattes would like it to be and therefore
doesn't follow the TDS draft in his distribution so far.
Personal comments about this:
1.) If they are interested, they are of course free to join our discussions,
but I forgot to point this out to them specifically. Perhaps it might
be a good idea to ask them directly unless we get some input from them
in the next time.
2.) I told them that the next version of the TDS draft might include
appendices addressing the structure of the implementation-dependent
stuff for various platforms (VMS, web2c, possibly others).
3.) I have no idea what they wanted concerning the font tree, but as
mentioned above I guess it might be related to what emTeX does or
does not.
After Joachim's presentation of the TDS draft and during the subsequent
panel session there weren't actually many questions and I was a bit
surprised that the 4allTeX people didn't raise their questions there.
Perhaps this was because the panel session was overshadowed by the
topics e-TeX, Omega and LaTeX3 so that the TDS fell in the background.
As far as I remember there weren't any serious objections, so I guess
the best way to proceed is to see that we finalize the current draft
in the near future taking into account the recent input. Taking into
account the experience how long it took to produce the last draft,
I guess shortly before Christmas might be a good target date.
That's all. I hope I haven't mis-represented the position of the
4allTeX people.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Fri, 08 Sep 1995 13:02:21 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0sr71L-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 8 Sep 95 18:15 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
>oh dear another one....
Indeed. Such is life in the wacky world of distributed software
development... The problem I had with Karl's (I think it was
Karl's...) was that it found the <supplier> and <source> by parsing
the filename. It seems to me much simpler to find the pfa/pfb/afm
file using find, and use that to get the supplier and source.
> > There's no TDS directory specified for images, which is odd, since
> > they have to be on the TEXINPUTS path in order for graphics.sty to
> > pick them up. I ended up using texmf/images/<type>/<group>/<file>, eg
> > texmf/images/epsf/sussex/ssxcrest.eps for our crest.
> i personally
>dont like this much. why not with your departmental style file? but
>its an interesting point
If the epsf files are put somewhere else, it saves dvips and friends
searching all of $TEXINPUTS trying to find them.
>i think there is a difference between "local", as in "university of
>sussex" and "local" as in "Alans hacks". BUT if you choose "sussex"
>rather than "local" you should REGISTER the name sussex so that its
>unambiguous all over the world. "sussex" is a fair choice, "cs" or
>"mathsdept" is not....
This registration seems bizarre to me. Register with who? Every
institution with it's own notepaper/techreports/newsletter/etc is
going to need a texmf/tex/latex/<oursite> directory, all we can do is
encourage sensible naming conventions.
> > : ${MFDIR=/local/texmf/fonts/source}
>with a trailing /mf//, surely?
That directory is passed to find, not to a kpathsea program. If there
were a kpathfind or similar, I'd use that...
> > : ${PSFONTSMAP=/local/texmf/dvips/psfonts.map}
>hmm. i have about 70 map files....
Well, I did say it was site-specific!
>you lose the choice of using ps2pk?
Ditto.
>and, Alan, you of all people to forget to allow for 8r re-encoding????
Nope, gsftopk copes with ReEncodeFont lines in the psfonts.map file.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 08 Sep 1995 13:18:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 8 Sep 1995 20:16:13 +0200
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9509081816.AA10870@regulus.dbis.uh>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
> > : ${MFDIR=/local/texmf/fonts/source}
> with a trailing /mf//, surely?
You mean 'trailing //', as source was chosen instead of mf in the TDS.
> > : ${PSFONTSMAP=/local/texmf/dvips/psfonts.map}
> hmm. i have about 70 map files....
Ai... All MakeTeXPK versions I know of (including my one) only look at
one psfonts.map file.ee if a font is a postscript one...
> > $GSFTOPK $NAME $DPI >&2 || exit 1
> you lose the choice of using ps2pk?
> and, Alan, you of all people to forget to allow for 8r re-encoding????
What do you want to imply here? gsftopk can handle 8r re-encoding.
Thomas
================================================================================
From owner-twg-tds@shsu.edu Fri, 08 Sep 1995 18:00: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: <199509082301.BAA17680@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Installing TDS at Sussex
To: TWG-TDS@SHSU.edu
Date: Sat, 9 Sep 1995 01:01:01 +0200 (MESZ)
Content-Type: text
Alan wrote:
>
> Indeed. Such is life in the wacky world of distributed software
> development... The problem I had with Karl's (I think it was
> Karl's...) was that it found the <supplier> and <source> by parsing
> the filename. It seems to me much simpler to find the pfa/pfb/afm
> file using find, and use that to get the supplier and source.
Why don't you use that new command included in 2.6 that uses kpathsea
to locate a file? (Can't remember it's name right now.) Then you'll
find exactly the same file as MF found.
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, 09 Sep 1995 03:16:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 9 Sep 1995 09:14:34 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509090814.JAA17646@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <199509081601.AA28401@ra.cs.umb.edu>
K. Berry writes:
> rather than "local" you should REGISTER the name sussex so that its
>
> Is there anywhere to register it? We're not maintaining such a list in
> the TDS doc, are we? Maybe let the local organization names fall where
> they may?
we dont have a register right now, but i dont think we (the TeX
community) can last much longer without one. Rich is the man who
volunteered, i think... (with Tobi Oetiker)
sebastian
================================================================================
From owner-twg-tds@shsu.edu Sat, 09 Sep 1995 03:22:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 9 Sep 1995 09:20:38 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509090820.JAA17658@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <9509081816.AA10870@regulus.dbis.uh>
> Ai... All MakeTeXPK versions I know of (including my one) only look at
> one psfonts.map file.ee if a font is a postscript one...
mine doesnt! it searches all of them :-}
> > > $GSFTOPK $NAME $DPI >&2 || exit 1
> > you lose the choice of using ps2pk?
> > and, Alan, you of all people to forget to allow for 8r re-encoding????
>
> What do you want to imply here? gsftopk can handle 8r re-encoding.
>
my mistake. sorry!
sebastian
================================================================================
From owner-twg-tds@shsu.edu Sat, 09 Sep 1995 11:32:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 9 Sep 1995 10:01:22 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509091401.AA08318@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Input from EuroTeX (for the record)
2.) They think the TDS standard shouldn't leave open important questions
about the location of the format files. Instead it should specify
What are these open important questions?
================================================================================
From owner-twg-tds@shsu.edu Sat, 09 Sep 1995 15:40:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 9 Sep 1995 16:38:02 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509092038.AA11188@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
There's no TDS directory specified for images, which is odd, since
they have to be on the TEXINPUTS path in order for graphics.sty to
pick them up. I ended up using texmf/images/<type>/<group>/<file>, eg
texmf/images/epsf/sussex/ssxcrest.eps for our crest.
Because, as you say, images have to be found by TEXINPUTS for the TeX
macros to find the bounding boxes, I think they belong under texmf/tex//,
in whatever directory is appropriate (with package, localism, or
whatever), instead of in a new top-level directory. That just
complicates the TEXINPUTS path.
The main point where I disagreed with TDS was the specification that
local files should be put outside the heirachy. There's no way on
What about if we reserved the name ``local'' at every level for people
to put stuff into if they want? (Similar to `misc' now.) I'm not sure if
this is better or worse than the proliferation of ``sussex'', ``umb'',
``elsevier'', etc.
I guess we had this discussion before, but I'm not sure why we settled
on a separate tree. I think we must bow to reality -- texadmins are not
going to create separate texmf trees and double the size of their paths
just for the sake of a couple of files. (They might with a
reasonably-fully-populated tree, but I suspect that case is rare to
nonexistent.)
Thus, perhaps we should support/recommend both.
Thoughts?
================================================================================
From owner-twg-tds@shsu.edu Mon, 11 Sep 1995 05:06:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 11 Sep 1995 11:02:37 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509111002.LAA19795@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <199509092038.AA11188@terminus.cs.umb.edu>
> What about if we reserved the name ``local'' at every level for people
> to put stuff into if they want? (Similar to `misc' now.) I'm not sure if
> this is better or worse than the proliferation of ``sussex'', ``umb'',
> ``elsevier'', etc.
my memory is that we had done this, i was obviously wrong. but i think
it should go in - "local" is reserved, and its contents undefined.
that doesnt mean that "elsevier" and "umb" shouldnt register their
names, tho, imho
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 11 Sep 1995 06:39:51 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0ss75s-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 11 Sep 95 12:32 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
>my memory is that we had done this, i was obviously wrong. but i think
>it should go in - "local" is reserved, and its contents undefined.
Using "sussex", etc. is simpler IMHO since it means that admins can
have more than one local directory, eg on my Mac I have a "sussex"
folder and an "asaj" folder.
>that doesnt mean that "elsevier" and "umb" shouldnt register their
>names, tho, imho
Do you really want me to register "asaj" as the name of the directory
that occurs only on my machine?
Alan
================================================================================
From owner-twg-tds@shsu.edu Mon, 11 Sep 1995 06:53:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 11 Sep 95 12:31:47 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9509111131.AA25488@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
my memory is that we had done this, i was obviously wrong. but i think
it should go in - "local" is reserved, and its contents undefined.
that doesnt mean that "elsevier" and "umb" shouldnt register their
names, tho, imho
I dont really mind mind `local' but last time this came up (now where
is that archive of this list:-) I thought the idea was to recommend
named direcories `elsevier' etc (or totally separate tds tree) so that
tds trees from different sites may be more easily merged.
I think the idea of `registering' every such name is a non-starter.
Every installation of TeX that has *any* local files would need to
register a unique name. So here (probably typical?) we would need to
register tds names for virtually every science department + the
medical school + the central computer centre + quite a few arts
departments. These are all `autonomous' TeX installations administered
by individuals in each department. Some of these installations
probably just copy the central computer centre set up, but I'd guess
Manchester would need a dozen or so names. And that is just one of
three universities in one town in a small European island. A global
register would get big very quickly for no obvious gain?
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 11 Sep 1995 07:36:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 11 Sep 1995 13:32:49 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509111232.NAA20666@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <9509111131.AA25488@r8h.cs.man.ac.uk>
> Manchester would need a dozen or so names. And that is just one of
> three universities in one town in a small European island. A global
> register would get big very quickly for no obvious gain?
>
spoilsport....
we obviously have to canonize "local" anyway, and make sure it is
omitted from merges
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 11 Sep 1995 07:39:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 11 Sep 1995 13:35:02 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509111235.NAA20689@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <m0ss75s-0001iBC@csrj.crn.cogs.susx.ac.uk>
> Do you really want me to register "asaj" as the name of the directory
> that occurs only on my machine?
>
if you insist it be in the main TDS tree, rather than your local tree,
yes.
one solution is for implementors to make it easy to say that
$TEXMF/tex/latex//
means
{/usr/local/tex,/usr/home/alan/tex}/tex/latex/latex
as it were, so that maintaining a local tree is not too much trouble
maybe someone can see how to express this in kpathsea? can it be done?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 11 Sep 1995 07:42:30 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0ss87x-0001iRC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 11 Sep 95 13:38 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
>Because, as you say, images have to be found by TEXINPUTS for the TeX
>macros to find the bounding boxes, I think they belong under texmf/tex//,
>in whatever directory is appropriate (with package, localism, or
>whatever), instead of in a new top-level directory. That just
>complicates the TEXINPUTS path.
But that requires having the dvi drivers search all of TEXINPUTS for
figures, rather than a (much smaller) images directory.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Sep 1995 08:17:13 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0ssV7J-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 12 Sep 95 14:11 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
>if you insist it be in the main TDS tree, rather than your local tree,
>yes.
What does `my local tree' mean on my Mac? I don't see why macros I've
written should belong on completely different places on my Mac
depending on whether or not I happened to distribute them to CTAN.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Sep 1995 08:24:22 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0ssVFQ-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 12 Sep 95 14:19 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
>Why don't you use that new command included in 2.6 that uses kpathsea
>to locate a file? (Can't remember it's name right now.) Then you'll
>find exactly the same file as MF found.
Karl pointed out kpsewhich to me, which makes life much easier. The
algorithm I now use is (in pidgin sh):
FONTHOME = `kpsewhich $NAME.mf || kpsewhich $NAME.tfm`
... tear $FONTHOME apart to get the appropriate bits and pieces ...
This will die horribly if anyone installs their own mf or type1 fonts,
but it's not obvious what to do in that situation. But I doubt this
is very likely here...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Sep 1995 11:33:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 12 Sep 1995 11:19:59 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509121519.AA19818@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
alan> But that requires having the dvi drivers search all of
TEXINPUTS for figures, rather than a (much smaller) images directory.
The whole thesis of the TDS is that searches are cheap. If this is not
true, things are hopeless anyway. What good does it do for the DVI
driver to search a small directory if TeX has to search a big one anyway?
Since TeX has to find the image files to get the bounding boxes, I
think they should be under tex//. I don't see the advantage to breaking
them out.
one solution is for implementors to make it easy to say that
$TEXMF/tex/latex//
means
{/usr/local/tex,/usr/home/alan/tex}/tex/latex/latex
as it were, so that maintaining a local tree is not too much trouble
maybe someone can see how to express this in kpathsea? can it be done?
You'd have to duplicate all the paths with two different TEXMF's.
There've been some discussions of directly supporting multiple trees,
but I have yet to be convinced it's worthwhile.
Anyway, regardless of whatever I do or do not implement, it seems a moot
point, since certainly the many other implementors out there will be
uninterested in something so hairy -- after all, simple caching
strategies were voted down, and significant compromises made because of
that, as we all know. Multiple TEXMF's is a lot more painful than
caching, believe me.
Are there any real local installations out there with two complete texmf
trees?
carlisle> I think the idea of `registering' every such name is a
non-starter.
I agree. I don't see the win here, Sebastian. Explain?
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Sep 1995 11:55:43 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0ssYXZ-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 12 Sep 95 17:50 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
>The whole thesis of the TDS is that searches are cheap. If this is not
>true, things are hopeless anyway. What good does it do for the DVI
>driver to search a small directory if TeX has to search a big one anyway?
OK, so the pragmatic argument doesn't work... I guess I just find it
odd classifying images as TeX sources, just because TeX happens to be
one of the programs which reads them.
But I guess I don't particularly care whether the files are
texmf/images/<type>/<bundle> or texmf/tex/images/<type>/<bundle> or
even texmf/tex/generic/images/<type>. But I think we should say
something about where they should go.
>There've been some discussions of directly supporting multiple trees,
>but I have yet to be convinced it's worthwhile.
I definitely agree with this!
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 12 Sep 1995 19:12:45 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 12 Sep 1995 17:10:27 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509130010.RAA24690@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
Karl pointed out kpsewhich to me, which makes life much easier. The
algorithm I now use is (in pidgin sh):
FONTHOME = `kpsewhich $NAME.mf || kpsewhich $NAME.tfm`
... tear $FONTHOME apart to get the appropriate bits and pieces ...
This will die horribly if anyone installs their own mf or type1 fonts,
but it's not obvious what to do in that situation. But I doubt this
is very likely here...
What's wrong with:
% Ditto for MF.
MFINPUTS = .:$TEXMF/mf//:$PRIVATE/fonts//src//:$TEXMF/fonts//src//
% Device-independent font metric files.
VFFONTS = .:$PRIVATE/fonts//vf:$TEXMF/fonts//vf
TFMFONTS = .:$PRIVATE/fonts//tfm:$TEXMF/fonts//tfm
% Just an abbreviation.
pkdir = $TEXMF/fonts//pk
privatepkdir = $TEXMF/private/fonts//pk
and so on? It works, and neatly separates the publishable
glyphs from the commercial ones.
(This is a nasty old supplier-first organization, but it's
my own system.)
%=======================================================================%
| 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, 13 Sep 1995 06:02:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 13 Sep 1995 11:58:11 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509131058.LAA03986@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <199509121519.AA19818@terminus.cs.umb.edu>
> Since TeX has to find the image files to get the bounding boxes, I
> think they should be under tex//. I don't see the advantage to breaking
> them out.
i'm with Karl on this. though i think Alan has a point. we should
mention it in the TDS, as he says
>
> You'd have to duplicate all the paths with two different TEXMF's.
>
> There've been some discussions of directly supporting multiple trees,
> but I have yet to be convinced it's worthwhile.
what do i do when i get a Unix plug-n-play CD out? (which is another
matter to bring up here). I copy it all to some single untouchable
read-only server for a whole group of projects, to provide a base. each
project then has its own packages, fonts, needs etc, and should/could
run a parallel tree of their private stuff, no?
> that, as we all know. Multiple TEXMF's is a lot more painful than
> caching, believe me.
if its not obvious, then i have no problem with complicated texmf.cnf
files in practice
> Are there any real local installations out there with two complete texmf
> trees?
i could imagine starting one
> carlisle> I think the idea of `registering' every such name is a
> non-starter.
>
> I agree. I don't see the win here, Sebastian. Explain?
i just want to ensure that if you see tex/latex/umb, it means the same
thing to you and me both.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Sep 1995 12:23:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 13 Sep 1995 11:06:44 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509131506.AA09595@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
odd classifying images as TeX sources, just because TeX happens to be
one of the programs which reads them.
It is weird, I agree. But I don't see any practical value in
complicating the TEXINPUTS path.
But I guess I don't particularly care whether the files are
texmf/images/<type>/<bundle> or texmf/tex/images/<type>/<bundle> or
even texmf/tex/generic/images/<type>.
I think I like that last, for images that aren't part of any package.
(I don't know if there are any packages that include .eps's, for that matter.)
But what are <type> and <bundle>?
But I think we should say
something about where they should go.
I agree.
> Are there any real local installations out there with two complete texmf
> trees?
i could imagine starting one
I can imagine lots of things :-). Even with a readonly tree off a CD, I
suspect some people will prefer to make individual local directories
with additional stuff, rather than a complete separate tree. No one will
prefer any one thing. I don't know. Let's work on getting the CD out :-).
i just want to ensure that if you see tex/latex/umb, it means the same
thing to you and me both.
At the moment I export a `umb' package to the world, that's the moment
at which it should be registered, using whatever mechanisms we have for
registering packages in general. (At the moment, that mechanism being
``existence on CTAN'' :-). How's that?
================================================================================
From owner-twg-tds@shsu.edu Wed, 13 Sep 1995 16:59:10 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0ssvcR-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 13 Sep 95 18:29 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
>I think I like that last, for images that aren't part of any package.
>(I don't know if there are any packages that include .eps's, for that matter.)
The `canonical example' is probably local images such as university
crests. I guess these could live in (eg)
texmf/tex/latex/sussex/ssxcrest.eps, but this does mean that if I ever
wrote plain macros for sussex letters (OK, pretty unlikely!) then I'd
be in trouble.
Alan
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Sep 1995 01:02:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 13 Sep 95 23:00:34 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9509140600.AA11363@cfcl.com>
To: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: I'm back (I think :-)...
I am still quite interested in the idea of a Registry for TDS names, but
I never got much (read, ANY) reaction to my specific proposals from the
TeX wizards out there. SPQR has asked me to jump back into the fray,
however, so I will.
As I see it, there are two problems a Registry can and should solve:
1. It should document TeX-related packages in sufficient detail
that a prospective user can find out (a) what the package is
good for, (b) where it can be obtained, (c) who maintains it,
et copious cetera.
This problem has been addressed in at least three organized ways:
a. The PTF "0.doc" files and HTML pages. (The latter may be
seen on www.ptf.com, and will appear on the next issue of
"Prime Time TeXcetera".)
This format is not optimized for machine-readability, but
we might be able to translate it into another which is...
b. The DRAFT specification of the IETF IAFA working group,
which defines a format for indexing information found on
Internet FTP archives. This is used by the ALIWEB server.
c. The "LSM" files used by the Linux community.
The latter two are essentially equivalent, for our purposes.
The IAFA may be more tightly specified; the LSM is certainly
more widely used. I have no strong preference in the matter.
2. It should unambiguously define the portion of the TDS name
space occupied by the package.
My initial notions (see my earlier postings) started with the
idea of specifying an explicit set of directory paths. I also
suggested that some form of wild-carding (regular expressions)
could be used to shorten the description. Finally, I said that
it might be possible to give (a) a name and (b) a package "type"
and let default rules establish which directories would be used.
In retrospect, I think I prefer a merger of these three ideas.
The package author defines the type (and paths) by listing the
top-level directories across which the name is claimed. (The
doc directories corresponding to the mainline directories would
also be reserved.)
I think this has the advantages of safety, simplicity, and
generality. If I lay claim to fonts/morin/martian/, I
should reserve any directories my font could reasonably use.
Here is a simplistic set of examples:
path example
==== =======
/ dvips, web2c
bibtex/bib/ ?
bibtex/bst/ ?
fonts/ public/cm
metafont/ plain
metapost/ plain
tex/format/ plain
tex/generic/hyphen/ ?
tex/generic/misc/ texnames
tex/generic/package/ babel
I suspect that a TeXnician could boil these down further. It might
be, for instance, that "plain" should be unique within "/". Let me
know about stuff like this, please... Also, would someone who has
built a reasonable-size TDS tree be willing to look into it and tell
us how much chaos this scheme would cause?
Yours, Rich
rdm@cfcl.com
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Sep 1995 03:04:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Sep 1995 09:00:50 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509140800.JAA18625@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <199509131506.AA09595@ra.cs.umb.edu>
> I think I like that last, for images that aren't part of any package.
> (I don't know if there are any packages that include .eps's, for that matter.)
any "local" one will, for eg a letter head. my local elsevier setup
has 3 or 4 logos as EPS files
> But what are <type> and <bundle>?
other image types? tiff?
> But I think we should say
> registering packages in general. (At the moment, that mechanism being
> ``existence on CTAN'' :-). How's that?
a fair practical criterion, i agree
s
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Sep 1995 09:41:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Sep 1995 10:40:11 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509141440.AA09363@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: rdm@cfcl.com
Subject: Re: I'm back (I think :-)...
generality. If I lay claim to fonts/morin/martian/, I
Except supplier-first lost the battle, so it has to be fonts/*/morin/martian
:-(. Also, if you're the first Martian font designer, I think it'd
reasonable to put it in fonts/*/public/martian. If it was public, of course.
be, for instance, that "plain" should be unique within "/". Let me
I don't understand. There is no texmf/plain, just
texmf/{tex,metafont,metapost}/plain. The everything-in-a-package name
proposal was rejected, tooo ...
I doubt anyone has strong feelings for any particular format for the
header info. I sure don't. Any automatic generation from what we've got
now will sure be a win ...
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Sep 1995 10:57:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Sep 95 08:51:59 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9509141551.AA11884@cfcl.com>
To: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: TDS Registry
Karl notes that fonts/morin/martian/ is incorrect, suggesting
fonts/*/morin/martian/ instead. Because there are two intervening
directories, this should really be fonts/*/*/morin/martian/, but I
imagine that I would be better served to claim fonts/*/*/morin/ as
a whole, then create subsidiary entries as desired. (There is no
purpose served by allowing two font developers to share the same
"supplier" name, and a supplier *should* be able to keep its own
name space clean.)
My Martian fonts could certainly go in as fonts/*/*/public/martian/,
unless I thought I was likely to have competition down the canal (:-).
My suggestion that "plain" be unique within "/" derives from the
observation that "plain" shows up in several sub-trees. I don't
think, for instance, that it would be a Good Thing for anyone other
than Dr. Knuth to develop a new package (font, etc.) named "plain".
On the other hand, if a developer has several independent packages
named "foo", it *might* be appropriate for each one to have its own
registration, if only to make it clear that they are unrelated items.
My only reservations on the header info stem from wanting to balance
the need for information with keeping the effort (and fascism) to a
minimum. We should probably make a template available, with flags to
show which fields are required, etc.
Getting on to mechanization, my current notion is that we need
a multi-stage procedure:
1. submission
2. sanity check
3. public comment
4. acceptance
After looking in CTAN/tex-archive/tds/registry (or an equivalent WWW
server), I would submit a filled-in template. This would be checked
for obvious errors and conflicts, then installed as a "prospective"
registration. If no conflict arose within (say) 90 days, it would be
accepted as a full registration.
PTF would certainly be willing to assist in any effort to generate
registration information from our (or others') documentation files.
It may be, however, that the public comment period should be longer
for this sort of "mass registration", as it could take longer for any
problems to be spotted.
-r
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Sep 1995 11:32:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Sep 1995 10:47:10 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509141447.AA09381@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
texmf/tex/latex/sussex/ssxcrest.eps, but this does mean that if I ever
As you suggested, texmf/tex/generic/images/sussex/ssxcrest.eps?
(or `local' instead of `sussex', but that's another discussion :-)
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Sep 1995 12:03: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: <199509141701.TAA17738@spice.iti.informatik.th-darmstadt.de>
Subject: Re: I'm back (I think :-)...
To: TWG-TDS@SHSU.edu
Date: Thu, 14 Sep 1995 19:01:26 +0200 (MESZ)
Content-Type: text
Rich wrote:
>
> I am still quite interested in the idea of a Registry for TDS names, but
> I never got much (read, ANY) reaction to my specific proposals from the
> TeX wizards out there.
Oops, I have forgotten to forward to this list a discussion I had on
comp.text.tex. It started with the question of easier TeX
installation, and I presented the TDSR idea as a means to get
automatic installation. I append my old article below, FYI.
For the record: 5 people reacted. 3 thought that the whole hassle is
unnecessary anyhow, and 2 agreed to my proposal. Neither the amount
nor the tendency of this reaction encouraged my to follow this path
further.
Executive summary: Compared to Rich's proposal, I would prefer a more
high-level description, where the directory information may be deduced
from automatically and where the information doesn't need updates more
often.
Cheers
Joachim
---------------- included article follows:
From: schrod@iti.informatik.th-darmstadt.de (Joachim Schrod)
Subject: Re: Installing LaTeX2e: A Suggestion
Newsgroups: comp.text.tex
Distribution: world
Followup-To:
References: <jhh.804928700@news.cwi.nl> <3tdn05$kl2@hippo.shef.ac.uk> <3te83q$dcm@news.rwth-aachen.de>
Organization: TH Darmstadt, FG Systemprogrammierung
Keywords:
In article <3te83q$dcm@news.rwth-aachen.de>, dak@tabaqui.informatik.rwth-aachen.de (David Kastrup) writes:
>
> Now, the TDS standard committee is cooking a file structure up for
> all of us, suggesting what should go where. It would probably be not
> the worst of ideas to include a file
> tdsinfo
> in every distribution which specifies where this distribution wants
> to have all its files distributed to.
Very good idea. (A set of such files makes up the yet-nebulous idea
of a TDS registry that is mentioned in appendix A.2.)
> Somewhat along:
> *.ins: &latex
> *.drv: &latex
> wusel.dtx: &latex
> *.cls: tex/latex2e/packages/fulcro
> [...]
Hmm, you could just name the directories relativ to the TDS root
texmf. [footnotes *1 *2]
But let me bring up a similar, but different possibility: a more
high-level description. I.e.:
----------------
Bundle: foo % `Bundle' is an alias for field name `Package'
Category: latex % from a predefined set of categories
Run-Files: *.sty *.fd *.fmt % files needed at run time, to use it
Doc-Files: *.dvi foouser.tex README % files with _user_ documentation
Font-Supplier: public % see TDS, section 4
Font-Typeface: drake % logo of Sir Francis Drake Society :-)
----------------
This information is enough to install a distribution automatically in
a TDS tree. Of course, if some field is not appropriate, it should not
be mentioned. One can establish known abbreviations, too. E.g., the
`Run-Files' field could only mention $latex (or @latex) and this will
automagically expand to a list of known-extensions-from-the-LaTeX-world.
IMO this description is better as the file based one, as it not only
carries information for the installation program, but also information
for the human that wants to have an overview about the contents of that
distribution.
Of course, support for the interpretation of such a description is up
to the respective TeX sub-communities (the Unix, DOS, VMS, etc.,
camps).
I would like to get feedback for that idea, please post or send
comments. There has been discussions about a proposed minimum standard
for supported LaTeX bundles. The current result of this discussion is
available as ftp://ftp.th-darmstadt.de/pub/tex/latex/bundle-dist.tex.gz .
I'm currently working on Perl scripts that will help to check incoming
CTAN submissions for compliance with these guidelines and to ask
authors for improvements in their next release... (They have been
written already, I'm in the test phase.)
These guidelines already demand a CATALOG file with information about
the bundle. We could add easily fields like those outlined above.
Even make them mandatory?!
The CATALOG file can be an input for the planned TeX Package Registry,
discussed recently on this newsgroup.
So -- if any authors of packages are still reading: Would you be
willing to add such a file? Please send me mail or post. If enough of
you authors -- yes, We Want You :-) -- are willing to add such a file,
I would fix a proposal for a format.
A Perl script for the installation job can be written very quickly.
As an aside note for the non-Unix user community: Perl is
available for many other platforms. If you don't have it, please
don't complain about Unix-centrism. Add _your_ volunteer contribution
to the TeX community and write an installation system that interprets
a file like above. Use a system that is well known and wide spread in
_your_ user community, be it REXX or Visual Basic or whatever.
OK, one last remark:
> Note that this looks suspiciously similar
> to make file syntax [...]
> So one could probably even use plain old makefiles, and not many
> people suffer harm from that.
I don't think that's possible. To write portable Makefiles is a pain
in the a**, even if you generate them with sed (aka GNU autoconf) or
cpp (aka Imake). You won't use the up-to-date-check feature of make
anyhow. And in the actions you'll need commands that are the same on
every platform: on Unix, DOS, VMS, etc. That some make is available
there as well doesn't make the Makefile portable. I'll would enjoy to
get proved wrong -- but I fear that's a bite too big to swallow.
Cheers, -- and send in your comments to these remarks
Joachim
----------------------------------------
Footnotes:
[*1] As there has been already the reproach of Unix centrism in this
thread, let me please note that the notion of `a/b/c' for a file in a
directory hierarchy is not a Unix-only notion. (It certainly has its
roots there.) It's the notion used in the ISO/IEEE standards for
Portable Applications. Of particular relevance is the standard ISO
9945-1 `System Application Program Interfaces' (aka IEEE 1003.1).
That standard is nowadays available on many platforms, including DOS
& VMS. (It's even there on MVS.)
[*2] Some more comments on the content of the proposal, maybe I
didn't understand it completely:
> *.ins: &latex
> *.drv: &latex
> wusel.dtx: &latex
Hmm, what does `&latex' mean here?
These files should be available in
source/latex/<bundle>/
where <bundle> is the name of the distribution unit. (I.e., the
subdirectory from contrib/{supported,other}/) and the files should
just stay there.)
> %what syntax for makeindex files?
*.ist: makeindex
> *.cls: tex/latex2e/packages/fulcro
*.cls: tex/latex/fulcro % no packages/ subdir :-)
> *.dvi:
*.dvi: doc/latex/<bundle>/ % maybe doc/latex/misc/
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Sep 1995 05:56:19 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0stYNE-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 15 Sep 95 11:52 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
>As you suggested, texmf/tex/generic/images/sussex/ssxcrest.eps?
Or texmf/tex/generic/images/epsf/ssxcrest.eps?
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Sep 1995 06:11: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: <199509151109.NAA19333@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Installing TDS at Sussex
To: TWG-TDS@SHSU.edu
Date: Fri, 15 Sep 1995 13:09:44 +0200 (MESZ)
Content-Type: text
You wrote:
>
> >As you suggested, texmf/tex/generic/images/sussex/ssxcrest.eps?
>
> Or texmf/tex/generic/images/epsf/ssxcrest.eps?
For the record: I'm against both.
TDS says:
texmf/tex/<format>/<package>/<file>
I'd like to stick with that. We have already enough open problems, we
shouldn't add another one.
I.e., I've nothing against storing EPS files in <format>==generic.
But I'm against the introduction of yet another directory level.
What's the problem with
texmf/tex/generic/{sussex,local,misc}/ssxcrest.eps
Choose the name of the <package> level as you like, that's not really
the problem. IMHO it's more important to warn people against the usage
of names like thesis.sty. File names like ssxcrest.eps are OK, the
probability to appear in several places is minimal.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Sep 1995 06:13:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 15 Sep 1995 12:09:22 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509151109.MAA26263@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <m0stYNE-0001iBC@csrj.crn.cogs.susx.ac.uk>
Alan Jeffrey writes:
> >As you suggested, texmf/tex/generic/images/sussex/ssxcrest.eps?
>
> Or texmf/tex/generic/images/epsf/ssxcrest.eps?
>
> Alan.
>
no, texmf/tex/generic/images/epsf/sussex/ssxcrest.eps, or else you
can't identify it easily. or images/epsf/misc.
but you are screwing the convention of tex/<format>/<package>/<files>
which has come up before. dont we agree that we dont permit multiple
levels there?
s
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Sep 1995 09:46:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 15 Sep 1995 10:45:32 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509151445.AA20386@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
> Or texmf/tex/generic/images/epsf/ssxcrest.eps?
For the record: I'm against both.
TDS says:
texmf/tex/<format>/<package>/<file>
Alan's point (as I understand it :-) was that a .epsf file could be used
by either tex or latex or whatever format, so it's a bit ugly to just
pick one arbitrarily.
How about
texmf/tex/epsf/sussex/ssxcrest.eps
???
(Where's the win in merging all conceivable image formats under images/?)
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Sep 1995 10:18:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 15 Sep 95 16:16:44 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9509151516.AA08852@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
Karl> texmf/tex/epsf/sussex/ssxcrest.eps
This looks the best of the bunch so far.
Of course here the local eps logo is shared between letter templates
for LaTeX and Framemaker. I doubt whether Framemaker users would
manage that path (they all think TeX is some kind of plague:-)
but I expect a few symbolic links will come to the rescue.
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Sep 1995 16:10:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 15 Sep 1995 16:23:16 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509151523.QAA08028@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <9509151516.AA08852@r8h.cs.man.ac.uk>
David Carlisle writes:
>
>
> Karl> texmf/tex/epsf/sussex/ssxcrest.eps
>
> This looks the best of the bunch so far.
not
texmf/tex/images/sussex/ssxcrest.eps
?
> Of course here the local eps logo is shared between letter templates
> for LaTeX and Framemaker. I doubt whether Framemaker users would
> manage that path (they all think TeX is some kind of plague:-)
you work with Framemaker? you need care in the tex community
s
================================================================================
From owner-twg-tds@shsu.edu Sun, 17 Sep 1995 00:55:25 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0stxQH-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Sat, 16 Sep 95 14:36 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, TWG-TDS@SHSU.edu, TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
>What's wrong with:
>% Ditto for MF.
>MFINPUTS = .:$TEXMF/mf//:$PRIVATE/fonts//src//:$TEXMF/fonts//src//
This works if the users are well behaved and put their fonts where I
tell them to. As it happens, at this site, I doubt if anyone will
ever install a font other than me, so I don't think it's a worry.
This isn't necessarily true the world over though...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Sun, 17 Sep 1995 07:32:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 16 Sep 1995 12:07:14 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509161607.AA05290@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
not
texmf/tex/images/sussex/ssxcrest.eps
Since drivers are likely to support multiple image file types, this
seems cleaner to me. The file extension should serve sufficiently to
distinguish so a .eps file doesn't get read when the driver is looking
for a .pict. Or whatever.
================================================================================
From owner-twg-tds@shsu.edu Sun, 17 Sep 1995 14:00: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: <199509171859.UAA14984@spock.iti.informatik.th-darmstadt.de>
Subject: Open Problems
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Sun, 17 Sep 1995 20:59:13 +0200 (MESZ)
Content-Type: text
At EuroTeX I made an error -- I agreed to collect the open problems
that have been mentioned on this list since we distributed the draft.
IMO, many of the stuff are not really problems, it's just that
somebody must sit down and must write it up. ;-)
I'm loosing my job in two weeks (and have no new one yet), so don't
expect much engagement from me in formulation issues.
Cheers,
Joachim
---------------- included: open-problems.txt:
-- One must not use texmf/tex// as search path, due to duplicate
files. TEXINPUTS must be set for each format anew. (There may be
reasonable defaults, but eventually that's the bottom line.)
[Paul Vojta]
-- PK files not generated by MF go in
fonts/pk/modeless/<utility>/dpi<dpi>/<font>.pk
[Joachim & Karl]
-- Where are binaries placed?
o Non-Unix folks don't like bin/<platform>/.
o Distribution of binaries over all kind of directories is not
sensible. Placing binaries in TeX distribution dirs (as
proposed by Christian Spieler) covers only a small part of the
problem, that of the distributor -- where shall a TeX admin
place the binaries [s]he has made locally?
IMO, we should discard that issue and mention explicitely that
we could not reach a consensus on that topic. We should
mention that one needs platform-specific directories very
often.
[Christian, Pierre, Karl, sebastian, Joachim]
-- It must be made more explicit that format, base, & pool files are
placed in the <TeX implementation> tree. It's in the draft, but
this is the most FAQ, the wording must therefore be improved.
Perhaps one might also need to add a rationale (a) why it's
there and (b) why we don't specify _where_ it is placed
there. [(a) since these files are inherently implementation-
dependend; (b) since we cannot enforce it on developers, we
would structure _their_ area.] We should made explicit that
we encourage developers/distributors to tell us where their
FMT files will be placed, and should add that information in
an appendix.
[tons of people]
-- An appendix should be added that outlines known structures of <TeX
implementation> trees. It must be made explicit that this
structure is for a specific version, is not fixed, and may change
in the next version; it's just for informational purposes (to see
what `others' have done).
Most questions concerned the implementation-dependent area.
People want to know something about this.
[Christian, Pierre, Karl, Thomas]
-- TDS Registry -- what do we do with it?
I have to admit I didn't understood Rich's last proposal (item
2 of his mail from 13 Sep 95). I don't know how software shall
process it to check the tree automatically for conformance, or
do installation. And for me, that's the bottom line -- a
registry that does not provide informations to handle these
tasks is not my beef.
[Rich, Joachim, sebastian; -- Tobi Oetger [sp?]?!]
-- Reserve package name local/, FWIW.
I'm not convinced that it will really help, but it won't
introduce problems either; so we should just add it.
[Alan, Karl, sebastian]
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 18 Sep 1995 03:10:20 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0sugqg-0003DSC@gauss>
Date: Mon, 18 Sep 95 10:07 EDT
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Open Problems
> -- One must not use texmf/tex// as search path, due to duplicate
> files. TEXINPUTS must be set for each format anew. (There may be
> reasonable defaults, but eventually that's the bottom line.)
> [Paul Vojta]
I do not understand what the problem is. Or, are there systems where
setting up different search paths are difficult? Or, is the problem
that this is not yet properly explained in the current draft?
> -- PK files not generated by MF go in
> fonts/pk/modeless/<utility>/dpi<dpi>/<font>.pk
> [Joachim & Karl]
Hm... No supplier/typeface part? Another thing: I do not like that
the files of the same type (e.g. .pk files) are stored at different
directory levels. If you compare
fonts/pk/cx/public/cm/dpi300/cmr10.pk # 6 dir. levels
with
fonts/pk/modeless/gsftopk/dpi300/ptmr8r.pk # 5 dir. levels
fonts/pk/modeless/gsftopk/adobe/times/dpi300/ptmr8r.pk # 7 dir. levels
then the modeless are always off by one...
I do not like the extra modeless directory...
> -- Where are binaries placed?
> o Non-Unix folks don't like bin/<platform>/.
And UNIX folks do not like fonts/type ... :-) In my opinion, binaries
info pages and manpages should be keep out of the draft. Maybe a
recommendation where to put them, but it should be clear that these
could be outside the texmf tree, too.
> -- It must be made more explicit that format, base, & pool files are
> placed in the <TeX implementation> tree. It's in the draft, but
> this is the most FAQ, the wording must therefore be improved.
I absolutely agree..
> -- An appendix should be added that outlines known structures of <TeX
> implementation> trees. It must be made explicit that this
> structure is for a specific version, is not fixed, and may change
> in the next version; it's just for informational purposes (to see
> what `others' have done).
Yes, I like that, too.
Thomas
================================================================================
From owner-twg-tds@shsu.edu Mon, 18 Sep 1995 03:52:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 18 Sep 1995 10:50:56 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Feeling uncomfortable with designation `public'
To: TWG-TDS@SHSU.edu
Message-ID: <01HVF2TFTXDE9PLVJB@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
I feel more and more uncomfortable with the designation `public' in the
font tree. I think, all ``supported'' fonts should be sorted under their
supporter.
The reasons are:
a) `public' is easily mistaken for `public domain' by the general public,
allthough almost all font currently sorted under `public' aren't.
b) There is ongoing talk (e.g. on comp.fonts) which wants to equate
public with low quality. Of course, the originators of that talk have
commercial interest in this perception, however the contributors of
free font probably don't want to find their work in a directory named `low
quality' in public perception.
c) For supported fonts, the authors accept bug reports (even if they may
wait 3 years before taking them from their stack). So why not giving the
athors credit in the directory tree?
d) Even the font donated by their founderies to the X consortium (and are
therefore more public than many `public' METAFONTs) are listed in the
sample tree under the name of the foundery. So there's unequal treatment
of `public' fonts.
For me (as a font author), b) is most serious.
--J"org Knappen
================================================================================
From owner-twg-tds@shsu.edu Mon, 18 Sep 1995 06:57:18 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0suelF-0001iSC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 18 Sep 95 12:53 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Feeling uncomfortable with designation `public'
>I feel more and more uncomfortable with the designation `public' in the
>font tree. I think, all ``supported'' fonts should be sorted under their
>supporter.
Agreed. I don't see why B&H should be treated differently from DEK,
just because they make a profit from Lucida.
Perhaps Damian, Jeremy and I should form our own font foundry so we
can be included in TDS...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 18 Sep 1995 07:04: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: <199509181201.OAA18248@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Open Problems
To: TWG-TDS@SHSU.edu
Date: Mon, 18 Sep 1995 14:01:41 +0200 (MESZ)
Content-Type: text
Thomas wrote:
>
> > -- One must not use texmf/tex// as search path, due to duplicate
> > files. TEXINPUTS must be set for each format anew. (There may be
> > reasonable defaults, but eventually that's the bottom line.)
> > [Paul Vojta]
>
> I do not understand what the problem is. Or, are there systems where
> setting up different search paths are difficult? Or, is the problem
> that this is not yet properly explained in the current draft?
The latter. The draft gives the impression as if texmf/tex// might be
a good (i.e., valid) TEXINPUTS path. That's not true, filenames are
only unique over the trees tex/{<format>,generic}/. Come to think of
it, perhaps this should be added as an explicit requirement.
> > -- PK files not generated by MF go in
> > fonts/pk/modeless/<utility>/dpi<dpi>/<font>.pk
> > [Joachim & Karl]
>
> Hm... No supplier/typeface part? Another thing: I do not like that
> the files of the same type (e.g. .pk files) are stored at different
> directory levels. If you compare
> fonts/pk/cx/public/cm/dpi300/cmr10.pk # 6 dir. levels
> with
> fonts/pk/modeless/gsftopk/dpi300/ptmr8r.pk # 5 dir. levels
> fonts/pk/modeless/gsftopk/adobe/times/dpi300/ptmr8r.pk # 7 dir. levels
> then the modeless are always off by one...
Yep, I got that wrong.
`fonts/pk/<utility>/<supplier>/<typeface>/dpi<dpi>/<font>.pk'
(or, alternatively, `.../<font>.<dpi>pk') was the last state of
discussion.
Basic point: The draft doesn't cover PK fonts not created by MF that
don't have a concept of modes.
> > -- Where are binaries placed?
> > o Non-Unix folks don't like bin/<platform>/.
>
> And UNIX folks do not like fonts/type ... :-) In my opinion, binaries
> info pages and manpages should be keep out of the draft. Maybe a
> recommendation where to put them, but it should be clear that these
> could be outside the texmf tree, too.
In case I wasn't clear enough: That's (almost) exactly my point. Move
the whole stuff to an appendix where we express our disagreement and
announce that we have to wait for further experiences.
To mention another (new) point: It isn't clear to me if the sentence
`emtex/texmf/ is wrong' is good. In contrary, I think it doesn't
capture the CD situation at all. E.g., _I_ would organize a
Unix-centric CD this way:
<mount point>/{bin,lib,texmf}/
(perhaps with a $PLATFORM somewhere in between), and I'd bet that
most people would use a directory name as the mount point that has
the `product' in it. I.e., they yield something like
/opt/unixtex/texmf/. (That may even lead to a directory
/opt/unixtex/texmf/unixtex/.) Your mileage may vary.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 18 Sep 1995 08:14:13 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0sufxL-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 18 Sep 95 14:09 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Open Problems
>I'm loosing my job in two weeks (and have no new one yet), so don't
>expect much engagement from me in formulation issues.
Good luck finding a new job!
> -- PK files not generated by MF go in
> fonts/pk/modeless/<utility>/dpi<dpi>/<font>.pk
> [Joachim & Karl]
Please no! Please either:
fonts/pk/modeless/<supplier>/<typeface>/dpi<dpi>/<font>.[dpi]pk
or (preferably):
fonts/pk/<utility>/<supplier>/<typeface>/dpi<dpi>/<font>.[dpi]pk
It's easy to get the <supplier> and <typeface> by looking to see where
the .tfm file is kept.
> -- Where are binaries placed?
> o Non-Unix folks don't like bin/<platform>/.
It's worth noting that sometimes non-Unix people have good reasons for
this! Eg on the Mac it's usual for an application to keep all of it's
associated files in the same folder as it, or in subfolders. Eg OzTeX
expects something like:
Applications
OzTeX
OzTeX
OzTools
Configs
texmf
ie texmf has to be under OzTeX, not the other way round. (It's
possible to fool it using symbolic links, sorry I mean aliases, but
this gets you into hot water when installations are copied off CD-ROM,
etc. because you end up copying the pointer rather than the
directory.)
> I'm not convinced that it will really help, but it won't
> introduce problems either; so we should just add it.
Or encourage people to use `sensible' names (eg sussex).
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 18 Sep 1995 19:09:49 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Mon, 18 Sep 1995 17:08:36 -0700
Message-ID: <199509190008.RAA21386@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Open Problems
On Mon Sep 18 07:46:08 1995,
Joachim Schrod <schrod@iti.informatik.th-darmstadt.de> wrote:
> Thomas wrote:
> >
> > > -- One must not use texmf/tex// as search path, due to duplicate
> > > files. TEXINPUTS must be set for each format anew. (There may be
> > > reasonable defaults, but eventually that's the bottom line.)
> > > [Paul Vojta]
> >
> > I do not understand what the problem is. Or, are there systems where
> > setting up different search paths are difficult? Or, is the problem
> > that this is not yet properly explained in the current draft?
>
> The latter. The draft gives the impression as if texmf/tex// might be
> a good (i.e., valid) TEXINPUTS path. That's not true, filenames are
> only unique over the trees tex/{<format>,generic}/. Come to think of
> it, perhaps this should be added as an explicit requirement.
On page 8 it says, ``a recursive search beginning at \path|texmf/tex|
is a correct path for {\TeX} inputs in a \abbr{TDS} tree.'' Are you saying
that this is incorrect? Or, are you saying that this is correct but that
texmf/tex// is an incorrect path for {\AmSTeX} and {\LaTeX} inputs?
If the latter, then this leads to a problem for authors of dvi drivers.
PostScript figures are also stored under texmf/tex, and the dvi driver has
to access them without knowing whether the dvi file came from plain TeX,
LaTeX, AmSTeX, or other. So non-uniqueness of file names will be a problem
at least for picture files.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Sep 1995 05:43: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: <199509191032.MAA21162@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Open Problems
To: TWG-TDS@SHSU.edu
Date: Tue, 19 Sep 1995 12:32:56 +0200 (MESZ)
Content-Type: text
Paul wrote:
>
> > The latter. The draft gives the impression as if texmf/tex// might be
> > a good (i.e., valid) TEXINPUTS path. That's not true, filenames are
> > only unique over the trees tex/{<format>,generic}/. Come to think of
> > it, perhaps this should be added as an explicit requirement.
>
> On page 8 it says, ``a recursive search beginning at \path|texmf/tex|
> is a correct path for {\TeX} inputs in a \abbr{TDS} tree.''
Ooh, even worse.
> Are you saying
> that this is incorrect?
Yes. And that's independent of TDS. There have been cases in the
past, where two different files with the same name are part of two
different macro packages. The most prominent example is LaTeX 2.09
vs. LaTeX, but there are other ones, too. (E.g., there were *.sty
files for Vanilla TeX in PC-TeX distribution that were in conflict
with the LaTeX files.)
I.e., *for TeX*, it is not valid to search all possible locations of
macro files for any format, as there may be (will be) name conflicts.
If one assumes sensible names for EPS files, there should not be any
name conflicts -- except if two lusers introduce a logo.eps. ;-)
Therefore I would assume that texmf/tex// is a valid (and good)
search path for DVI drivers if they need access to such files. (Of
course, slow without caching.) If programs need to locate macro
files, they must now the format for it.
Joachim
PS: More and more I come to the point that the discussion of `there
are no unique macro file names' should be part of the rationale.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Sep 1995 05:50:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Sep 1995 06:48:54 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509191048.AA23745@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Open Problems
the open problems
that have been mentioned on this list since we distributed the draft.
Thanks for putting this together.
My first question is, Norm, are you still out there? Will you have time
to edit and prepare the next version? I wouldn't mind doing it, but I
don't have any SGML facilities, so I'd have to go back to straight
(some-flavor-of) TeX.
We need to settle this before getting to the nitty-gritty of text changes.
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Sep 1995 05:50:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Sep 1995 06:48:54 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509191048.AA23753@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: texmf/tex//
-- One must not use texmf/tex// as search path, due to duplicate
files. TEXINPUTS must be set for each format anew. (There may be
[speaking as stds-type person]
I do not think the standard should require users to have a different
TEXINPUTS path for each format, or implementors to support this
feature. In practice, is there a problem for anything besides latex 2.09
vs. latex2e?
I think we already recognize that there is a potential problem; we
should probably recommend more strongly that implemntors support it.
[speaking as implementor]
On the other hand, if no other implementor objects, I certainly don't.
My programs already support this feature, and have for ages.
That's not true, filenames are
only unique over the trees tex/{<format>,generic}/.
Say what? As far as I know, we've always been assuming filenames are
unique over the entire tree. Or, more precisely, if filenames are not
unique, results are unspecified without a more precise path. What's
wrong with this?
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Sep 1995 05:51:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Sep 1995 06:49:14 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509191049.AA23770@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: bin/, info/, man/, ...
-- Where are binaries placed?
Like Joachim and Thomas, I am entirely in favor of dropping the bin/
stuff out of the main part of the document (if not just removing it
entirely). I'm not sure it's a viable proposal for more than a handful
of sites, so probably doesn't deserve such prominent positioning.
info pages and manpages should be keep out of the draft. Maybe a
I seem to recall some recent discussions about this, but I don't
remember the conclusion. Isn't $TEXMF/man a natural place to put man
pages? (Etc.) Shouldn't we recognize that fact? That's not to say
everyone has to have it.
In fact, I seem to remember being opposed to $TEXMF/man because of its
platform-centrism, but then other people pointed out other platforms
have man pages, and so on and so on. Sounded right to me.
recommendation where to put them, but it should be clear that these
could be outside the texmf tree, too.
That is clear anyway. We already say that any of the directories we give
in the std need not exist at any particular site, unless they are useful
there ..
`emtex/texmf/ is wrong' is good. In contrary, I think it doesn't
Hmm, seems reasonable. I think there are lurking implications here, though.
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Sep 1995 05:51:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Sep 1995 06:49:15 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509191049.AA23778@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: hopefully non-controversial miscellany
-- It must be made more explicit that format, base, & pool files are
placed in the <TeX implementation> tree. It's in the draft, but
Fine.
-- An appendix should be added that outlines known structures of <TeX
implementation> trees. It must be made explicit that this
Fine. I doubt much of a tree will be needed under emtex/ or web2c/
whatever. Certainly I'm not planning on any tree, just a couple of files.
-- TDS Registry -- what do we do with it?
I dunno. Suggest that does not need to be settled for the next draft to
happen.
-- Reserve package name local/, FWIW.
I'm not convinced that it will really help, but it won't
introduce problems either; so we should just add it.
It will help some people, it won't help others. As you say, it doesn't hurt.
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Sep 1995 05:51:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Sep 1995 06:49:16 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509191049.AA23786@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Feeling uncomfortable with designation `public'
I feel more and more uncomfortable with the designation `public' in the
Fine. public/ seems to be misunderstood/misused by everyone, so let's
drop it.
b) There is ongoing talk (e.g. on comp.fonts) which wants to equate
public with low quality. Of course, the originators of that talk have
I sincerely doubt a directory name will make any difference as to
people's opinions of font quality. Good fonts will become well-known,
bad fonts will be forgotten, by their very nature. But this is a side issue.
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Sep 1995 05:51:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Sep 1995 06:48:55 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509191048.AA23761@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: dak@pool.informatik.rwth-aachen.de
Subject: modeless fonts
-- PK files not generated by MF go in
fonts/pk/modeless/<utility>/dpi<dpi>/<font>.pk
[Joachim & Karl]
te> I do not like that
the files of the same type (e.g. .pk files) are stored at different
alan> or (preferably):
fonts/pk/<utility>/<supplier>/<typeface>/dpi<dpi>/<font>.[dpi]pk
The reason for the modeless/ directory, as I recall, is that searches
should generally take place over (1) the mode-specific directory (if any),
and (2) *all* mode-nonspecific directories (gsftopk, ps2pk, ...).
For example, for xdvi, one explicitly has to put the gsftopk// and ps2pk//
into the path, along with the usual $MODE//. Otherwise the PostScript
fonts aren't found.
That said, I'm not sure it's worth making the tree inconsistent just to
be able to say modeless//. Having the utility name serve as a mode name
seems natural.
Basic point: The draft doesn't cover PK fonts not created by MF that
don't have a concept of modes.
Yes, we do mention this. We say to use the utility name as the mode name.
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Sep 1995 13:17:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 19 Sep 1995 14:15:52 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: texmf/tex//
To: TWG-TDS@SHSU.edu
Message-ID: <811534552.729600.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
karl:
-- One must not use texmf/tex// as search path, due to duplicate
files. TEXINPUTS must be set for each format anew. (There may be
[speaking as stds-type person]
I do not think the standard should require users to have a different
TEXINPUTS path for each format, or implementors to support this
feature. In practice, is there a problem for anything besides latex 2.09
vs. latex2e?
although at the moment, i think we're down to a reasonable number of
versions of (la)tex, there have been times when we had as many as 5
live at once. and indeed this *does* require redefinition of the
texinputs path, because while one is migrating a production system
from one version to a new one, it's not always practical to rename
every single macro file or to rebuild for robustness under all
conditions.
another reason for specifying a variant texinputs path is for testing.
so, even though it may not be essential for the texinputs path actually
to be changed under any random circumstances, it is very necessary
that the *ability* to change the path be supported. (or have i
misunderstood something?)
-- bb
================================================================================
From owner-twg-tds@shsu.edu Tue, 19 Sep 1995 14:00:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Sep 1995 16:59:23 +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: <950919165923.22a3c70e@vms.rhbnc.ac.uk>
Subject: Re: Open Problems
Joachim wrote:
>> PS: More and more I come to the point that the discussion of `there
>> are no unique macro file names' should be part of the rationale.
Joy, joy: now if only the discussion had _started_ from that
perspective, the outcome might have been very different. ** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Sep 1995 03:29:31 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0svPyE-0003HUC@gauss>
Date: Wed, 20 Sep 95 10:17 EDT
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: bin/, info/, man/, ...
> info pages and manpages should be keep out of the draft. Maybe a
>
> I seem to recall some recent discussions about this, but I don't
> remember the conclusion. Isn't $TEXMF/man a natural place to put man
> pages? (Etc.) Shouldn't we recognize that fact? That's not to say
> everyone has to have it.
>
> In fact, I seem to remember being opposed to $TEXMF/man because of its
> platform-centrism, but then other people pointed out other platforms
> have man pages, and so on and so on. Sounded right to me.
Yes, now I remember, too. But I still suggest to handle bin, man and
info the same way. If the bin will be taken out of the draft, then
man and info should be, too.
man and info pages change with new versions of the binaries in general
and are distributed together with the sources of the binaries. Putting
just a part of this into the texmf tree seems like a looser to me.
Thomas
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Sep 1995 03:30:14 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0svPyE-0003HUC@gauss>
Date: Wed, 20 Sep 95 10:17 EDT
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: bin/, info/, man/, ...
> info pages and manpages should be keep out of the draft. Maybe a
>
> I seem to recall some recent discussions about this, but I don't
> remember the conclusion. Isn't $TEXMF/man a natural place to put man
> pages? (Etc.) Shouldn't we recognize that fact? That's not to say
> everyone has to have it.
>
> In fact, I seem to remember being opposed to $TEXMF/man because of its
> platform-centrism, but then other people pointed out other platforms
> have man pages, and so on and so on. Sounded right to me.
Yes, now I remember, too. But I still suggest to handle bin, man and
info the same way. If the bin will be taken out of the draft, then
man and info should be, too.
man and info pages change with new versions of the binaries in general
and are distributed together with the sources of the binaries. Putting
just a part of this into the texmf tree seems like a looser to me.
Thomas
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Sep 1995 07:00: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: <199509201158.NAA19712@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Open Problems
To: TWG-TDS@SHSU.edu
Date: Wed, 20 Sep 1995 13:58:53 +0200 (MESZ)
Content-Type: text
You wrote:
>
> Joachim wrote:
>
> >> PS: More and more I come to the point that the discussion of `there
> >> are no unique macro file names' should be part of the rationale.
>
> Joy, joy: now if only the discussion had _started_ from that
> perspective, the outcome might have been very different. ** Phil.
For the record: I mentioned the point that one needs different macro
file search paths for different formats very early. (Partly, because
I use them since years in my installation setups, utilizing shell
scripts.) The reason above was implied. I don't think that
explicating the reason would have changed the outcome -- no
experience exists for more radical approaches, and developers won't
support them anyhow.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Sep 1995 07:04:22 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509201203.OAA21778@spice.iti.informatik.th-darmstadt.de>
Subject: Re: texmf/tex//
To: TWG-TDS@SHSU.edu
Date: Wed, 20 Sep 1995 14:02:59 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> That's not true, filenames are
> only unique over the trees tex/{<format>,generic}/.
>
> Say what? As far as I know, we've always been assuming filenames are
> unique over the entire tree.
???? Over which tree? texmf/? That's not true, to start with font
names. But it's also not true for macro files. We can assume that
macro files for one format have unique file names. But not in a wider
area. Well, above I also added the restriction that they should not
conflict with generic/. (Since generic is used for every format, by
definition.)
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, 20 Sep 1995 09:52:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 20 Sep 1995 10:50:31 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509201450.AA14553@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: bin/, info/, man/, ...
man and info pages change with new versions of the binaries in general
and are distributed together with the sources of the binaries. Putting
just a part of this into the texmf tree seems like a looser to me.
Mm, good point.
I'm not opposed to removing them from the main part of the draft.
The urgent question is, who's going to do the editing?
If Norm no longer has time to do it, and no one else has SGML & time
enough either, I will grab the distributed draft and start making the
changes we've agreed as best as I can.
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Sep 1995 09:58:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 20 Sep 1995 10:57:03 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509201457.AA14676@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/tex//
that the *ability* to change the path be supported. (or have i
Yes, certainly, people should be able to set whatever path they want.
The question, as far as I know, is whether the TDS should require
implementors to provide a way to simultaneously define one path for one
program (latex-foo) and another path for another program (latex-bar).
I doubt we will get very far with such a requirement.
I'm also not convinced this is necessary or desirable.
================================================================================
From owner-twg-tds@shsu.edu Wed, 20 Sep 1995 10:31: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: <199509201529.RAA17262@spice.iti.informatik.th-darmstadt.de>
Subject: Re: texmf/tex//
To: TWG-TDS@SHSU.edu
Date: Wed, 20 Sep 1995 17:29:05 +0200 (MESZ)
Content-Type: text
You wrote:
>
> that the *ability* to change the path be supported. (or have i
>
> The question, as far as I know, is whether the TDS should require
> implementors to provide a way to simultaneously define one path for one
> program (latex-foo) and another path for another program (latex-bar).
Yes, we should. And it's no problem as every TeX implementation I
know of supports that requirement already. (By means of scripts or
resource files.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 21 Sep 1995 10:40:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 21 Sep 1995 11:38:52 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509211538.AA13656@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/tex//
> The question, as far as I know, is whether the TDS should require
> implementors to provide a way to simultaneously define one path for one
> program (latex-foo) and another path for another program (latex-bar).
Yes, we should.
Joachim, I'm afraid don't understand. What is the proposed change here?
Is the idea that we're just clarifying that this is the case? That
filenames need not be unique across different formats? There's no
``real'' change to the directory structure going on here, just better
explanations of the ramifications?
It's certainly true that *if* you have non-unique filenames, then you
must more precisely specify the path.
================================================================================
From owner-twg-tds@shsu.edu Fri, 22 Sep 1995 06:52:38 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509221150.NAA19690@spock.iti.informatik.th-darmstadt.de>
Subject: Re: texmf/tex//
To: TWG-TDS@SHSU.edu
Date: Fri, 22 Sep 1995 13:50:54 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> > The question, as far as I know, is whether the TDS should require
> > implementors to provide a way to simultaneously define one path for one
> > program (latex-foo) and another path for another program (latex-bar).
>
> Yes, we should.
>
> Joachim, I'm afraid don't understand. What is the proposed change here?
>
> Is the idea that we're just clarifying that this is the case? That
> filenames need not be unique across different formats? There's no
> ``real'' change to the directory structure going on here, just better
> explanations of the ramifications?
Yes, that's my point. Describe the fact leading to a requirement, not
a technical solution.
\begin{digression}
As I've said in previous mails, the TDS document should not describe
implementation strategies, but should just describe layouts and add
the implications for requirements if we detect from our feedback that
the implications are not clear for our readers. To get the proposal
accepted by the TeX community, we have to make sure that the
requirements are implementable with the systems today. If the
implementation is not obvious, we should record that check in an
appendix, for our reader's information.
\end{digression}
There is an obvious implementation of the requirement for different
TeX input files search paths, namely wrapper scripts that set that
path. Most TeX implementations use some script (or configuration
file, in the case of GUI-based systems) anyhow to call TeX, since
they need to record the format somewhere.
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, 23 Sep 1995 08:43:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 23 Sep 1995 14:05:23 +0200
From: David Kastrup <dak@pool.informatik.rwth-aachen.de>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: modeless fonts
To: kb@cs.umb.edu
CC: TWG-TDS@SHSU.edu
Message-ID: <199509231205.OAA07266@stan.goethe.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Date: Tue, 19 Sep 1995 06:48:55 -0400
From: "K. Berry" <kb@cs.umb.edu>
Cc: dak@Pool.Informatik.RWTH-Aachen.DE
Content-Type: text
Content-Length: 1049
-- PK files not generated by MF go in
fonts/pk/modeless/<utility>/dpi<dpi>/<font>.pk
[Joachim & Karl]
The reason for the modeless/ directory, as I recall, is that searches
should generally take place over (1) the mode-specific directory (if any),
and (2) *all* mode-nonspecific directories (gsftopk, ps2pk, ...).
For example, for xdvi, one explicitly has to put the gsftopk// and ps2pk//
into the path, along with the usual $MODE//. Otherwise the PostScript
fonts aren't found.
That said, I'm not sure it's worth making the tree inconsistent just to
be able to say modeless//. Having the utility name serve as a mode name
seems natural.
The problem was that the idea of mode directories in the first place
was to separate fonts with equal resolutions designed for different
printers, not to separate Metafont from non-Metafont fonts. The
modeless subdirectory is *not* for non-Metafont files in particular,
but for those fonts where no other design characteristics than the
resolution are of any influence.
The modeless/<utility> naming scheme would, for instance, allow a
directory modeless/metafont as well, if someone used a generic
parameter set (for example, no fillin etc) for generation of the font.
For the font selection mechanism there is no particular reason even to
make a <utility> subdirectory tree under modeless: all fonts are
designed for that size, and that's that. In order to facilitate
searches over this "generic" branch of fonts with equal design
characteristics, it would be useful to have them in one tree. For
purposes of organization, however, one might contrive that sometimes it
might be of interest to separate this into separate trees
again. Specifically if one knows that a certain utility might generate
awful looking fonts which are of use only in emergencies, when no
other utility can generate them.
On the other hand, in the typical setup one will want to search one
mode-dependent font pool, and *all* mode-independent ones. The
"modeless" subdirectory tree warrants that.
Basic point: The draft doesn't cover PK fonts not created by MF that
don't have a concept of modes.
Yes, we do mention this. We say to use the utility name as the mode name.
Yes, but that does not take into account that *all* modeless fonts
have the common property of being usable at the resolution they are
specified for.
Now strictly speaking, as metafont-generatedness and modeness are not
related (one can contrive mode-dependent font-generating utilities
apart from metafont, and vice versa) a general layout of
mode/<utility>/...
would be the logical choice, leading to names like
fonts/pk/CanonDX/metafont/dpi300/cmr10.pk
as opposed to fonts like
fonts/pk/CanonDX/fetamont/dpi300/cmr10.pk for a differently named
utility generating mode-dependent files.
However, for a TeX-oriented tree, the extra mention of metafont
generaated files might seem a bit exaggerated.
So the <utility> subdivision might be of use mainly in the modeless
hierarchie. At least the distinction CanonDX/modeless is much more
useful than the distinction CanonDX/pstopk, which would imply that no
program other than metafont could ever produce printer specific fonts.
Another possible scheme would be the full <mode>/<utility> scheme
(where <mode> can be modeless as well) where /metafont would always be
left out.
This would have fonts/pk/CanonDX/dpi300/cmr10.pk (from metafont) as
opposed to fonts/pk/CanonDX/fetamont/dpi300/cmr10.pk. Perhaps a tadbit
ugly, but "upwards compatible" to metafont only outfits. And it is
still rather possible to search with appropriate patterns for
metafont-only fonts even in the mode-dependent directories (well,
something like fonts/pk/CanonDX/dpi*/*.pk -- oops, I believe web2c
will *not* currently allow patterns like that, perhaps it should?).
So for a consistent scheme I see two possibilities: either require
that current search strategies are extended to cover wishes like the
above mentioned one, or include metafont as utility name always, or
*never* include the utility name, or not allow any utility except
metafont to generate mode-dependent files.
Not much clarification I offer here, do I? Still found this worth
mentioning, and still think that the modeless directory should be the
alternative to the mode-dependent directories, and that I think it not
unwise to have a separation on name of utility, just in case one might
need it for any purpose, or just to prefer one utility over the other,
if deemed appropriate.
--
David Kastrup, Goethestr. 20, D-52064 Aachen Tel: +49-241-72419
Email: dak@pool.informatik.rwth-aachen.de Fax: +49-241-79502
================================================================================
From owner-twg-tds@shsu.edu Sun, 24 Sep 1995 16:16:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 24 Sep 1995 17:14:23 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509242114.AA09801@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: modeless fonts
For the font selection mechanism there is no particular reason even to
make a <utility> subdirectory tree under modeless: all fonts are
designed for that size, and that's that. In order to facilitate
Since gsftopk and ps2pk don't produce the same output, we must
distinguish them. Therefore, we need a <utility> directory.
On the other hand, in the typical setup one will want to search one
mode-dependent font pool, and *all* mode-independent ones. The
"modeless" subdirectory tree warrants that.
Yes, that's the argument. To search all the mode-independent fonts, you
would currently have to specify all the utility names:
$TEXMF/fonts/pk/{$MODE,gsftopk,ps2pk}//
[no, TDS doesn't allow/propose {foo,bar} syntax, but for purposes of
discussion...]
With modeless, the path spec simplifies and generalizes to:
$TEXMF/fonts/pk/{$MODE,modeless}//
But the counter-argument is that with the introduction of modeless/, PK
files are at different levels in the tree, we've used up one more (the
last) directory level, and things are generally non-orthogonal.
fonts/pk/CanonDX/metafont/dpi300/cmr10.pk
as opposed to fonts like
fonts/pk/CanonDX/fetamont/dpi300/cmr10.pk for a differently named
Hmm, that's certainly the most general solution. But, as you say,
specifying `metafont' for the common case seems a bit painful.
something like fonts/pk/CanonDX/dpi*/*.pk -- oops, I believe web2c
will *not* currently allow patterns like that, perhaps it should?).
No, it doesn't, and no, I don't want to implement complete filename
globbing :-). (And even if I did, the TDS could never promulgate a
solution that requires such a thing.)
================================================================================
From owner-twg-tds@shsu.edu Sun, 24 Sep 1995 22:32:37 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Sun, 24 Sep 1995 20:31:48 -0700
Message-ID: <199509250331.UAA01516@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: modeless fonts
> Date: Sun, 24 Sep 1995 17:14:23 -0400
> From: "K. Berry" <kb@cs.umb.edu>
> To: TWG-TDS@SHSU.edu
> Subject: Re: modeless fonts
>
> For the font selection mechanism there is no particular reason even to
> make a <utility> subdirectory tree under modeless: all fonts are
> designed for that size, and that's that. In order to facilitate
>
> Since gsftopk and ps2pk don't produce the same output, we must
> distinguish them. Therefore, we need a <utility> directory.
Why? They are used in the same way, aren't they?
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Mon, 25 Sep 1995 11:08:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 25 Sep 1995 17:04:21 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509251604.RAA15667@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: bin/, info/, man/, ...
References: <199509201450.AA14553@terminus.cs.umb.edu>
>
> The urgent question is, who's going to do the editing?
>
> If Norm no longer has time to do it, and no one else has SGML & time
> enough either, I will grab the distributed draft and start making the
> changes we've agreed as best as I can.
i am sorry for being "absent" for a week, sometimes i have to do work
for my employers.
Karl, since i am in some sense an authority for this group (as the
Technical Council liaison), I *do* ask that you take over from Norm
until he can get back on the job. I don't think there is any inherent
necessity to have the source in SGML, so editing the last TeX file
seems fine. If you can do this, i think we'd all be very happy.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 26 Sep 1995 09:45:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 26 Sep 1995 10:44:20 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509261444.AA27419@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: modeless fonts
Why? They are used in the same way, aren't they?
Yes. But the point is that a site might well have both installed.
I don't think it would be desirable for output from utility A to
overwrite output from utility B!
Although there is no quality difference (to my knowledge) bteween ps2pk
and gsftopk, both being derived from the Type 1 renderer IBm donated to
the X Consortium, one can easily imagine that changing, or someone else
writing/donating a different renderer.
================================================================================
From owner-twg-tds@shsu.edu Tue, 26 Sep 1995 15:24:13 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Tue, 26 Sep 1995 13:21:13 -0700
Message-ID: <199509262021.NAA04348@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: modeless fonts
On Tue Sep 26 09:35:51 1995, Karl Berry wrote:
> Why? They are used in the same way, aren't they?
>
> Yes. But the point is that a site might well have both installed.
> I don't think it would be desirable for output from utility A to
> overwrite output from utility B!
MakeTeXPK checks for that.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Wed, 27 Sep 1995 17:46:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 27 Sep 1995 18:44:14 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509272244.AA07693@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: modeless fonts
> I don't think it would be desirable for output from utility A to
> overwrite output from utility B
MakeTeXPK checks for that.
Certainly. But the point is that there's no reason to assume all
renderers are of equal quality. If we have only one `modeless' directory
for the output of gsftopk, ps2pk, and other-programs-as-yet-unwritten,
that's what we're assuming. I think it's preferable, and certainly more
cautious, to admit up front that there are multiple programs to make PK
files from PostScript fonts, and people might want to have the output
from all (more than one) of them around, instead of making the standard
be to lump them all together.
From owner-twg-tds@shsu.edu Sun, 01 Oct 1995 14:42:53 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sun, 1 Oct 1995 12:42:23 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510011942.MAA09593@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, TWG-TDS@SHSU.edu
Subject: Re: Feeling uncomfortable with designation `public'
Well,, the idea was that public means fonts which you don't have to
worry about passing on to others. You don't have to check with
DEK before giving his source away with an installation package.
You do with a B&H font.
Sure, it is a rather different matter from "foundry" names, and
it leaves anomalies in the case of Utopia, Charter etc., but even those
are not public. They are still licensed, it is just that the
license is free.
What do we do with N. Billawalla, and Tom Ridgeway. Are they
Foundries? Am I? or am I a sub branch of Silvio Levy and he is
a foundry. In that case Y. Haralambous is a sub branch of Silvio
Levy as well, but only sometimes. Because of the way I use
the Levy font, I have to package it along with Ibycus. What
foundry/supplier does that go under? The topology gets
horrendous. Giving a supplier name is an indication that
the supplier owns this, and probably need to deal with the
supplier about licensing. Giving the name "public" usually means
that the font has been put in the public domain. It makes a
difference.
%=======================================================================%
| 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, 01 Oct 1995 14:58:03 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sun, 1 Oct 1995 12:57:34 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510011957.MAA10497@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: texmf/tex//
It is maybe a bit too web2c-ish to point out that duplicate names are
often a sign of a badly maintained tree (They certainly are in my own case)
and that even when they have to exist, something on the order of
texmf.cnf provides a satisfactory way to get around the problem.
I have run into the problem several times, often caused by my own
inattention and and other times by the import of files from vastly
different worlds (arabtex vs. AMStex) for example. My own
suggestion would be that on a fixed archive like a CDROM we weed
out the ambiguities, and otherwise suggest strongly that package
developers need to think about this. I do not see the virtue in
going back to endlessly long paths which will inevitably fill up
the environment variable space of some machines.
================================================================================
From owner-twg-tds@shsu.edu Sun, 01 Oct 1995 16:04:35 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sun, 1 Oct 1995 13:00:02 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510012000.NAA10663@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Feeling uncomfortable with designation `public'
I hope we have a volunteer to unscramble all the complex parentage of
public domain fonts, in that case, and decide what is to be done with
them
================================================================================
From owner-twg-tds@shsu.edu Mon, 02 Oct 1995 07:38: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: <199510021237.NAA20025@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Feeling uncomfortable with designation `public'
To: TWG-TDS@SHSU.edu
Date: Mon, 2 Oct 1995 13:37:45 +0100 (MEZ)
Content-Type: text
Pierre wrote:
>
> I hope we have a volunteer to unscramble all the complex parentage of
> public domain fonts, in that case, and decide what is to be done with
> them
Did we decide to drop `public'? I don't remember.
If somebody doesn't want his (or her) fonts to be stored in public/,
he should mention that and then he gets an own <supplier> directory
with a name that he can choose himself. E.g., if Joerg or Yannis or
Pierre or whoever wants an own directory we'll give them one. ;-)
What's the problem with that?
Of course, we have to record that discussion in the document; or it
will come up and up again. (It's already on the floor for the 3rd
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 Mon, 02 Oct 1995 07:50: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: <199510021229.NAA16174@spock.iti.informatik.th-darmstadt.de>
Subject: Re: texmf/tex//
To: TWG-TDS@SHSU.edu
Date: Mon, 2 Oct 1995 13:29:31 +0100 (MEZ)
Content-Type: text
You wrote:
>
> It is maybe a bit too web2c-ish to point out that duplicate names are
> often a sign of a badly maintained tree
I don't think so. In the context of web2c; two cases, macros and fonts:
Macros:
-- If you create a distribution, do you have LaTeX2e _and_ a
rudimentary LaTeX 2.09 system on them? Let's assume, no.
Then you won't have duplicate names in the macro area.
(Well, not often. E.g., currently one needs two german.sty, an
older version for Plain TeX, and the current version for LaTeX... :(
-- If you administrate a TeX installation for a whole universities or
even a bunch of universities (e.g., many German universities share
one *installation* over AFS) -- do you have both LaTeX2e and LaTeX
2.09 installed? Here we cannot assume that that's not the case.
Too many legacy documents are around where such an
installation needs to provice LaTeX 2.09. -- And then we have the
name conflicts.
Fonts:
-- Font names were in conflict from the very start. A name like
cmr10.300pk tells nothing about the mode, and many medium-sized
installations have more than one output device with different
modes. (Even at home I use three different modedefs for the
three printers I have.)
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, 02 Oct 1995 12:19:01 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 2 Oct 1995 10:18:35 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510021718.KAA27835@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Feeling uncomfortable with designation `public'
My point is that I DON'T want a personal supplier directory, and
most of the contributors of fonts into the public domain
probably don't care either. I saw one message ( I think from
a battle-weary Karl Berry) that suggested we were resigned
to dropping "public". I still think it does better as
a general location for public domain fonts (and free
fonts that don't otherwise have a home) than a whole proliferation
of rather pseudish supplier names.
As for duplicate names in the tree (in response to another message)
the case of cmr??.*pk is a well-known instance of the requirement
to allow duplicate names, and there is no getting around it except
by permitting loooooong filenames. That doesn't in itself supply
an argument in favor of allowing multiple instances of "symbol.mf"
The case of LaTeX2e and LaTeX209 is not a general instance because
it involves only an intermediate stage in the replacement of one
version of LaTeX by another. The ultimate intent is that LaTeX209
will fade away like TeX78, isn't it? And there seem to be adequate
techniques for getting around the duplicate name problem in that
one anomalous instance. At least it ought to be anomalous.
I have yet to be convinced that it is a good idea to fill a TDS
compliant *archive* with files having duplicate names. If individual
installations wish to encumber themselves with that problem that
is another matter. A more elaborate texmf.cnf can handle it if
it has to, and I suppose there must be techniques on other systems.
%=======================================================================%
| 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, 02 Oct 1995 13:03:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 2 Oct 1995 14:01:34 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510021801.AA28710@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Feeling uncomfortable with designation `public'
Did we decide to drop `public'? I don't remember.
We didn't decide.
with a name that he can choose himself. E.g., if Joerg or Yannis or
Pierre or whoever wants an own directory we'll give them one. ;-)
I agree. Joerg, I assume you want one. `knappen' for the directory name,
or something else? And which fonts will go there, TS and DC and sauter?
As Pierre suggests, I don't see any problem with keeping public/ as a
catchall name for fonts. It's a nonstarter to try to assign supplier
names to every existing font from my point of view, anyway.
Of course, we have to record that discussion in the document; or it
Right.
================================================================================
From owner-twg-tds@shsu.edu Tue, 03 Oct 1995 13:04:46 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510031802.TAA20153@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Feeling uncomfortable with designation `public'
To: TWG-TDS@SHSU.edu
Date: Tue, 3 Oct 1995 19:02:57 +0100 (MEZ)
Content-Type: text
Pierre wrote:
>
> My point is that I DON'T want a personal supplier directory, and
> most of the contributors of fonts into the public domain
> probably don't care either. I saw one message ( I think from
> a battle-weary Karl Berry) that suggested we were resigned
> to dropping "public". I still think it does better as
> a general location for public domain fonts (and free
> fonts that don't otherwise have a home) than a whole proliferation
> of rather pseudish supplier names.
OK, obviously I don't understand your viewpoint. Let's come back to
the current situation: Already, in public/ are fonts that are _not_
public domain, but are freely distributable (e.g., public/pandora/).
Other freely distributable fonts are placed outside of public/ due to
the request of their supplier (e.g., ams/) or because that supplier
has also non-free fonts (e.g., adobe/).
So -- I don't understand your aim. Do you want to place in public/
*only* PD fonts? Two points come up: (1) Where is Pandora placed then?
(2) Joerg might simply put a copyright (e.g., the GPL) on the DC
fonts. Then we must move them somewhere else, as they are not PD any
more...
Or -- is your viewpoint the same as mine?
o public/ is the tree for all freely distributable fonts where
-- the supplier didn't request an own directory, and
-- the supplier didn't make _so_ many fonts that we want to
identify him or her as their source.
o Suppliers or authors who fall under these two exceptions get an
own tree.
As explained above, I think that's the situation we have right now
already; it's not a new proposal.
I would like to see a bit pragmatism here and fix the description in
a style like above (feel like carrying owls to Athen when I, as a
German, preach pragmatism to Americans ;-).
----------------------------------------
On the other topic, of duplicate file names:
> I have yet to be convinced that it is a good idea to fill a TDS
> compliant *archive* with files having duplicate names.
If you substitute `archive' with `distribution' or `installation', I
fully agree with you.
I don't think it's a good thing to create a TDS *archive* in the
first place. TDS is for distributions and installations, not for
archives. _Archives_ have by definition old files, and one cannot
circumvent the problem of duplicate file names there.
> If individual
> installations wish to encumber themselves with that problem that
> is another matter. A more elaborate texmf.cnf can handle it if
> it has to, and I suppose there must be techniques on other systems.
Yes, configuration files or environment variables.
I cannot see our disagreement in this point: I agree with you that it
is not a situation one shall strive for. But I do also see that this
situation will happen, and that folks will come to the TDS group and
will ask for resolvement of that question. (`will come'? They came
already... :-)
So we should note in the document that such a situation may happen,
though one should try to avoid it. And that the situation -- if they
happen -- may be handled by appropriate methods, as you mentioned
already.
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, 03 Oct 1995 15:38:10 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 3 Oct 1995 13:38:04 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510032038.NAA28498@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Feeling uncomfortable with designation `public'
Joachim's "pragmatic" version of what public/ is for is
exactly what I hope we will retain.
That is the way public/ has been used in the past, and I
don't see any need to change it.
I take the point about the necessity of old files in an
archive, and agree fully. I should have said distribution
or installation.
%=======================================================================%
| 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, 04 Oct 1995 17:01:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 4 Oct 1995 18:01:10 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510042201.AA06528@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: plain/base?
I noticed the draft says:
The \path|plain| directory is for files which are
useful with the Plain {\TeX} format and others compatible with Plain:
\path|testfont.tex|,
\path|manmac.tex|,
\path|webmac.tex|, etc., as well as \path|plain.tex|
itself and the canonical example \path|story.tex|.
We don't really mean texmf/tex/plain/plain.tex, do we?
Isn't it
texmf/tex/plain/base/plain.tex
/misc/{testfont.tex,manmac.tex,...}
So we can have
/tugboat/whatever
/texdraw/whatever
etc.
as usual?
================================================================================
From owner-twg-tds@shsu.edu Wed, 04 Oct 1995 17:02:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 4 Oct 1995 18:01:10 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510042201.AA06536@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: tds 0.99
OK, I've hacked up some text in response to Joachim's open problems list
and subsequent discussion. I don't pretend to have addressed everything;
I hope to reread all the mail since the draft release soon.
Here's a changelog and the diffs. You can get the whole thing from
ftp.cs.umb.edu:/private/tex/tds. I guess it should stay in private/ for now.
One meta-question -- I think having this available in info (and html?)
formats in the end would be very useful. I know I'd find it useful. But
we can do a better job typesetting in latex than texinfo. I don't
suppose anyone can wave a magic wand to transform the latex input into
texinfo? I looked at Norm's SGML input, etc., but wasn't enthused at the
prospect of hacking my own SGML pseudo-translator :-).
Also, I think it'd be nice if the latex input was actually ``good''
latex input -- used references correctly, etc. Sigh. But for now, I left
that alone, trying to keep the diffs minimal.
BTW, if any of you relative newcomers (hi Paul, Thomas, Christian, ...)
reading this would like to be included in the last section (i.e., be
``on the committee''), just send me the info. (Presuming there's no
objections from anyone.)
Wed Oct 4 15:08:01 1995 Karl Berry <karl@cs.umb.edu>
* tds.tex: Don't hardwire version number in more than place.
- Use TUG instead of O'Reilly for postal mail.
- texmf/tex// does not suffice in general.
- Incorporate `subdirectory searching syntax' section into main
subdir searching section, and `Expeding the Process' into
`Adoption of the TDS'.
- Move bin/ out of the main text.
- Reserve `local' at every level.
- Top-level directories should be a chapter, and
implementation-specific files need more discussion.
- Make macros, fonts, etc. sections under the top-level
directories chapter.
*** tds.tex 1995/10/04 18:59:04 1.1
--- tds.tex 1995/10/04 21:25:43
***************
*** 12,16 ****
\formatterfile{bookinfo.tex}
% begin bookinfo
! \tdsVersion{0.98}\title{{A Directory Structure for {\TeX} Files}\\Version 0.98}
\author{TUG Working Group on a {\TeX} Directory Structure (TWG-TDS)}
\begin{document}
--- 12,16 ----
\formatterfile{bookinfo.tex}
% begin bookinfo
! \tdsVersion{0.99}\title{{A Directory Structure for {\TeX} Files}\\Version \the\tdsVersion}
\author{TUG Working Group on a {\TeX} Directory Structure (TWG-TDS)}
\begin{document}
***************
*** 19,23 ****
This specification may be referred to as the ``\abbr{twg-tds
! 0.98}'' or ``\abbr{twg-tds}'' for short, or just
``\abbr{tds}'' when the context makes it clear which {\TeX}
directory structure is meant.
--- 19,23 ----
This specification may be referred to as the ``\abbr{twg-tds
! \the\tdsVersion}'' or ``\abbr{twg-tds}'' for short, or just
``\abbr{tds}'' when the context makes it clear which {\TeX}
directory structure is meant.
***************
*** 35,46 ****
Please direct all questions, suggestions, or bug reports,
! to \literal{twg-tds@shsu.edu} or by mail to Norman
! Walsh, O'Reilly \& Associates, Inc., 90 Sherman Street,
! Cambridge, MA 02140, USA.
!
! This document is available in {\LaTeX}, \path|DVI|, {\PS},
! {\TeXinfo}, \abbr{html}, and other formats from
! \path|ftp://jasper.ora.com/pub/twg-tds/|*
and from \path|/tex-archive/tds| on any \abbr{ctan} host.
--- 35,42 ----
Please direct all questions, suggestions, or bug reports,
! by email to \literal{twg-tds@@shsu.edu} or by postal mail to TUG, xx.
! This document is available from
! \path|ftp://ftp.cs.umb.edu/pub/tex/tds/*|
and from \path|/tex-archive/tds| on any \abbr{ctan} host.
***************
*** 75,79 ****
This document is intended both for the {\TeX} system administrator at a
site and for people preparing {\TeX} distributions---everything from a
! complete runnable system to a single macro or style file. It will also
help {\TeX} users find their way around systems organized this way.
\subsection{The Role of the \abbr{TDS}}
--- 71,75 ----
This document is intended both for the {\TeX} system administrator at a
site and for people preparing {\TeX} distributions---everything from a
! complete runnable system to a single macro or style file. It may also
help {\TeX} users find their way around systems organized this way.
\subsection{The Role of the \abbr{TDS}}
***************
*** 249,260 ****
up to the installer. On \abbr{pc} networks, for example, this
could map to a logical drive specification such as \path|T:|.
! We recommend naming the directory of the system-wide {\TeX}
installation \path|texmf|, where possible.
! Similarly, the location of
! this directory within the file system is site-dependent. On
! many systems, this may be at the root of the file system; on
! Unix systems, it would traditionally be located in
! \path|/usr/local| or \path|/usr/local/lib|.
The name \path|texmf| was chosen for several reasons:
--- 245,255 ----
up to the installer. On \abbr{pc} networks, for example, this
could map to a logical drive specification such as \path|T:|.
! We recommend naming the root of the system-wide {\TeX}
installation \path|texmf|, where possible.
! Similarly, the location of this directory within the file system is
! site-dependent. On many systems, this will be at the root of the file
! system; on Unix systems, \path|/usr/local|, \path|/usr/local/lib|, or
! \path|/usr/local/share| are perhaps the common choices.
The name \path|texmf| was chosen for several reasons:
***************
*** 263,279 ****
itself) and it is
descriptive of a generic installation rather than a particular
! implementation (such as \path|emtex|).
! The \path|texmf| root is not intended to be placed under an
! implementation-dependent directory. For example, \path|emtex/texmf|
! is wrong.
! \subsection{Top Level Directories}
The top level directories in the \path|texmf| directory identify
the major components of a {\TeX} system. A site may omit any unneeded
directories.
! Although the \abbr{TDS} is designed to be implementation-independent, the
! \abbr{TWG} recognizes that some installers may wish to place other files in
! the \abbr{TDS}. For example, {\TeX} administrators may wish to place all
{\TeX}-related files (including binaries, manual pages, pool files, and
formats) in the \path|texmf| tree. This greatly simplifies
--- 258,295 ----
itself) and it is
descriptive of a generic installation rather than a particular
! implementation.
!
!
! \subsection{Local Additions}
! \label{sec:local}
!
! We recognize two common methods for local additions to a distributed
! \path|texmf| tree. Both have their place; in fact, a single site may
! find it useful to employ both.
!
! \begin{itemize}
!
! \item A completely separate tree, following a \abbr{TDS} structure
! itself; for example, \path|/usr/local/oratex| and
! \path|/usr/local/texmf|.
!
! \item A \path|local| directory at any appropriate level. For example,
! the \replaceable{format}, \replaceable{package}, and
! \replaceable{supplier} directories mentioned in the following. The
! \abbr{TDS} therefore reserves the directory name \path|local| for
! this purpose.
!
! \end{itemize}
!
! \section{Top Level Directories}
The top level directories in the \path|texmf| directory identify
the major components of a {\TeX} system. A site may omit any unneeded
directories.
! Although the \abbr{TDS} by its nature can specify precise locations only
! for implementation-independent files,
! we recognize that installers may well wish to place other files in
! the \abbr{TDS} tree. For example, {\TeX} administrators may wish to place all
{\TeX}-related files (including binaries, manual pages, pool files, and
formats) in the \path|texmf| tree. This greatly simplifies
***************
*** 318,323 ****
\item[\path|source|]
for sources. This includes both traditional program
! sources (for example, \application{Web2C} sources go in
! \path|texmf/source/web2c|) and {\LaTeX} \path|dtx|
sources (\path|texmf/source/latex|).
The \path|dtx| files used for {\LaTeX} distribution contain
--- 334,339 ----
\item[\path|source|]
for sources. This includes both traditional program
! sources (for example, \application{Web2c} sources go in
! \path|texmf/source/Web2c|) and {\LaTeX} \path|dtx|
sources (\path|texmf/source/latex|).
The \path|dtx| files used for {\LaTeX} distribution contain
***************
*** 325,350 ****
are kept in the \path|source| tree.
- \item[\path|bin|/\replaceable{system}]
- for binaries. The \replaceable{system} directories
- allow multiple implementations to share the common directory
- structure. For example, the binaries for a {\TeX} system
- on a Sun workstation
- might be installed in \path|/texmf/bin/spsun413| (the name
- \path|spsun413| is one possible ({\abbr{ISO}-9660} compliant)
- abbreviation for \abbr{sparc} SunOS 4.1.3).
- Some {\TeX} administrators may wish to put executables outside of
- \path|texmf| altogether.
-
\end{description}
! The standard \path|texmf| tree provides no explicit location for
! locally-maintained files (e.g. letterheads), since that would require
! duplicating the entire tree. Consequently, sites are encouraged to
! maintain a separate tree for local styles and to use both trees in
! search paths. For example, \path|/usr/local/oratex| and
! \path|/usr/local/texmf|.
\sourcefile{macros.sgm}
\formatterfile{macros.tex}
! \section{Macros}
The common current practice of lumping files into a small number of
directories has the disadvantage of making it difficult to determine
--- 341,371 ----
are kept in the \path|source| tree.
\end{description}
!
! \subsection{Implementation-specific files}
! \label{sec:impl-specific-files}
!
! Many different {\TeX} implementations and distributions exist
! (\application{em\TeX}, \application{Web2c}, etc.). The \abbr{TDS} is an
! attempt to factor out the input files in a {\TeX} system that can be
! shared among implementations. Therefore, the tree rooted at \path|texmf|
! is not intended to be a subdirectory of a particular implementation's
! distribution. Rather, the \abbr{TDS} provides for
! implementation-specific files under a top-level directory named for the
! implementation, as mentioned above.
!
! The main exceptions are pool files and ``memory dump'' files
! (\path|.fmt|, \path|.base|, \path|.mem|). These must be
! stored under \path|texmf/\replaceable{implementation}|, with the precise
! location left to the implementation maintainer or distributor's
! discretion, since they simply cannot be shared, and the \abbr{TDS}
! cannot presume to know the best structure for any particular implementation.
! We do, however, list the structures we know of, in
! \ref{sec:example-impl-trees}.
!
\sourcefile{macros.sgm}
\formatterfile{macros.tex}
! \subsection{Macros}
The common current practice of lumping files into a small number of
directories has the disadvantage of making it difficult to determine
***************
*** 368,372 ****
! Although some of these formats can also
be used as macro packages, the \abbr{TDS} nevertheless stores them as formats.
By adjusting the {\TeX} inputs search
--- 389,393 ----
! Although some formats (Texinfo, Eplain) can also
be used as macro packages, the \abbr{TDS} nevertheless stores them as formats.
By adjusting the {\TeX} inputs search
***************
*** 384,387 ****
--- 405,411 ----
\item
+ \path|local| is reserved for local additions. See \xref{sec:local}.
+
+ \item
\path|generic| is
reserved for input files that are useful across a wide range of
***************
*** 407,419 ****
search at least the \replaceable{format} directory, and then the
\path|generic| directory (in that order).
! Other directories may be searched as well.
For example, the \path|amstex|,
\path|plain|, and \path|generic|
directories should be searched when using {\AMSTeX},
! because {\AMSTeX} is compatible with Plain.
! This does not mean \emphasis{only} those directories must be searched:
! a recursive search beginning at \path|texmf/tex|
! is a correct path for {\TeX} inputs in a \abbr{TDS}
! tree.
\item[\replaceable{package}]
--- 431,445 ----
search at least the \replaceable{format} directory, and then the
\path|generic| directory (in that order).
! Other directories may need to be searched as well, depending on the format.
For example, the \path|amstex|,
\path|plain|, and \path|generic|
directories should be searched when using {\AMSTeX},
! because {\AMSTeX} is compatible with Plain.
! No single format-independent path specification, such as
! a recursive search beginning at \path|texmf/tex| specifying no
! other directories, may suffice in general, since
! different formats may reasonably have an input file with the same name.
! Therefore we encourage implementors to provide format-dependent paths,
! by use of, for example, wrapper scripts or configuration files.
\item[\replaceable{package}]
***************
*** 436,445 ****
\item
- \path|misc| is reserved for
- packages that consist of a single file. It seems pointless to
- nest such a package/file within a directory of its own. It may
- also make subdirectory searching slower.
-
- \item
\path|config| is reserved for
configuration files. Configuration files are used by several
--- 462,465 ----
***************
*** 448,455 ****
\item
\path|hyphen| is reserved for
! hyphenation patterns. These are typically used only by {\iniTeX}.
This directory need exist only
under the \literal{generic} format directory.
\end{itemize}
In the case where a format consists of only a single
--- 468,484 ----
\item
\path|hyphen| is reserved for
! hyphenation patterns, e.g., \path|hyphen.tex|. These are typically used only by {\iniTeX}.
This directory need exist only
under the \literal{generic} format directory.
+ \item
+ \path|local| is reserved for local additions. See \xref{sec:local}.
+
+ \item
+ \path|misc| is reserved for
+ packages that consist of a single file. It seems pointless to
+ nest such a package/file within a directory of its own. It may
+ also make subdirectory searching slower.
+
\end{itemize}
In the case where a format consists of only a single
***************
*** 462,466 ****
\end{description}\sourcefile{fonts.sgm}
\formatterfile{fonts.tex}
! \section{Fonts}
As with macros, fonts need to be stored in a hierarchical structure in order to
make maintenance feasible.
--- 491,495 ----
\end{description}\sourcefile{fonts.sgm}
\formatterfile{fonts.tex}
! \subsection{Fonts}
As with macros, fonts need to be stored in a hierarchical structure in order to
make maintenance feasible.
***************
*** 496,500 ****
\path|adobe|,
\path|monotype|, and \path|ams| are
! examples of \replaceable{supplier}.
--- 525,531 ----
\path|adobe|,
\path|monotype|, and \path|ams| are
! examples of \replaceable{supplier}.
! \path|local| is reserved for local additions. See \xref{sec:local}.
!
***************
*** 619,623 ****
\sourcefile{metafont.sgm}
\formatterfile{metafont.tex}
! \section{Non-font {\protect\MF} Files}
Most {\protect\MF} input files are font programs or parts of font programs
(see the previous section); however a
--- 650,654 ----
\sourcefile{metafont.sgm}
\formatterfile{metafont.tex}
! \subsection{Non-font {\protect\MF} Files}
Most {\protect\MF} input files are font programs or parts of font programs
(see the previous section); however a
***************
*** 649,653 ****
\sourcefile{metapost.sgm}
\formatterfile{metapost.tex}
! \section{{\MP}}
{\MP} is a picture-drawing language developed by John Hobby that is
very much like Knuth's {\protect\MF}, except that it outputs {\PS} instead
--- 680,684 ----
\sourcefile{metapost.sgm}
\formatterfile{metapost.tex}
! \subsection{{\MP}}
{\MP} is a picture-drawing language developed by John Hobby that is
very much like Knuth's {\protect\MF}, except that it outputs {\PS} instead
***************
*** 687,691 ****
\end{itemize}\sourcefile{bibtex.sgm}
\formatterfile{bibtex.tex}
! \section{{\protect\BibTeX}}
{\protect\BibTeX} databases and style files are commonly scattered in with other
formats, making them hard to find and sometimes making {\protect\BibTeX} hard to
--- 718,722 ----
\end{itemize}\sourcefile{bibtex.sgm}
\formatterfile{bibtex.tex}
! \subsection{{\protect\BibTeX}}
{\protect\BibTeX} databases and style files are commonly scattered in with other
formats, making them hard to find and sometimes making {\protect\BibTeX} hard to
***************
*** 699,703 ****
\end{description}\sourcefile{doc.sgm}
\formatterfile{doc.tex}
! \section{Documentation}
Most packages come with some form of documentation. To make
it easier for users to find this documentation, the \abbr{TDS} specifies that
--- 730,734 ----
\end{description}\sourcefile{doc.sgm}
\formatterfile{doc.tex}
! \subsection{Documentation}
Most packages come with some form of documentation. To make
it easier for users to find this documentation, the \abbr{TDS} specifies that
***************
*** 850,854 ****
. bib/ {\protect\BibTeX} databases of common interest
. bst/ {\protect\BibTeX} style files
- bin/*/ binaries, by system type (optional)
doc/ see \xref{Section~8, ``Documentation''}
fonts/ font-related files
--- 881,884 ----
***************
*** 868,872 ****
. support/ support files for {\MP}-related utilities
<program>/ {\TeX} applications, by name (e.g., \path|makeindx| and \path|dvips|)
! source/ program source code by name (e.g., \path|web2c|, \path|latex|)
tex/ {\TeX} input files
. <\replaceable{format}>/ name of a format (e.g., \path|plain|)
--- 898,902 ----
. support/ support files for {\MP}-related utilities
<program>/ {\TeX} applications, by name (e.g., \path|makeindx| and \path|dvips|)
! source/ program source code by name (e.g., \path|Web2c|, \path|latex|)
tex/ {\TeX} input files
. <\replaceable{format}>/ name of a format (e.g., \path|plain|)
***************
*** 874,881 ****
. . config/ configuration files for format (e.g., \path|texsys.cfg|).
. . misc/ single-file packages
. . <package>/ name of a package (e.g., \path|graphics|)
. generic/ format-independent packages
! . . hyphen/ hyphenation patterns
! . . misc/ single-file format-independent packages (e.g. \path|texnames.sty|).
. . <package>/ name of a package (e.g., \path|babel|)
\end{tdsSummary}\sourcefile{impissue.sgm}
--- 904,912 ----
. . config/ configuration files for format (e.g., \path|texsys.cfg|).
. . misc/ single-file packages
+ . . local/ local additions to \replaceable{format}
. . <package>/ name of a package (e.g., \path|graphics|)
. generic/ format-independent packages
! . . hyphen/ hyphenation patterns
! . . misc/ single-file format-independent packages (e.g., \path|texnames.sty|).
. . <package>/ name of a package (e.g., \path|babel|)
\end{tdsSummary}\sourcefile{impissue.sgm}
***************
*** 924,929 ****
Eventually, most {\TeX} sites will have adopted the new structure,
and most common packages will be readily available in \abbr{TDS}-compliant form.
! \subsection{Expediting the Process}
! We believe that the process described above will occur fairly quickly.
The \abbr{TDS} committee spans a wide range of interests in the {\TeX} community.
Consequently, we believe that most of the key issues involved
--- 955,960 ----
Eventually, most {\TeX} sites will have adopted the new structure,
and most common packages will be readily available in \abbr{TDS}-compliant form.
!
! We believe that this process will occur fairly quickly.
The \abbr{TDS} committee spans a wide range of interests in the {\TeX} community.
Consequently, we believe that most of the key issues involved
***************
*** 951,955 ****
This feature is already supported by many implementations of {\TeX},
including, but not limited to, \application{em{\TeX}} (and its
! drivers), \application{PubliC {\TeX}}, \application{Web2C},
\application{Y\&Y{\TeX}}, \application{dvips(k)},
\application{xdvi(k)}, and \abbr{DECUS} {\TeX} for \abbr{VMS}.
--- 982,986 ----
This feature is already supported by many implementations of {\TeX},
including, but not limited to, \application{em{\TeX}} (and its
! drivers), \application{PubliC {\TeX}}, \application{Web2c},
\application{Y\&Y{\TeX}}, \application{dvips(k)},
\application{xdvi(k)}, and \abbr{DECUS} {\TeX} for \abbr{VMS}.
***************
*** 974,978 ****
searching is not required, and performance is thus independent of the
number of subdirectories present on the system.
! \subsection{Subdirectory Searching Syntax}
Different implementations have elected to use different syntaxes for
specifying subdirectory searching. In the interest of typographic clarity,
--- 1005,1009 ----
searching is not required, and performance is thus independent of the
number of subdirectories present on the system.
!
Different implementations have elected to use different syntaxes for
specifying subdirectory searching. In the interest of typographic clarity,
***************
*** 1010,1013 ****
--- 1041,1086 ----
farm'' (at 1\,KB per link) may be negligible compared to
the space required for all the files.
+
+ \subsection{Example Implementation-Specific Trees}
+ \label{sec:example-impl-trees}
+
+ As discussed in \ref{sec:impl-specific-files}, the \abbr{TDS} cannot
+ specify a precise location for implementation-specific files. Here we
+ provide the default locations for the implementations we know of. Please
+ contact us with any additions or corrections. These paths are not
+ definitive, may not match anything at your site, and may change as of
+ the next release; this is simply for informative purposes.
+
+ \begin{itemize}
+ \item Web2c 7.0: all files (\path|.pool|, \path|.fmt|,
+ \path|.base|, \path|.mem|) are stored directly in \path|texmf/web2c|.
+ The configuration file \path|texmf.cnf| and the
+ \path|MakeTeX\ldots| scripts are also stored there.
+ \end{itemize}
+
+
+ \subsection{Unspecified Pieces}
+
+ We are unable to address several components necessary to a functioning
+ {\TeX} system.
+
+ \begin{itemize}
+
+ \item The location of executable programs: this is too site-dependent
+ even to recommend a location, let alone require one. Executables may
+ well be placed outside the \path|texmf| tree altogether, in a
+ platform-dependent directory within \path|texmf|, or elsewhere.
+
+ \item Upgrading packages as new releases are made: we could find no way
+ of introducing version specifiers into \path|texmf| that would not do more
+ harm than good, or that would be practical for even a plurality of
+ installations.
+
+ \item Implementation-specific files. See \ref{sec:impl-specific-files}
+ and \ref{sec:example-impl-trees}.
+
+ \end{itemize}
+
+
\sourcefile{better.sgm}
\formatterfile{better.tex}
***************
*** 1068,1072 ****
In fact, many sites already use this alternative arrangement. (It is the
! arrangement suggested by the \application{Web2C} distribution.)
This arrangement greatly improves the maintainability of the font tree,
--- 1141,1145 ----
In fact, many sites already use this alternative arrangement. (It is the
! arrangement suggested by the \application{Web2c} distribution.)
This arrangement greatly improves the maintainability of the font tree,
***************
*** 1118,1135 ****
Finger \path|ctan@ftp.shsu.edu| for a complete list of \abbr{ctan} sites.
! \citetitle{Filenames for {\TeX} fonts} is availble from
\abbr{ctan}:\path|documentation/fontname|.
! A complete set of {\protect\MF} modes is available from
\abbr{ctan}:\path|fonts/modes/modes.mf|.
This file includes eight-character-or-fewer recommended mode names.
! \citetitle{Components of {\TeX}} by Joachim Schrod is
! available from \abbr{ctan}:\path|documentation/components-of-TeX|.
! A sample tree is available from \abbr{ctan}:\path|tds|.
- \path|ftp.math.utah.edu:pub/tex/bib| has a huge {\protect\BibTeX} collection,
- both databases and styles.
\sourcefile{members.sgm}
\formatterfile{members.tex}
--- 1191,1209 ----
Finger \path|ctan@ftp.shsu.edu| for a complete list of \abbr{ctan} sites.
! \citetitle{Filenames for {\TeX} fonts}, from
\abbr{ctan}:\path|documentation/fontname|.
! A complete set of {\protect\MF} modes, from
\abbr{ctan}:\path|fonts/modes/modes.mf|.
This file includes eight-character-or-fewer recommended mode names.
! \citetitle{Components of {\TeX}} by Joachim Schrod,
! from \abbr{ctan}:\path|documentation/components-of-TeX|.
!
! A sample tree, from \abbr{ctan}:\path|tds|.
! A collection of {\protect\BibTeX} databases and styles, from
! \path|ftp.math.utah.edu:pub/tex/bib|.
\sourcefile{members.sgm}
\formatterfile{members.tex}
***************
*** 1146,1150 ****
charter member and Board member, {\TeX} Users Group.
! Berry, Karl (\literal{kb@cs.umb.edu}). Maintainer of \application{Web2C},
Eplain, \path|modes.mf|, et al.
--- 1220,1224 ----
charter member and Board member, {\TeX} Users Group.
! Berry, Karl (\literal{kb@cs.umb.edu}). Maintainer of \application{Web2c},
Eplain, \path|modes.mf|, et al.
***************
*** 1202,1206 ****
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} in early 1995.
Walsh, Norman (\literal{norm@ora.com}). Production tools specialist,
--- 1276,1280 ----
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} in early 1995.
Walsh, Norman (\literal{norm@ora.com}). Production tools specialist,
***************
*** 1208,1210 ****
90 Sherman Street, Cambridge, MA 02140. Author of \emphasis{Making {\TeX}
Work}. (\abbr{TDS} Committee Chair.)
! \end{document}
\ No newline at end of file
--- 1282,1284 ----
90 Sherman Street, Cambridge, MA 02140. Author of \emphasis{Making {\TeX}
Work}. (\abbr{TDS} Committee Chair.)
! \end{document}
================================================================================
From owner-twg-tds@shsu.edu Wed, 04 Oct 1995 17:10: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: <199510042209.XAA18178@spice.iti.informatik.th-darmstadt.de>
Subject: Re: plain/base?
To: TWG-TDS@SHSU.edu
Date: Wed, 4 Oct 1995 23:09:34 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> We don't really mean texmf/tex/plain/plain.tex, do we?
> Isn't it
> texmf/tex/plain/base/plain.tex
IMO yes.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 05 Oct 1995 08:36:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 5 Oct 1995 14:27:32 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510051327.OAA28547@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: tds 0.99
References: <199510042201.AA06536@terminus.cs.umb.edu>
> One meta-question -- I think having this available in info (and html?)
> formats in the end would be very useful. I know I'd find it useful. But
> we can do a better job typesetting in latex than texinfo. I don't
> suppose anyone can wave a magic wand to transform the latex input into
> texinfo? I looked at Norm's SGML input, etc., but wasn't enthused at the
> prospect of hacking my own SGML pseudo-translator :-).
hohohoho. i'd say try going to html with latex2html, but expect to
clean it up by hand. i don't mind doing this when the thing is
finished. i'll even volunteer to do the nice PDF version :-}
> Also, I think it'd be nice if the latex input was actually ``good''
> latex input -- used references correctly, etc. Sigh. But for now, I left
> that alone, trying to keep the diffs minimal.
any of us can do that later, i'd say
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 05 Oct 1995 13:46:55 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Thu, 5 Oct 1995 11:46:51 -0700 (PDT)
Message-ID: <199510051846.LAA04503@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.99
In his latest diffs, Karl writes:
! No single format-independent path specification, such as
! a recursive search beginning at \path|texmf/tex| specifying no
! other directories, may suffice in general, since
! different formats may reasonably have an input file with the same name.
! Therefore we encourage implementors to provide format-dependent paths,
! by use of, for example, wrapper scripts or configuration files.
Ugh. I'd still prefer some language encouraging people to gravitate towards
saying \input latex/foobar, etc.
But also, I think that the issue of when duplicate file names within
texmf/tex are allowed should be explicitly addressed. Current practice seems
to be:
1. names of TeX input files must be unique within any of the first-level
subdirectories of texmf/tex, and
2. names of image input files must be unique within texmf/tex.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Fri, 06 Oct 1995 05:11:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 6 Oct 1995 11:09:44 +0100
Message-ID: <9510061009.AA02294@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.99
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
Paul writes:
> But also, I think that the issue of when duplicate file names within
> texmf/tex are allowed should be explicitly addressed. Current practice seems
> to be:
> 1. names of TeX input files must be unique within any of the first-level
> subdirectories of texmf/tex, and
> 2. names of image input files must be unique within texmf/tex.
Don't forget that there is another -- sometimes even more irritating -- limitation:
3. names of METAFONT font files must be unique withing texmf/fonts.
This currently prevents me from installing some non-standard cm variants
that come with modified versions of punct.mf, romanl.mf, romanu.mf.
(This real world example is for the cmttss{c,lc,bc} fonts by Art Ogawa.)
Installing them below texmf/fonts/source/public/cmttss would affect the
standard cm fonts if cmttss/*.mf is found before cm/*.mf during searching.
I don't have a solution to offer for this, but it might be a good idea
to point out this restriction on the uniqueness of file names.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Fri, 06 Oct 1995 05:31:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 6 Oct 1995 11:29:48 +0100
Message-ID: <9510061029.AA04311@macbeth.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Re: tds 0.99
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
Hi Karl et al.
1. Some technical points:
- if you are now using the LaTeX document for future changes, you might
as well do some minor cleanups of unneccessary stuff introduced by
Norm's converter. In particular, I think you can remove all the
\protect's in front of \MF and \BibTeX since Joachim's macros from
tdsguide.cls take care of protecting them.
- concerning .info and .html versions: What about trying to convert
the LaTeX document to Texinfo with a simple sed-script or something
like that. I guess that would be much easier than trying to go the
way via SGML.
2. Concerning the contents:
I don't quite remember the outcome of our previous discussion about
this, but didn't we decide to move /tex/mft to the top-level.
I'm just asking this because I came across mft when trying to fix
the man pages in texk-6.94. (More on that in a separate message.)
If we do move the mft directory, now would be a good time to
introduce another search path variable for MFTINPUTS in kpathsea
before web2c-7.0/kpathsea-3.0 goes public. (If we move mft but
continue to use TEXINPUTS as the search path, one would have to
add texmf/mft to TEXINPUTS which really seems odd, especially
since TeX itself would never need to look into texmf/mft.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Fri, 06 Oct 1995 05:41:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 6 Oct 1995 11:40:40 +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: <951006114040.2180108a@vms.rhbnc.ac.uk>
Subject: Re: tds 0.99
>> Ugh. I'd still prefer some language encouraging people to gravitate towards
>> saying \input latex/foobar, etc.
Unles and until the world (or at least the TeX world) agrees on an
operating-system independent means of specifying a file unambiguously
(e.g. by adopting URLs), such a proposal is doomed to failure: a TeX
document should process identically on all TeX installations, but the
use of O/S-specific file specifications will prevent the document
from functioning at all if processed under a different operating system.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Fri, 06 Oct 1995 06:00:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 6 Oct 1995 11:56:57 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510061056.LAA02314@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: tds 0.99
References: <199510051846.LAA04503@tashkent.berkeley.edu>
> Ugh. I'd still prefer some language encouraging people to gravitate towards
> saying \input latex/foobar, etc.
i dont agree, but i think Phil is
being unduly negative. other people (much bigger than us) in the
industry want standards for directory specification, independent of
implemenation. it would not be hard for VMS TeX to translate foo/bar
to [.foo]bar or whatever. If you look at Acrobat PDFmark spec, Adobe
have got things like this in there, viz OS-independent filename
specs. face it, Phil, the world is moving inexorably towards foo/bar
or foo\bar or the like, and DEC are not going to stand out for that
long
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 06 Oct 1995 11:33: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: <199510061633.RAA20029@spice.iti.informatik.th-darmstadt.de>
Subject: Re: tds 0.99
To: TWG-TDS@SHSU.edu
Date: Fri, 6 Oct 1995 17:33:28 +0100 (MEZ)
Content-Type: text
sebastian wrote:
>
> it would not be hard for VMS TeX to translate foo/bar
> to [.foo]bar or whatever.
I thought VMS supports foo/bar on the program level?! (Not on the
command level, though.) As it's supposed to be POSIX.1 conformant, it
must do so.
Or did I misunderstand DEC announcements?
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, 06 Oct 1995 12:02:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 6 Oct 1995 18:02:05 +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: <951006180205.2180291d@vms.rhbnc.ac.uk>
Subject: Re: tds 0.99
>> I thought VMS supports foo/bar on the program level?! (Not on the
>> command level, though.) As it's supposed to be POSIX.1 conformant, it
>> must do so.
There's no evidence that it does. My top level directory
is Chaa:[006]; I have created in it a TeX file, Test.TeX,
containing:
\input unix/insert
\end
I have created a sub-directory [.Unix], and in it I have created
Insert.TeX, containing
\message {This is Insert.TeX, from Chaa:[006.Insert]}
I then (whilst in my top-level) directory, typed
$ TeX Test
to which TeX responds:
Please type another input file name:
to which I respond
[.Unix]Insert
at which point TeX finds the file...
:-(
>> Or did I misunderstand DEC announcements?
One cannot know!
I haven't seen Sebastian's message, but I would not support the idea of mapping
Unix filespecs to VMS equivalents within VMS TeX; I would far sooner propose
that we adopt the `file://...' URL as _the_ standard portable file specifier
within the TeX world, with the hope that, before long, intrinsic support for
URLs will become a feature of all operating systems and that we can therefore
hope to allow other URLs from within TeX within the forseeable future.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Fri, 06 Oct 1995 12:43:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 6 Oct 1995 18:42:33 +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: <951006184233.21c00248@vms.rhbnc.ac.uk>
Subject: Oops: a line dropped out of my message...
I meant to say
[...]
to which TeX responds:
! I can't find file `unix/insert.tex'.
Please type another input file name:
[...]
================================================================================
From owner-twg-tds@shsu.edu Fri, 06 Oct 1995 12:58:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 06 Oct 1995 18:57:59 CET +0100
From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" <spieler@linac.ikp.physik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: spieler@linac.ikp.physik.th-darmstadt.de
Message-ID: <009977A6.1E4059C2.10@linac.ikp.physik.th-darmstadt.de>
Subject: Re: tds 0.99
>> I thought VMS supports foo/bar on the program level?! (Not on the
>> command level, though.) As it's supposed to be POSIX.1 conformant, it
>> must do so.
The "foo/bar" syntax is supported for C programs. The VMS C runtime
library contains internal (and transparent!) support to translate
between Unix and VMS file specification syntax.
But, as far a I know, this feature is confined to the C (C++) programming
environment, other compilers like Pascal (TeX and friends are implemented
in Pascal on VMS!!) do NOT contain transparent UNIX path syntax
translation, sorry.
Christian Spieler
================================================================================
From owner-twg-tds@shsu.edu Fri, 06 Oct 1995 13:28:30 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 6 Oct 1995 11:28:21 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510061828.LAA21917@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: tds 0.99
Locally I hit that problem all the time, and I simply rename the offending
files, and the small number of calls to them in driver files.
I wouldn't redistribute them without consulting the author first, but
I have found that authors are often very amenable to the suggestion
that romanl.mf might in such a case be named aoromanl.mf
If a hypothetical aoromanl.mf is needed for compilation using a DEK
driver file, a symbolic link in the output directory will take
care of that with any normal paths. Of course you want to get
rid of the link before the next refresh of ls-R.
I am rather opposed to the notion of dialect forms of well-known files
like romanl.mf floating around the system.
%=======================================================================%
| 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, 06 Oct 1995 13:44:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 06 Oct 1995 19:44:17 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.99
To: TWG-TDS@SHSU.edu
Message-ID: <01HW4R1DZC8295MN8A@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
>I thought VMS supports foo/bar on the program level?! (Not on the
>command level, though.) As it's supposed to be POSIX.1 conformant, it
>must do so.
At least VMS TeX doesn't understand
\input foo/bar.tex
It understands
\input [.foo]bar.tex
and
\input <.foo>bar.tex
--J"org Knappen.
================================================================================
From owner-twg-tds@shsu.edu Fri, 06 Oct 1995 13:47:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 06 Oct 1995 19:47:34 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.99
To: TWG-TDS@SHSU.edu
Message-ID: <01HW4R5YGC3695MN8A@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Well, there is an additional product by DEC, a posix shell for VMS. If it
is installed, you can type
$posix
and find yourself in a UNIX-style environment. Guess this is what DEC
announcements mean.
--J"org Knappen.
================================================================================
From owner-twg-tds@shsu.edu Fri, 06 Oct 1995 17:53:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 06 Oct 1995 22:24:19 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Feeling uncomfortable with designation `public'
To: TWG-TDS@SHSU.edu
Message-ID: <01HW4W8BXRGY8WWJLO@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
After this debatte, I'd ask you to register a foudry
jknappen in the TDS tree. I suggest to place the following three
font packages there:
bashkirian
fc
dc and tc
With the Sauter fonts, the situation is more complicated. They should be
placed either
(a) together with the standard sources of Computer Modern
or
(b) under the name sauter
The complications arise because of duplicate names; both the base 75
parameter files by Knuth and the Sauter tools contain a file named
`cmr10.mf'. However, it does not matter which one you use, since the
Sauter file is designed to give *exactly* the same output as the Knuthian
one, and therefore qualifies as a legitimate `cmr10' according to the
copyright of Computer Modern.
If you use the Sauter tools you probably don't want to maintain a `split
distribution' of Computer Modern, with one part under knuth/cm/tfm another
under ams/cm/tfm and a third under sauter/cm/tfm.
Allthough I maintain the Sauter tools, my own contribution to them
consists only in some bug fixes, the original idea and implementation is
John Sauter's and hasn't changed substantially.
Yours, J"org Knappen.
P.S. It is interesting to go through the CTAN font directories and read the
licences and copyrights the authors have left there.
One font I have states that it may only distributed from ymir.claremont.edu
or tex.ac.uk (both archives don't exist anymore, and I never checked if
that special copyright was ever changed...)
================================================================================
From owner-twg-tds@shsu.edu Sat, 07 Oct 1995 23:36:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 7 Oct 1995 16:25:04 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510072025.AA23767@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: mft
remove all the \protect's in front of \MF and \BibTeX
Done. Thanks.
I don't quite remember the outcome of our previous discussion about
I didn't either, which is why I didn't do anything about it until I
could go back and look.
this, but didn't we decide to move /tex/mft to the top-level.
I think we did agree on this. Objections, anyone?
introduce another search path variable for MFTINPUTS in kpathsea
Yes, absolutely.
================================================================================
From owner-twg-tds@shsu.edu Sat, 07 Oct 1995 23:36:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 7 Oct 1995 16:25:05 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510072025.AA23775@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.99
Ugh. I'd still prefer some language encouraging people to gravitate towards
saying \input latex/foobar, etc.
I don't think this is desirable, even if / becomes a universal directory
separator (not likely to happen any time soon, anyway). Why should every
<format> user have to preface each \input with `<format>'? Seems like
TeX should be smart enough to do the Right Thing.
But also, I think that the issue of when duplicate file names within
texmf/tex are allowed should be explicitly addressed.
Yes, good point. I'll dream up something along these lines for us to
start from.
(This real world example is for the cmttss{c,lc,bc} fonts by Art Ogawa.)
...
I don't have a solution to offer for this, but it might be a good idea
The solution, btw, is for Art to rename his files.
I suggested this to him once, but he didn't reply.
================================================================================
From owner-twg-tds@shsu.edu Sun, 08 Oct 1995 17:53:17 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sun, 8 Oct 1995 15:53:10 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510082253.PAA21245@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.99
Further on the reuse of names like romanl.mf and romanu.mf:
I wonder how much real difference there is between the Art Ogawa
version and the DEK version. If it is only a small amount there is
even less reason to have two dialects of roman[lu].mf
The need to accept instances of duplicate names for such cases
as rasterized fonts remains obvious. There may be a couple of
additional cases, but not many. For the remainder, duplicate
names can and should at very least be discouraged.
================================================================================
From owner-twg-tds@shsu.edu Sun, 08 Oct 1995 21:03:39 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Sun, 8 Oct 1995 19:03:28 -0700 (PDT)
Message-ID: <199510090203.TAA08919@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.99
> Ugh. I'd still prefer some language encouraging people to gravitate
> towards saying \input latex/foobar, etc.
>
> I don't think this is desirable, even if / becomes a universal directory
> separator (not likely to happen any time soon, anyway). Why should every
> <format> user have to preface each \input with `<format>'? Seems like
> TeX should be smart enough to do the Right Thing.
They shouldn't, nor would they be required to. If they just say \input foobar,
then TeX would take any file from within texmf/tex//, or any subtree if that
occurs first on the path. What I have in mind is that macro package writers
use this feature, e.g., somewhere within their \documentclass, \usepackage,
or \documentstyle macros.
Regarding the issue of directory separators, if / is not the directory
separator on a given O/S, then TeX (the program, not any macro packages lying
over it) should be smart enough to Do the Right Thing and translate the
syntax appropriately, much as #include does in C.
The problem with TeX being smart enough is that whatever smarts it has is
limited by what it knows. Making the input path dependent on the format in
use provides TeX with some information, but I can easily imagine circumstances
in which that is not enough, or even misleading.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Mon, 09 Oct 1995 05:54:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 9 Oct 1995 11:53:55 +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: <951009115355.21c03100@vms.rhbnc.ac.uk>
Subject: Re: tds 0.99
>> Regarding the issue of directory separators, if / is not the directory
>> separator on a given O/S, then TeX (the program, not any macro packages lying
>> over it) should be smart enough to Do the Right Thing and translate the
>> syntax appropriately, much as #include does in C.
What a Unixo-centric view of TeX :-(
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Mon, 09 Oct 1995 11:31:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 9 Oct 1995 10:16:21 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510091416.AA18569@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Feeling uncomfortable with designation `public'
I'd ask you to register a foudry
jknappen in the TDS tree.
I don't think it's a matter for TDS, but rather for fontname.
The TDS standards document itself is not the place to try to register
every existing name. (There's no mention of `bitstream', for example.)
I've added jknappen to fontname's supplier.map.
What is fc, out of curiousity?
If you use the Sauter tools you probably don't want to maintain a `split
distribution' of Computer Modern, with one part under knuth/cm/tfm another
under ams/cm/tfm and a third under sauter/cm/tfm.
That is precisely how I do maintain them :-).
It's actually feasible to do this automatically with kpsewhich or some such.
Anyway, I don't see any need for a `sauter' supplier, unless John
himself requests such. They can just go under public. Ditto `knuth'; we
had that discussion long ago, and I don't see that anything's changed.
I've added a `sauter' directory in fontname's special.map, as a nod
towards registering it.
================================================================================
From owner-twg-tds@shsu.edu Mon, 09 Oct 1995 13:44:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 09 Oct 1995 19:44:19 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Feeling uncomfortable with designation `public'
To: TWG-TDS@SHSU.edu
Message-ID: <01HW8XUZO15E8ZERA5@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Karl wrote:
> I've added jknappen to fontname's supplier.map.
Thanks.
> What is fc, out of curiousity?
aFrican Computer modern fonts, now registered as LaTeX's T4 encoding.
They contain a selection of special letters needed for african languages
with latin writing. Documented once in TUGboat, a font table can also be
found in the EuroTeX95 proceedings.
--J"org Knappen.
================================================================================
From owner-twg-tds@shsu.edu Mon, 09 Oct 1995 15:31:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 9 Oct 1995 14:14:51 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510091814.AA21714@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Feeling uncomfortable with designation `public'
I'd ask you to register a foudry
jknappen in the TDS tree.
I don't think it's a matter for TDS, but rather for fontname.
The TDS standards document itself is not the place to try to register
every existing name. (There's no mention of `bitstream', for example.)
I've added jknappen to fontname's supplier.map.
What is fc, out of curiousity?
If you use the Sauter tools you probably don't want to maintain a `split
distribution' of Computer Modern, with one part under knuth/cm/tfm another
under ams/cm/tfm and a third under sauter/cm/tfm.
That is precisely how I do maintain them :-).
It's actually feasible to do this automatically with kpsewhich or some such.
Anyway, I don't see any need for a `sauter' supplier, unless John
himself requests such. They can just go under public. Ditto `knuth'; we
had that discussion long ago, and I don't see that anything's changed.
I've added a `sauter' directory in fontname's special.map, as a nod
towards registering it.
================================================================================
From owner-twg-tds@shsu.edu Mon, 09 Oct 1995 23:31:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 9 Oct 1995 14:14:51 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510091814.AA21714@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Feeling uncomfortable with designation `public'
I'd ask you to register a foudry
jknappen in the TDS tree.
I don't think it's a matter for TDS, but rather for fontname.
The TDS standards document itself is not the place to try to register
every existing name. (There's no mention of `bitstream', for example.)
I've added jknappen to fontname's supplier.map.
What is fc, out of curiousity?
If you use the Sauter tools you probably don't want to maintain a `split
distribution' of Computer Modern, with one part under knuth/cm/tfm another
under ams/cm/tfm and a third under sauter/cm/tfm.
That is precisely how I do maintain them :-).
It's actually feasible to do this automatically with kpsewhich or some such.
Anyway, I don't see any need for a `sauter' supplier, unless John
himself requests such. They can just go under public. Ditto `knuth'; we
had that discussion long ago, and I don't see that anything's changed.
I've added a `sauter' directory in fontname's special.map, as a nod
towards registering it.
================================================================================
From owner-twg-tds@shsu.edu Tue, 10 Oct 1995 09:03:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 10 Oct 1995 10:03:09 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510101403.AA12831@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: archive
Is anyone keeping an archive of tds mail? The one
on shsu.edu:[twg-tds] isn't letting me retrieve
the one for the current month, which is, of course, what
I want to read :-).
Mail to root/postmaster at shsu.edu and ftp.shsu.edu gets
no response ...
Any help appreciated.
================================================================================
From owner-twg-tds@shsu.edu Tue, 10 Oct 1995 09:34:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 10 Oct 1995 15:33:51 +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: <951010153351.21c048b6@vms.rhbnc.ac.uk>
Subject: RE: archive
>> Is anyone keeping an archive of tds mail? The one
>> on shsu.edu:[twg-tds] isn't letting me retrieve
>> the one for the current month, which is, of course, what
>> I want to read :-).
>> Mail to root/postmaster at shsu.edu and ftp.shsu.edu gets
>> no response ...
>> Any help appreciated.
Unless I've accidentally deleted something, I have all correspondence
going back to the time of my invitation to join...
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Tue, 10 Oct 1995 09:48:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 10 Oct 1995 15:46:02 +0100
Message-ID: <9510101446.AA17939@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: archive
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
> Is anyone keeping an archive of tds mail? The one
> on shsu.edu:[twg-tds] isn't letting me retrieve
> the one for the current month, which is, of course, what
> I want to read :-).
I do, or at least I'm trying to. Before I got added to the mailing
list back in March this year, I relied on the mail archive at shsu.edu
and found that it occasionally does strange. During the month of
March it started a new file several times, losing all the previous
mail accumulated during that month. I haven't looked at shsu.edu
any more since then, so I don't know what state it is in now.
It's a pity that there's nobody to fix it.
If your're only interested in the current mail, I can send your
my file. Beware that it's 70K already (starting from Oct 2).
Hope that it'll get through with too much delay.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Tue, 10 Oct 1995 10:26:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 10 Oct 1995 16:22:37 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510101522.QAA01836@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: archive
References: <199510101403.AA12831@terminus.cs.umb.edu>
> Is anyone keeping an archive of tds mail? The one
> on shsu.edu:[twg-tds] isn't letting me retrieve
> the one for the current month, which is, of course, what
> I want to read :-).
> Mail to root/postmaster at shsu.edu and ftp.shsu.edu gets
> no response ...
SHSU is like a frightful hell these days since George G went to live
in a parallel universe. theres not much we can do there. Joachim, do
youi archive it?
s
================================================================================
From owner-twg-tds@shsu.edu Wed, 11 Oct 1995 10:02:58 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510111502.QAA16283@spice.iti.informatik.th-darmstadt.de>
Subject: Re: archive
To: TWG-TDS@SHSU.edu
Date: Wed, 11 Oct 1995 16:02:40 +0100 (MEZ)
Content-Type: text
sebastian wrote:
>
> > archive of tds mail?
> Joachim, do youi archive it?
No. I always wanted to mirror shsu.edu, after I've repaired the mirror
program (not that I've done it yet ;-). Seems it would have been
better to archive it myself.
Sorry,
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, 11 Oct 1995 16:28:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 11 Oct 1995 17:28:28 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510112128.AA07160@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: archive
It's a pity that there's nobody to fix [shsu].
Indeed.
If your're only interested in the current mail, I can send your
my file. Beware that it's 70K already (starting from Oct 2).
Phil Taylor sent it to me. Thanks for the offer, though.
Guess keeping another archive somewhere would be a good idea :-).
================================================================================
From owner-twg-tds@shsu.edu Wed, 11 Oct 1995 16:34:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 11 Oct 1995 17:34:27 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510112134.AA07319@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Subject: Re: Comments and questions concerning draft 0.98, directory layout
(back on old tds mail)
> [musictex] The LaTeX style files should probably go into /texmf/tex/latex/musictex/;
> but the main macros, should the located under "plain" or under "generic"
> (The main macros are needed by the LaTeX interface!).
Then they go in generic/.
Can't musictex be a format, so then they would go in texmf/tex/musictex,
rather than texmf/tex/generic?
================================================================================
From owner-twg-tds@shsu.edu Wed, 11 Oct 1995 16:34:46 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 11 Oct 1995 17:34:26 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510112134.AA07311@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: .sty & .fd structure
Going through old mail. An unresolved issue -- what about the TeX inputs
.sty's and .fd's for fonts?
Is there a de facto solution people have adopted?
Sebastian?
> 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).
================================================================================
From owner-twg-tds@shsu.edu Wed, 11 Oct 1995 16:34:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 11 Oct 1995 17:34:29 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510112134.AA07335@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: modeless/ or not?
So, did we decide to drop modeless/? I'm not sure if we reached
consensus on this. I wrote up the following for the appendix, but find
myself unconvinced by these arguments.
\subsubsection{Modeless Bitmaps}
The \abbr{TDS} specifies using utility names as mode names for those
utilities which generate bitmaps, e.g., \path|texmf/fonts/pk/gsftopk/|.
An alternative was to introduce a single directory \path|modeless/|
below which all such directories could be gathered. This has the
advantage of not requiring each such directory name to be listed. But it
has disadvantages, too: it would use the last available directory level
on CD-ROM's; and it would put |pk| files at different depths in the font
tree, possibly hindering existing search strategies and certainly a
likely source of confusion. We decided to stay with existing practice
and keep the utility name at the same level as the mode names.
We may regret this decision. We are making an implicit assumption that
{\MF} is the only program producing mode-dependent bitmaps. This
assumption may be proven false in the future, and then the generating
program name will need to be included in all cases.
================================================================================
From owner-twg-tds@shsu.edu Thu, 12 Oct 1995 03:21:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 12 Oct 1995 09:17:49 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510120817.JAA01510@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: modeless/ or not?
References: <199510112134.AA07335@terminus.cs.umb.edu>
> consensus on this. I wrote up the following for the appendix, but find
> myself unconvinced by these arguments.
....
> We may regret this decision. We are making an implicit assumption that
> {\MF} is the only program producing mode-dependent bitmaps. This
> assumption may be proven false in the future, and then the generating
> program name will need to be included in all cases.
*i* am convinced by your arguments. the answer to the last para (in
theory) is to rename everything in modes.def to be prefixed with
"mf". we have a space for "what the hell generated this lot for what
sort of machine", and we can use it for what we like. maybe the
relatively adhoc naming in modes.def will have to be rethought, but
the principle seems sound to me
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 12 Oct 1995 03:22:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 12 Oct 1995 09:19:20 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510120819.JAA01574@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Comments and questions concerning draft 0.98, directory layout
References: <199510112134.AA07319@terminus.cs.umb.edu>
> > [musictex] The LaTeX style files should probably go into /texmf/tex/latex/musictex/;
> > but the main macros, should the located under "plain" or under "generic"
> > (The main macros are needed by the LaTeX interface!).
>
> Then they go in generic/.
>
> Can't musictex be a format, so then they would go in texmf/tex/musictex,
> rather than texmf/tex/generic?
i think we should use the format level sparingly; would anyone build a
musictex.fmt? i somehow doubt it. while i dont feel that strongly i'd
tend to go with the splitting analysis
s
================================================================================
From owner-twg-tds@shsu.edu Thu, 12 Oct 1995 03:59:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 12 Oct 1995 09:14:09 +0100
From: Sebastian Rahtz <s.rahtz@ELSEVIER.CO.UK>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510120814.JAA01366@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: .sty & .fd structure
References: <199510112134.AA07311@terminus.cs.umb.edu>
> Going through old mail. An unresolved issue -- what about the TeX inputs
> .sty's and .fd's for fonts?
> Is there a de facto solution people have adopted?
didnt we thrash at this a month ago? in what forum? gurk, my memory is
gone.
>
> > 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.
now hang on. we dont *want* people installing the non-psnfss old
psfonts stuff anyway. or am i confused?
> > tex/latex/fonts/adobe/bookman /* .sty and .fd files */
> > tex/latex/fonts/monotype/perpetua
i started to do this, but then realised we dont want that many
directory levels in there.
my memory is that it is up to `suppliers of packages' like me to
register package names, albeit at present simply informally. so my
solution is to say that i have already grabbed "adobe", "monotype",
"bh" etc, and that all the related files should go in there at one
level.
but i am not very happy about this
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 12 Oct 1995 07:11:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 12 Oct 1995 13:09:07 +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: <951012130907.21c0a8b5@vms.rhbnc.ac.uk>
Subject: TWG-TDS e-mail archive
At Karl's suggestion I have put up my e-mail archives
of TWG-TDS correspondence; they can be found at
ftp://vms.rhbnc.ac.uk/archives/twg-tds.<mon>-<yy>
with the earliest instance of <mon>-<yy> being AUG-94
and the most recent being OCT-95. If you find I have
missed any messages of which you have a copy, please let
me have them and I will attempt to integrate them into
the archive.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Thu, 12 Oct 1995 08:27:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 12 Oct 1995 09:27:48 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510121327.AA17276@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: .sty & .fd structure
solution is to say that i have already grabbed "adobe", "monotype",
"bh" etc, and that all the related files should go in there at one
Does the adobe/whatever level buy you anything? The filenames already
have to be distinct. Maybe just dump everything into latex/fonts or some
such?
================================================================================
From owner-twg-tds@shsu.edu Thu, 12 Oct 1995 08:30:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 12 Oct 1995 09:30:43 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510121330.AA17335@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Comments and questions concerning draft 0.98, directory layout
i think we should use the format level sparingly; would anyone build a
musictex.fmt? i somehow doubt it. while i dont feel that strongly i'd
tend to go with the splitting analysis
I absolutely did build musictex.fmt in my days of working with musictex.
It was far too slow otherwise (on a 50MHz 486 ...).
Anyway, we don't have to specify a location. Just thought we were being
a bit inconsistent in recommending tex/texinfo but not tex/musictex.
================================================================================
From owner-twg-tds@shsu.edu Thu, 12 Oct 1995 09:09:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 12 Oct 1995 15:06:34 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510121406.PAA21823@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: .sty & .fd structure
References: <199510121327.AA17276@terminus.cs.umb.edu>
K. Berry writes:
> solution is to say that i have already grabbed "adobe", "monotype",
> "bh" etc, and that all the related files should go in there at one
>
> Does the adobe/whatever level buy you anything? The filenames already
> have to be distinct. Maybe just dump everything into latex/fonts or some
> such?
um, you are right of course. in that case tex/latex/psnfss. it doesnt
help the person who develops a new style for a new typeface tho - do
they make a new package, or do they treat psnfss like misc, and simply
add to it?
my pragmatic answer is that i "own" tex/latex/psnfss so that should be
left alone, and others shoyld use tex/latex/fonts like they use misc
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 12 Oct 1995 09:13:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 12 Oct 1995 15:09:07 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510121409.PAA21834@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Comments and questions concerning draft 0.98, directory layout
References: <199510121330.AA17335@terminus.cs.umb.edu>
> I absolutely did build musictex.fmt in my days of working with musictex.
> It was far too slow otherwise (on a 50MHz 486 ...).
thats cos you didnt have Linux then :-}
> Anyway, we don't have to specify a location. Just thought we were being
> a bit inconsistent in recommending tex/texinfo but not tex/musictex.
or musixtex as we pc people say these days :-}
i think its sort of up to the author to lay claim to a new format or
not. texinfo clearly does. maybe Taupin does, maybe he doesnt. can
you somehow express that argument in the TDS docs?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 13 Oct 1995 16:52:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 13 Oct 1995 17:52:25 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510132152.AA10953@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: .sty & .fd structure
my pragmatic answer is that i "own" tex/latex/psnfss so that should be
left alone,
I agree. psnfss is an instance of `package'.
and others shoyld use tex/latex/fonts like they use misc
Hmm. Then do we really need to have a special case texmf/tex/latex/fonts/?
How about putting the singular .sty's/.fd's directly in misc/?
================================================================================
From owner-twg-tds@shsu.edu Fri, 13 Oct 1995 16:52:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 13 Oct 1995 17:52:24 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510132152.AA10945@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Comments and questions concerning draft 0.98, directory layout
i think its sort of up to the author to lay claim to a new format or
not. texinfo clearly does. maybe Taupin does, maybe he doesnt. can
you somehow express that argument in the TDS docs?
Well, I added a parenthetical:
Although some formats (e.g., Texinfo, Eplain) can also
be used as macro packages, the \abbr{TDS} nevertheless stores them as
formats (at the option of the format author).
If someone thinks more is needed, speak up (with specifics :-).
================================================================================
From owner-twg-tds@shsu.edu Fri, 13 Oct 1995 16:53:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 13 Oct 1995 17:52:32 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510132152.AA10988@terminus.cs.umb.edu>
To: ntg@nic.surfnet.nl
CC: twg-tds@shsu.edu
Subject: tds discussions
I seem to be acting as de factor chair of the TDS group, as Norm Walsh
is attending to other responsibilities. A couple reports from the
EuroTeX meeting (thanks, Ulrik) suggested you'd like to participate in
the TDS discussions. You are most welcome to do so; we welcome
participation by anyone.
If you (or anyone else reading this) wants to be included as a
``committee member'' on the last page, just mail me the details.
The mailing list is twg-tds@shsu.edu. I myself have no privileges to add
or remove anyone from the list, but I hope you can subscribe
automatically by mailing to twg-tds-request@shsu.edu.
In the meantime, I'll email you about the next (still non-public) draft
when I finish it for your comments.
Thanks.
karl@cs.umb.edu
================================================================================
From owner-twg-tds@shsu.edu Sat, 14 Oct 1995 10:18:45 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510141518.QAA18845@spock.iti.informatik.th-darmstadt.de>
Subject: Re: .sty & .fd structure
To: TWG-TDS@SHSU.edu
Date: Sat, 14 Oct 1995 16:17:59 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> and others shoyld use tex/latex/fonts like they use misc
>
> Hmm. Then do we really need to have a special case texmf/tex/latex/fonts/?
No, please not.
> How about putting the singular .sty's/.fd's directly in misc/?
If the distribution is a single file, yes. Otherwise the distribution
name is used. (E.g., like Ulrik's ssqquote or mflogo.)
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, 14 Oct 1995 16:23:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 14 Oct 1995 17:23:00 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510142123.AA23442@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: directory names and iso-9660
Does anyone know if directory names can have an extension in ISO-9660?
================================================================================
From owner-twg-tds@shsu.edu Sat, 14 Oct 1995 16:23:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 14 Oct 1995 17:23:01 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510142123.AA23450@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: tex/generic vs. tex/images
Remember we were talking about using texmf/tex/images for image files,
since they're format-independent.
But this would mean complicating the paths, since everything would have
to include both texmf/tex/generic and texmf/tex/images.
How about texmf/tex/generic/images/*.eps? (Or maybe this is what we
settled on? There were a lot of proposals flying around.)
This seems more natural to me. Analogous to hyphen/, etc.
================================================================================
From owner-twg-tds@shsu.edu Sat, 14 Oct 1995 16:25:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 14 Oct 1995 17:23:02 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510142123.AA23461@terminus.cs.umb.edu>
To: twg-tds@shsu.edu, ntg@nic.surfnet.nl
Subject: tds 0.100
OK, I've added a bunch of stuff for version 0.100. Here's the
ChangeLog. No diffs this time, they'd be bigger than the document.
ftp.cs.umb.edu:/private/tex/tds/.
I added an appendix on file formats, but I don't know the answer to all
of them, and I'm sure some are still missing. Please help. Also, the
formatting needs to be improved (no extra vertical space between items).
I changed the address for postal comments to say TUG instead of
ORA. Seem reasonable? With publication in TUGboat, we might actually get
postal comments, so we should probably alert the TUG office? I'd
actually feel more comfortable getting them myself (then I know they
won't get lost in transit), but it seems a bit odd to have a personal
postal address on a standards document :-).
Does anyone object if I make the section titles lowercase (i.e., follow
normal rules, not the dumb [IMHO] American ``title'' rules)? They're
bothering me.
Christian, I added you to the author list at the end. I also
(heavily) edited your email message about the DECUS TeX structure into a
section in the appendix. Please inspect and emend as necessary ...
Joachim, I changed tdsguide.cls. Don't know if you're tracking that.
Also, I have a question -- can we easily change the formatting for the
table of contents? I really want it to fit on one page. That means we
have to squeeze things a bit.
I've been ruthlessly editing things for conciseness, consistency, etc.
Hope nobody minds.
Sat Oct 14 16:07:16 1995 Karl Berry <karl@cs.umb.edu>
* Version 0.100.
Fri Oct 13 16:23:34 1995 Karl Berry <karl@cs.umb.edu>
* tdsguide.cls (\textwidth): Make a little larger. Don't bother
reading tdsguide.cfg just to get mflogo.
- Mention that a format author doesn't have to have a <format>
directory.
- Don't use makeindx as an example.
Thu Oct 12 14:19:25 1995 Karl Berry <karl@cs.umb.edu>
- Add Christian Spieler to the author list.
- Reserve tex/images for eps files etc.
- Remove implication the texmf/tex/plain has no subdirectories.
- More implementation-specific stuff, this time under
`program'. From Alex Kok et al.
- Expound on texmf/source a bit. From Alex Kok.
- Tell people to go read if we're talking about mysteries
- Remove all instances of the confusing word `application'.
- Mention that examples are documentation, and move discussion of
the alternative to an appendix.
Tue Oct 10 15:45:32 1995 Karl Berry <karl@cs.umb.edu>
- New section on duplicate filenames.
- Image files are likely to go under texmf/tex.
- Printers can have multiple resolutions. From Bernard Gaulle.
- Reference the level 0 DVI standard.
- Define `dpi' better. From Nelson Beebe, David Kastrup.
- Document the reasons for not using modeless/. From David Kastrup.
- Mention the (presently impractical) possibility of \input
latex2e/file.tex. From Paul Vojta.
- make uninstall or an equivalent is desirable. From Alan Dunwell.
- Remove `files are...' text. From Doug Waud.
- /opt is another likely root. From Jeff Gealow.
- Use dpiNNN, not just dpi. From Bart Childs.
- Slightly improved description of MP. From Bart.
- Recommend . at beginning of search paths. From DEK via Sebastian.
- Include musictex as an example generic/ directory.
Mon Oct 9 17:36:27 1995 Karl Berry <karl@cs.umb.edu>
- mft/ is no longer a special case under tex/.
- Move `package distribution' to an appendix section.
Fri Oct 6 17:23:15 1995 Karl Berry <karl@cs.umb.edu>
- Remove \protect. From Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Sun, 15 Oct 1995 06:56:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 15 Oct 95 04:58:40 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9510151158.AA22968@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: registration of names
I have been remiss in specifying the exact format for registering TDS
names, but I have a fairly compelling reason: I can't discern, from
reading the discussions in this group, how much "uniqueness" an item
should be able to claim for its name.
That is, which directories and/or files should we allow a font or filter
author (e.g., "morin") to claim? If there is someone on this list who
feels comfortable in helping me with this, please get in touch with me
(rdm@cfcl.com). I'll be glad to bap notes back and forth until we see
eye to eye.
Thanks, Rich
================================================================================
From owner-twg-tds@shsu.edu Sun, 15 Oct 1995 07:16:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 15 Oct 95 13:12:37 WET
From: GOOSSENS@CERNVM.CERN.CH
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.100
To: TWG-TDS@SHSU.edu
On Sat, 14 Oct 1995 17:23:02 -0400 K. Berry said:
>
Karl, many thanks for your work in coordinating the editing of the
"final proposal" for tds, that will be published in TUGboat 16#4 to
come out at the end of this year. I also appreciate the contributions
by all those individuals who have collaborated in making the document
a workable compromise that will form a sound basis for a directory
structure for tex-related software that is not too much biased towards
a particular operating system. I hope that all developers will find this
proposal acceptable and the tds structure as soon as possible.
>I changed the address for postal comments to say TUG instead of
>ORA. Seem reasonable? With publication in TUGboat, we might actually get
>postal comments, so we should probably alert the TUG office? I'd
>actually feel more comfortable getting them myself (then I know they
>won't get lost in transit), but it seems a bit odd to have a personal
>postal address on a standards document :-).
I think it is up to the tds working group to decide who is to receive the
comments, since it is better that they are dealt with immediately rather
than centralized in the TUG Office, which will have them to pass them on to
a nominated individual anyway. So I think it would be more efficient to
decide on a contact person/address to receive electronic and postal comments.
Michel Goossens
================================================================================
From owner-twg-tds@shsu.edu Sun, 15 Oct 1995 09:26: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: <199510151426.PAA12277@spock.iti.informatik.th-darmstadt.de>
Subject: Re: tex/generic vs. tex/images
To: TWG-TDS@SHSU.edu
Date: Sun, 15 Oct 1995 15:26:38 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> How about texmf/tex/generic/images/*.eps?
I like that.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Sun, 15 Oct 1995 09:48:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 15 Oct 95 07:51:02 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9510151451.AA23644@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: directory names and iso-9660
> Does anyone know if directory names can have an extension in ISO-9660?
Yes; no (:-).
Only files can have extensions. Technically, a file name can have just
a name or an extenstion, but it will always have the seperating period.
-r
================================================================================
From owner-twg-tds@shsu.edu Sun, 15 Oct 1995 11:31:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 15 Oct 1995 11:23:29 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510151523.AA08077@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: GOOSSENS@crnvma.cern.ch
Subject: Re: tds 0.100
I think it would be more efficient to
decide on a contact person/address to receive electronic and postal comments.
OK. THanks for the info, Michel.
Unless someone objects, I'm going to put my name/address on it, then.
================================================================================
From owner-twg-tds@shsu.edu Mon, 16 Oct 1995 14:38:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 16 Oct 1995 15:38:19 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510161938.AA27792@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: var vs. ro data in TDS
I asked a friend to look at the draft TDS, and one of his immediate
comments was:
2. The Linux File System Standard has texmf directories in two places:
one for invariant data (which can then be in a read-only filesystem) and
one (/var/lib/texmf) for variable data such as dynamically constructed
fonts. I think it's important that you accommodate this standard.
We can't require any such thing, I think, but we should probably mention
this. I guess it's handled as a separate ``local'' tree or something?
Any thoughts?
================================================================================
From owner-twg-tds@shsu.edu Mon, 16 Oct 1995 17:05:34 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Mon, 16 Oct 1995 15:05:29 -0700 (PDT)
Message-ID: <199510162205.PAA03709@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: tds 0.100
May I suggest the following diff:
*** tds.tex Mon Oct 16 13:34:23 1995
--- tds.new Mon Oct 16 15:02:40 1995
***************
*** 1220,1228 ****
into different sections of the tree right at the top level).
If documents could portably specify a directory part in filenames (as in
! \path|\input latex2e/file.tex|), the entire \abbr{TDS} tree might look
! different, because then duplicate ``filenames'' would be restricted to
! the 8.3 lowest-common-denominator. However, this is not currently practical.
\subsection{Macro Structure}
The \abbr{TWG} settled on the
--- 1220,1230 ----
into different sections of the tree right at the top level).
If documents could portably specify a directory part in filenames (as in
! \path|\input latex2e/file.tex|), restrictions on uniqueness of filenames
! could be relaxed considerably (with the cooperation of the macro packages),
! and the search path would not need to depend on the format.
! However, this is not currently practical, since no current {\TeX}
! implementation supports this.
\subsection{Macro Structure}
The \abbr{TWG} settled on the
In the current wording, it's not at all clear to me how the TDS tree might
look different.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Tue, 17 Oct 1995 03:53:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 17 Oct 95 09:49:18 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9510170849.AA15928@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.100
>>>>> Paul Vojta writes:
> May I suggest the following diff:
> *** tds.tex Mon Oct 16 13:34:23 1995
> --- tds.new Mon Oct 16 15:02:40 1995
> ***************
> *** 1220,1228 ****
> into different sections of the tree right at the top level).
> If documents could portably specify a directory part in filenames (as in
> ! \path|\input latex2e/file.tex|), the entire \abbr{TDS} tree might look
> ! different, because then duplicate ``filenames'' would be restricted to
> ! the 8.3 lowest-common-denominator. However, this is not currently practical.
> \subsection{Macro Structure}
> The \abbr{TWG} settled on the
> --- 1220,1230 ----
> into different sections of the tree right at the top level).
> If documents could portably specify a directory part in filenames (as in
> ! \path|\input latex2e/file.tex|), restrictions on uniqueness of filenames
> ! could be relaxed considerably (with the cooperation of the macro packages),
> ! and the search path would not need to depend on the format.
> ! However, this is not currently practical, since no current {\TeX}
> ! implementation supports this.
> \subsection{Macro Structure}
> The \abbr{TWG} settled on the
> In the current wording, it's not at all clear to me how the TDS tree might
> look different.
> --Paul Vojta, vojta@math.berkeley.edu
Sorry for coming to this a bit late, but I still do not really
understand this proposal, with either wording.
Is the intention that TeX supports \input latex/file.tex to mean to
find file.tex in some sub-directory recursively below latex for
instance \input latex/graphics.sty finds latex/graphics/graphics.sty
If not, and \input latex/file.tex is supposed to mean that file.tex
is in a directory called latex, then the TDS would need completely
restructuring, not just relaxing a uniqueness restriction.
Furthermore, the particular example |\input latex2e/file.tex| is a bad
one as the TDS directory name for LaTeX is latex not latex2e, and the
primitive TeX \input syntax (without {}) is strongly discouraged in
LaTeX.
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 17 Oct 1995 07:21:01 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510171220.NAA15289@spock.iti.informatik.th-darmstadt.de>
Subject: Re: var vs. ro data in TDS
To: TWG-TDS@SHSU.edu
Date: Tue, 17 Oct 1995 13:20:10 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> I asked a friend to look at the draft TDS, and one of his immediate
> comments was:
>
> 2. The Linux File System Standard has texmf directories in two places:
> one for invariant data (which can then be in a read-only filesystem) and
> one (/var/lib/texmf) for variable data such as dynamically constructed
> fonts. I think it's important that you accommodate this standard.
>
> We can't require any such thing
Why not?
A (more-or-less) standard place (i.e., subtree) for generated fonts
would be a Good Thing. And for Unix systems we should note that this
place is often a symlink in a /var area.
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, 17 Oct 1995 09:04:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 17 Oct 1995 10:04:18 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510171404.AA10151@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: var vs. ro data in TDS
A (more-or-less) standard place (i.e., subtree) for generated fonts
would be a Good Thing.
Where do you suggest?
And for Unix systems we should note that this
place is often a symlink in a /var area.
I don't see why we should recommend generated fonts be kept separately
from ``original'' fonts. It might be useful at some sites; but it isn't
everywhere.
I agree we should mention this case. More than that, I don't know.
What I meant was, we obviously cannot say ``you will use
/var/something'' as the place to put them. We only control stuff under
texmf/, not other system directories.
================================================================================
From owner-twg-tds@shsu.edu Tue, 17 Oct 1995 09:37:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 17 Oct 1995 10:37:04 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510171437.AA10538@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.100
> ! However, this is not currently practical, since no current {\TeX}
> ! implementation supports this.
Ohh, you're speculating on a new syntax for filename searches within TeX ...?
I didn't understand that before.
> In the current wording, it's not at all clear to me how the TDS tree might
> look different.
Probably because it wasn't clear to me, either. What is your conception
of how the tree would change?
Is the intention that TeX supports \input latex/file.tex to mean to
find file.tex in some sub-directory recursively below latex for
I don't know. Paul, is that what you had in mind?
If so, I don't think this is the right syntax to contemplate;
latex/file.tex should mean look for a file file.tex in a directory latex,
because that's a regular filename path.
Perhaps //?
Furthermore, the particular example |\input latex2e/file.tex| is a bad
one as the TDS directory name for LaTeX is latex not latex2e, and the
primitive TeX \input syntax (without {}) is strongly discouraged in
LaTeX.
Thanks for catching that. I guess the example will be
plain//testfont.tex or something.
================================================================================
From owner-twg-tds@shsu.edu Tue, 17 Oct 1995 14:14:37 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Tue, 17 Oct 1995 12:14:28 -0700 (PDT)
Message-ID: <199510171914.MAA04800@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.100
On Tue, 17 Oct 95 09:49:18 BST, David Carlisle <carlisle@cs.man.ac.uk> wrote:
> >>>>> Paul Vojta writes:
>
> > May I suggest the following diff:
>
> [omitted]
>
> Sorry for coming to this a bit late, but I still do not really
> understand this proposal, with either wording.
>
> Is the intention that TeX supports \input latex/file.tex to mean to
> find file.tex in some sub-directory recursively below latex for
> instance \input latex/graphics.sty finds latex/graphics/graphics.sty
Yes. Specifically, if you say \input latex/file.tex, and the search path
is .:/usr/local/texmf/tex//, then:
(1) first it checks for ./latex/file.tex
(2) then it looks recursively within /usr/local/texmf/tex/latex for a file
named file.tex.
> If not, and \input latex/file.tex is supposed to mean that file.tex
> is in a directory called latex, then the TDS would need completely
> restructuring, not just relaxing a uniqueness restriction.
Not applicable.
> Furthermore, the particular example |\input latex2e/file.tex| is a bad
> one as the TDS directory name for LaTeX is latex not latex2e,
Correct; mea culpa.
> and the
> primitive TeX \input syntax (without {}) is strongly discouraged in
> LaTeX.
Of course in LaTeX you use \documentclass or \usepackage, but with the
LaTeX macro package that eventually reduces to \input. My intent is that
the macro package would insert "latex/" or whatever; hence the wording
``(with the cooperation of the macro packages).'' See my message of 24 June.
Also, on Tue Oct 17 08:04:46 1995, "K. Berry" <kb@cs.umb.edu> wrote:
> > ! However, this is not currently practical, since no current {\TeX}
> > ! implementation supports this.
>
> Ohh, you're speculating on a new syntax for filename searches within TeX ...?
> I didn't understand that before.
More precisely, an extension of the current syntax; see above.
> > In the current wording, it's not at all clear to me how the TDS tree
> > might look different.
>
> Probably because it wasn't clear to me, either. What is your conception
> of how the tree would change?
My conception is that it wouldn't change.
> Is the intention that TeX supports \input latex/file.tex to mean to
> find file.tex in some sub-directory recursively below latex for
>
> I don't know. Paul, is that what you had in mind?
> If so, I don't think this is the right syntax to contemplate;
> latex/file.tex should mean look for a file file.tex in a directory latex,
> because that's a regular filename path.
> Perhaps //?
Hm. I hadn't considered that. I figured the // would stick around from the
TEXFONTS variable. Actually, I still prefer only /. To use LaTeX as an
example, with //, latex would translate \usepackage{foo} into
\input latex//foo.sty, but then \usepackage{ams/foo} would translate into
\input latex//ams/foo.sty. It would work, but it wouldn't be pretty.
Also, if '.' is at the beginning of the search path, and if a directory
./latex exists, then it would do an unintended recursive search within that
directory.
> Furthermore, the particular example |\input latex2e/file.tex| is a bad
> one as the TDS directory name for LaTeX is latex not latex2e, and the
> primitive TeX \input syntax (without {}) is strongly discouraged in
> LaTeX.
>
> Thanks for catching that. I guess the example will be
> plain//testfont.tex or something.
plain/testfont.tex is fine with me.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Tue, 17 Oct 1995 15:37:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 17 Oct 1995 14:21:19 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510171821.AA13837@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: package vs. format?
Just to clarify our examples a bit: babel is a package, right, not a format?
Ditto amslatex? (amslatex used to be either one, but now it's just a
latex package, right?)
I added this text to try to define these terms a bit more clearly:
The \abbr{TDS} specifies that macros are stored in separate directories,
segregated by format and package, a `package' here being simply one or
more {\TeX} input files generally containing only macro definitions, and
a `format' being a usefully \path|\dump|-able package.
Actually, it might be good to use a different term for the macro
\replaceable{package}, since it's at odds with our (traditional) use of
`package' elsewhere, but I can't think of anything decent.
================================================================================
From owner-twg-tds@shsu.edu Tue, 17 Oct 1995 19:57:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 17 Oct 1995 20:57:31 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: package vs. format?
To: TWG-TDS@SHSU.edu
Message-ID: <813977851.255229.BNB@MATH.AMS.ORG>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
karl asks:
Just to clarify our examples a bit: babel is a package, right, not a format?
Ditto amslatex? (amslatex used to be either one, but now it's just a
latex package, right?)
i think there may still be instructions on how to make a format
out of amslatex, but it's not what we recommend. so, just a package.
-- bb
================================================================================
From owner-twg-tds@shsu.edu Tue, 17 Oct 1995 23:31:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 17 Oct 1995 14:21:19 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510171821.AA13829@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: PK file contents recommendation
I think we should ``recommend'' rather than ``require'' the
mode/magstep/etc. specials for PK fonts. This is the only place in the
entire TDS where we say anything about file contents rather than file
locations, and it seems a bit inconsistent. By this argument, we should
also require comments in TeX input files, etc. (Not a bad idea to
recommend that, either, come to think of it ...)
================================================================================
From owner-twg-tds@shsu.edu Wed, 18 Oct 1995 09:32:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 18 Oct 1995 10:31:39 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510181431.AA27294@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.100
Hm. I hadn't considered that. I figured the // would stick around from the
TEXFONTS variable. Actually, I still prefer only /. To use LaTeX as an
I think it's not worth debating the syntactic details of a hypothetical
feature :-). I'll try to write something nonspecific that gets the point
across.
Thanks for the clarifications.
================================================================================
From owner-twg-tds@shsu.edu Wed, 18 Oct 1995 11:31:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 18 Oct 1995 10:31:39 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510181431.AA27294@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.100
Hm. I hadn't considered that. I figured the // would stick around from the
TEXFONTS variable. Actually, I still prefer only /. To use LaTeX as an
I think it's not worth debating the syntactic details of a hypothetical
feature :-). I'll try to write something nonspecific that gets the point
across.
Thanks for the clarifications.
================================================================================
From owner-twg-tds@shsu.edu Wed, 18 Oct 1995 14:52:58 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510181902.UAA19736@spice.iti.informatik.th-darmstadt.de>
Subject: Re: var vs. ro data in TDS
To: TWG-TDS@SHSU.edu
Date: Wed, 18 Oct 1995 20:02:33 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> A (more-or-less) standard place (i.e., subtree) for generated fonts
> would be a Good Thing.
>
> Where do you suggest?
fonts/tmp/pk/
due to established practice... ;-)
> And for Unix systems we should note that this
> place is often a symlink in a /var area.
>
> I don't see why we should recommend generated fonts be kept separately
> from ``original'' fonts. It might be useful at some sites; but it isn't
> everywhere.
Of course, as personal boxes are the most prominent situation, it
won't be used at most sites. But I think that almost all non-personal
installations will mount the texmf-tree from somewhere in read-only
mode (it's faster than read-write). Then fonts/tmp/pk/ is typically a
symlink to somewhere else, why not to /var/texmf/fonts/pk/ on Unix
systems?
And isn't /var/texmf/web2c/texmf.cnf a good place for a config file
augmenting a CD installation with a local tree?
I admit that this discussion is Unix-centric, in case of a CD
installation on a Windoof PC we won't have symlinks.
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, 18 Oct 1995 15:23: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: <199510181854.TAA16382@spice.iti.informatik.th-darmstadt.de>
Subject: Re: package vs. format?
To: TWG-TDS@SHSU.edu
Date: Wed, 18 Oct 1995 19:54:51 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> Just to clarify our examples a bit: babel is a package, right, not a format?
Yes. It's supposed to be a generic package, i.e., the macro files are
normally placed in tex/generic/babel/. (`Normally' because the
current babel distribution has an error that prevents the usage of
most of its macro files with Plain TeX. But that should be possible
again with the next version, according to Johannes. :-)
> I added this text to try to define these terms a bit more clearly:
>
> The \abbr{TDS} specifies that macros are stored in separate directories,
> segregated by format and package, a `package' here being simply one or
> more {\TeX} input files generally containing only macro definitions, and
> a `format' being a usefully \path|\dump|-able package.
>
> Actually, it might be good to use a different term for the macro
> \replaceable{package}, since it's at odds with our (traditional) use of
> `package' elsewhere, but I can't think of anything decent.
Why is it at adds with our (traditional) use? It _is_ the traditional
`package' term, isn't it?
I'd like to see `distributed together' somewhere in the sentence
above, perhaps after `input files'. But then, perhaps one should make
two sentences. Btw, is it really `usefully', addressing `\dump-able'?
Isn't it more the `\dump-able package' and thus `useful'?
Sorry, still didn't find the time to read 0.100 thoroughly. But in my
scetchy reading I stumbled over the location of libkpathsea -- surely
.../lib/ instead of .../info/.
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, 19 Oct 1995 05:10:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 19 Oct 1995 11:07:16 +0100
Message-ID: <9510191007.AA00215@macbeth.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: tds 0.100 feedback
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
It's been a long time since I last read a TDS draft, but after
a fresh reading (without checking what's old or what's new),
here's what I noticed.
*
modern systems. In particular, this Technical Working Group (TWG)
believes it is usable under Unix, \abbr{ms-dos}, Windows \abbr{nt},
\abbr{os/2}, MacOS, and \abbr{vms}. We hope that administrators and
^^^^^
developers of both free and commercial implementations of {\TeX} will
adopt this standard.
Why not: Mac\abbr{os}? (For visual consistency with \abbr{os/2})
*
\item
Names and extensions may consist of \emphasis{only} the
characters \literal{A}--\literal{Z},
\literal{0}--\literal{9}, and underscore.
What about hyphen? It's so common in filenames on some systems
that I'm really surprised to read here that it's not allowed.
Could anyone confirm this?
*
\item Names of {\TeX} input files must be unique only within each
first-level subdirectory of \path|texmf/tex| and
\path|texmf/tex/generic|; i.e., different formats may have files by the
same name. (\ref{sec:Macros} discusses the macro structure.)
^^^^^^^^^^^^^^^^
Please make this: Section~\ref{...} (If that causes bad line breaks
you might say `{\TeX} formats' instead of `formats' to fill the line.
*
The \path|dtx| files used for {\LaTeX} distribution contain
both the program sources and the documentation sources, so they
^^^^^^^
are kept in the \path|source| tree.
I think saying `macro sources' would be clearer. Speaking of `program
sources' in the context of LaTeX might be confusing to some people.
*
\item \path|config| is reserved for configuration files, whether used
only by {\iniTeX} or not. Configuration files are used by several
formats; for example, {\LaTeX} and Babel.
Is Babel a format? Anyway, I thing the matter of config files may need
some clarifications.
1. Should \path{config} be reserved for config files that affect the base
format (and closely related packages) or should config files for
individual packages go here as well? (Take the example of tdsguide.cfg
if someone wanted to install tdsguidle.cls as a LaTeX package/bundle.)
2. Should \path{config} be reserved to local/user generated config files
while leaving distributed config files (like Babel's hyphen.cfg)
in the corresponding package directory? (Babel's configuration file
is language.dat, which for some reason doesn't have a .cfg extension.)
3. What about packages that may have arbitrary config files, such as
myletter.cls, which has a \usename{} feature to load config files
for individual letterheads.
4. Should \path{config} be restriced to the local tree if there is
a distinction?
*
Usually, this is usually the name of the {\MF} mode used to build the
^^^^^^^ ^^^^^^^
\path|PK| file.
Drop the second `usually'!
*
This information is easy to supply: a simple addition to the local modes
used for building the fonts with {\MF} will automatically provide the
required information. If you have been using a local modes file derived
from (or that is) \path|modes.mf| (complete reference in
^^^^^^^^^^^^^^^^^^^^^
Section~\ref{sec:Related References}), the required information is
already in your \path|PK| files. If not, a simple addition based on the
code found in \path|modes.mf| can be made to your local modes file and
the \path|PK| files rebuilt.
Is it necessary to repeat this everytime when modes.mf is mentioned?
(It appears at least twice with `complete reference in ...'.)
*
The documentation directories may contain {\TeX}
sources, \path|DVI| files, {\PS} files, text files, or
whatever form of documentation will best explain the package.
Maybe add that it may contain TeX, LaTeX, MF, MP examples as well?
(Remember David Rhead's mails about whether to separate examples from
documentation or not? Personally , I can't remember the outcome.)
*
We recommend all implementations have default search paths that start
with the current directory (e.g., `\path|.|').
Maybe add the Knuth recommends including \path|..| as well?
*
\item{\path|libkpathsea.*| in} \replaceable{prefix}\path|/info|
^^^ ^^^^
You can't mean that. Obviously a silly typo.
*
\section{File Formats and TDS Locations}
This section lists file types used in the {\TeX} system and their
placement according to the \abbr{TDS}. If you are unfamiliar with any
of these, consult the references (Section~\ref{sec:Related References}).
It might be a nice idae to flesh out this list and add a more verbose
description of what the individual file types are. If I had more time,
I might write up something, but not at the moment.
*
This improves the maintainability of the font tree,
but, unless all the programs that search this tree employ some form of
caching, there are serious performance concerns. For example, in order
to find \path|cmr10.tfm|, {\TeX} would potentially have to search
^^^
through all the directories that contain \path|pk| files
^^
in all modes and at all resolutions.
I don't understand this. Is this a mix-up or something?
*
In the former case, it isn't easy to limit subdirectory searching to only
the mode required for the particular printer you are using. And in the
^^^^^^^^^^
latter case, leaving \path|dpi|\replaceable{NNN} at the bottom
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
allows that level to be omitted on systems which allow long filenames
(e.g., \path|cmr10.300pk|).
I find this confusing since in the second case |dpi| is not at the bottom.
Or did you mean `... not leaving |dpiNNN| at the bottom doesn't allow ...'?
*
All discussions were held by email. The discussions
are archived on \path|shsu.edu:[twg-tds]|.
Maybe add alternative archive addresses, since shsu.edu has problems?
*
\section{About the Committee}
The \abbr{TWG} had no formal meetings (many, but not all, members attended
\abbr{tug} '94).
And some attended TUG'95 and/or EuroTeX'95 as well. I don't quite see what
the reference to TUG'94 should imply here, or maybe it's just outdated.
*
Rahtz, Sebastian
(\literal{s.rahtz@elsevier.co.cuk}). Production Methods
^^^
Obviously a typo.
*
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} in early 1995.
^^^^^^^^^^^^
This is getting out of date, better drop it.
As a general note: What about mentioning that other people participated
in the TWG who aren't listed here. Otherwise, readers might get the
impression that VMS people are under-represented in this group, even
though we have Phil and Joerg keeping a watchful eye on us Unix people.
That's all for this time.
Cheers,
Ulrik.
P.S. Joachim, could you arrange to mirror Karl's new drafts in the
usual location at ftp.th-darmstadt.de, or would that cause them to
be mirrored on CTAN as well (which some didn't want as I remember)?
For some reason, I always have connection problem's to Karl's site.
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 Oct 1995 11:57:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 19 Oct 95 17:56:57 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9510191656.AA19111@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.100
Me> If not, and \input latex/file.tex is supposed to mean that file.tex
Me> is in a directory called latex, then the TDS would need completely
Me> restructuring, not just relaxing a uniqueness restriction.
Paul> Not applicable.
Ah in that case I think latex/file.tex would be a very bad syntax for
this as the current semantics for it on any TeX that accepts / as a
directory separator *is* that the input path contains a
directory called latex directly containing a file called file.tex.
I'm not sure what a good syntax would be, or even the intended meaning.
Is \input latex//*//file.tex (say) supposed to restrict the search
just to the top level texmf/tex/latex subtree or does it search the
whole tree, including texmf/tex/plain/* looking for a directory latex,
and then looking below that for a file called file.tex?
Personally I'd rather the whole notion be dropped, I am sure that some
version of this idea would be useful, but it just seems too late in
the day after months of discussions to be adding new ideas to the
draft.
If it goes in I think it should not suggest any possible syntax and be
suitably vague about sematics, something like ... if it were possible
to restrict the search path to a subtree via the use of suitable TeX
macros .....
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 Oct 1995 13:02:48 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Thu, 19 Oct 1995 11:02:42 -0700 (PDT)
Message-ID: <199510191802.LAA07629@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.100 feedback
On Thu Oct 19 04:01:19 1995,
vieth@thphy.uni-duesseldorf.de (Ulrik Vieth) wrote:
>
> *
> This improves the maintainability of the font tree,
> but, unless all the programs that search this tree employ some form of
> caching, there are serious performance concerns. For example, in order
> to find \path|cmr10.tfm|, {\TeX} would potentially have to search
> ^^^
> through all the directories that contain \path|pk| files
> ^^
> in all modes and at all resolutions.
>
> I don't understand this. Is this a mix-up or something?
No, but implementing texmf/fonts/supplier/typeface/type/... would be a mix-up
for the above-mentioned reason. The problem is: how does TeX know that the
dvi file isn't located in some weird place like
texmf/fonts/foo/bar/pk/dpi300/tfm/cmr10.tfm ?
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 Oct 1995 15:15:34 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Thu, 19 Oct 1995 11:15:23 -0700 (PDT)
Message-ID: <199510191815.LAA07649@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.100
On Thu Oct 19 10:16:17 1995, David Carlisle <carlisle@cs.man.ac.uk> wrote:
>
...
>
> Ah in that case I think latex/file.tex would be a very bad syntax for
> this as the current semantics for it on any TeX that accepts / as a
> directory separator *is* that the input path contains a
> directory called latex directly containing a file called file.tex.
Is that _useful_ semantics?
> I'm not sure what a good syntax would be, or even the intended meaning.
> Is \input latex//*//file.tex (say) supposed to restrict the search
> just to the top level texmf/tex/latex subtree or does it search the
> whole tree, including texmf/tex/plain/* looking for a directory latex,
> and then looking below that for a file called file.tex?
The semantics would have to be specified explicitly. I prefer the former.
I don't think the latter would be useful.
> Personally I'd rather the whole notion be dropped, I am sure that some
> version of this idea would be useful, but it just seems too late in
> the day after months of discussions to be adding new ideas to the
> draft.
I brought this up in June... months ago.
> If it goes in I think it should not suggest any possible syntax and be
> suitably vague about sematics, something like ... if it were possible
> to restrict the search path to a subtree via the use of suitable TeX
> macros .....
That would be fine with me.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 Oct 1995 16:54:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 19 Oct 1995 17:54:19 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510192154.AA23256@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: .. in search paths
We recommend all implementations have default search paths that start
with the current directory (e.g., `\path|.|').
Maybe add the Knuth recommends including \path|..| as well?
He does? I wouldn't want to recommend that as a default for
implementations to provide.
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 Oct 1995 16:54:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 19 Oct 1995 17:54:22 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510192154.AA23288@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: about the committee
\section{About the Committee}
Yes, I agree with all your comments here. In fact, what would people
think of changing this appendix to be just a list of names, no
descriptions? I'm not sure it's worth the space. Also, I'd like to list
everyone who sent email (under a separate heading, so they aren't
besmirched with being part of the consensus), but I'd feel funny listing
just names for one group and the long-winded descriptions for others.
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 Oct 1995 16:54:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 19 Oct 1995 17:54:21 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510192154.AA23272@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: file format appendix
It might be a nice idae to flesh out this list and add a more verbose
description of what the individual file types are. If I had more time,
I might write up something, but not at the moment.
In the absence of anyone having the time, I'm dropping this
appendix. There's too many cases to deal with. Not all files with the
same extension go in the same place, and we'll end up describing every
extension on every system. And describing only *some* file extensions
seems guaranteed to frustrate and cause complaints.
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 Oct 1995 16:54:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 19 Oct 1995 17:54:20 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510192154.AA23264@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: texmf/tex/config
Is Babel a format?
No, it's a generic package, or was last time I asked this question :-).
Anyway, I thing the matter of config files may need
some clarifications.
1. Should \path{config} be reserved for config files that affect the base
format (and closely related packages) or should config files for
individual packages go here as well? (Take the example of tdsguide.cfg
if someone wanted to install tdsguidle.cls as a LaTeX package/bundle.)
2. Should \path{config} be reserved to local/user generated config files
while leaving distributed config files (like Babel's hyphen.cfg)
in the corresponding package directory? (Babel's configuration file
is language.dat, which for some reason doesn't have a .cfg extension.)
3. What about packages that may have arbitrary config files, such as
myletter.cls, which has a \usename{} feature to load config files
for individual letterheads.
4. Should \path{config} be restriced to the local tree if there is
a distinction?
All these are good questions. I don't know the answers. Here's a proposal:
1) we drop the explicit config/ directory;
2) config files as distributed with the package go wherever the rest of
the package goes (why did we separate them in the first place?).
3) locally-modified config files are ``local additions'' and treated as
such. No need for a separate directory.
I think this matches reality more closely than our current text.
Is the latex base distribution really supposed to provide a config/
directory for its .cfg files, as we currently imply? Or the local
installer create a config directory on their cdrom :-)?
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 Oct 1995 18:12:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 20 Oct 95 00:12:19 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9510192312.AA06787@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.100
Paul> Is that _useful_ semantics?
well there are thousands of documents out there that have
\input chapter1/file1.tex
\input chapter1/file2.tex
\input chapter2/file1.tex
where your typical thesis directory has subdirectories for each
chapter.
Your proposed semantics would send TeX looking in rather different
places for these files, although I suppose if it finds them in the end
it does not matter too much.
> I brought this up in June... months ago.
Yes sorry, Ive been a bit quiet on this list over the summer;-)
> That would be fine with me.
Any one else got a comment before this all gets shipped off to
tugboat:-)
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 19 Oct 1995 23:31:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 19 Oct 1995 17:54:21 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510192154.AA23280@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: tds font organizations
to find \path|cmr10.tfm|, {\TeX} would potentially have to search
^^^
through all the directories that contain \path|pk| files
^^
in all modes and at all resolutions.
I don't understand this. Is this a mix-up or something?
No, the mix-up is the point of this argument. If tfm/ and pk/ are under
supplier/, instead of the other way around, a stupid recursive search
for tfms would look at pk directories. I go into chapter and verse if
you really want.
(Personally, I find this argument totally unconvincing, and still think
the filetype/-first organization is no better in performance than
supplier/-first, but we've already achieved a (grudging :-) consensus,
so I'll shut up :-)
================================================================================
From owner-twg-tds@shsu.edu Fri, 20 Oct 1995 03:52:15 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <v02130500acad0c483ab0@[130.237.198.109]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Fri, 20 Oct 1995 09:52:10 +0100
To: twg-tds@shsu.edu
From: ozan@matematik.su.se (Ozan Öktem)
Reply-To: TWG-TDS@SHSU.edu
Subject: Questions and suggestions about TDS
CC: jans@insanus.matematik.su.se, ozan@insanus.matematik.su.se
Dear TDS-team,
First, I would like to thank you all for doing a great job. There is
really a need for a standard for TeX-files.
I have a small question about the TDS as described in the TWG-TDS 0.98.
The structure propsed in TDS does not keep all the various files for a
macro package at the same place. Thus, the files for a specifik
mackropackage are scattered in the TeX distribution and this problem is
addressed in TWG-TDS 0.98 (page 18). However, the problem of not having the
files of a macro package collected in one place is not so serious if there
is a reasonabel way to locate the different files. As an example, the
LAmS-TeX-package consists of typefaces and TeX-input files. Thus, according
to TDS the metafont files in that package would en up in
"texmf/metafont/lamstex", the 600dpi-pk-files in
"texmf/fonts/pk/ljfour/public/lamstex/600",
the tfm-files in "texmf/fonts/tfm/lamstex" and the TeX-input files in
"texmf/lamstex/base". Finally, the sourcefiles for LAmS-TeX would en up in
"texmf/source". In this case the problem that the files in the
LAmS-TeX-package are scattered is not that big, since one can locate all
files belonging to LAmS-TeX easily.
Now to my question. Macro packages that contain bst-files would cause
problems. In TWG-TDS 0.98, there is no further subdivision of the
"texmf/bst" and "texmf/bib" directories. Why? Is it not reasonabel that the
"texmf/bst"-directory is subdivided as "texmf/bibtex/bst/package", or
something similar? This is the way you have treated all other directories
containing files needed for the TeX-installation, such as "texmf/metafont",
"texmf/tex" and "texmf/fonts".
Finally, the TDS is a structure designed the an working installation of
TeX. Thus it is not suitable for archiving purposes. The CTAN-structure
however, is quit good for archiving purposes, since all files related to a
macro pckage are collected in one place. Would it be a good idea to use the
CTAN-structure for the "texmf/source"-directory?
Yours sincerely,
Ozan
______________________________________________________________________
Ozan Öktem Phone: ++46-8 16 49 15
Department of Mathematics Fax: ++46-8 612 67 17
Stockholm University e-mail: ozan@matematik.su.se
S-106 91 Stockholm url: http://www.matematik.su.se/user?ozan
Sweden
______________________________________________________________________
================================================================================
From owner-twg-tds@shsu.edu Fri, 20 Oct 1995 05:04:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 20 Oct 1995 11:00:06 +0100
Message-ID: <9510201000.AA01061@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: .. in search paths
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
> We recommend all implementations have default search paths that start
> with the current directory (e.g., `\path|.|').
> Maybe add the Knuth recommends including \path|..| as well?
> He does? I wouldn't want to recommend that as a default for
> implementations to provide.
Yes, I remember someone told us that he suggested that after the TDS
presentation at the last TUG meeting. The reasoning was that you could
put a test version of a file in a subdirectory and run TeX (or whatever)
there without clobbering the previous version while still finding all
other related input files when searching \path|..|
People may have different opinions whether this is useful or not, but
it was told that this was his feedback on the TDS.
- Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Fri, 20 Oct 1995 05:12:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 20 Oct 1995 11:10:20 +0100
Message-ID: <9510201010.AA01075@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/tex/config
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
> All these are good questions. I don't know the answers. Here's a proposal:
> 1) we drop the explicit config/ directory;
> 2) config files as distributed with the package go wherever the rest of
> the package goes (why did we separate them in the first place?).
> 3) locally-modified config files are ``local additions'' and treated as
> such. No need for a separate directory.
> I think this matches reality more closely than our current text.
> Is the latex base distribution really supposed to provide a config/
> directory for its .cfg files, as we currently imply? Or the local
> installer create a config directory on their cdrom :-)?
Well, maybe I wouldn't go as far as dropping config/ completely.
Perhaps we could reserve config/ as a special case of local/ which is
intended only for locally-modified as opposed to other local packages.
At least the teTeX distribution contains a couple of sample config
files to help people get going without much fuss and I think it's
good that they are collected in one place in a config/ directory.
- Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Fri, 20 Oct 1995 05:38:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 20 Oct 1995 11:34:36 +0100
Message-ID: <9510201034.AA01090@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: jans@insanus.matematik.su.se, ozan@insanus.matematik.su.se
Subject: Re: Questions and suggestions about TDS
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
> Dear TDS-team,
> First, I would like to thank you all for doing a great job. There is
> really a need for a standard for TeX-files.
> Now to my question. Macro packages that contain bst-files would cause
> problems. In TWG-TDS 0.98, there is no further subdivision of the
> "texmf/bst" and "texmf/bib" directories. Why? Is it not reasonabel that the
> "texmf/bst"-directory is subdivided as "texmf/bibtex/bst/package", or
> something similar? This is the way you have treated all other directories
> containing files needed for the TeX-installation, such as "texmf/metafont",
> "texmf/tex" and "texmf/fonts".
I like this idea of introducing a package subdivision below texmf/bibtex/bst.
(Actually, some BibTeX packages put related macro definitions in .bib files,
e.g. mrabbrev.bib from amslatex, so the same applies for texmf/bibtex/bib.)
I guess the need for a subdivision wasn't that much apparent as in the case
of texmf/tex, but it's true that it would be better not to throw packages
from various sources all in one directory. The only problem that might
occur is that various BibTeX database handling software might not be up
to path searching yet as it is the case with BibTeX itself.
> Finally, the TDS is a structure designed the an working installation of
> TeX. Thus it is not suitable for archiving purposes. The CTAN-structure
> however, is quit good for archiving purposes, since all files related to a
> macro pckage are collected in one place. Would it be a good idea to use the
> CTAN-structure for the "texmf/source"-directory?
I'm not sure about this. Personally, I tend to follow the layout of texmf/tex
where possible, e.g. texmf/source/latex/package whether or not it is located
on CTAN in macros/latex/base, macros/latex/packages or macros/latex/contrib.
This means that I can find all related files of a specific package in
texmf/{source,tex,src}/{latex,generic}/package or simply texmf/*/*/package.
I think this is more useful than exactly following the CTAN layout.
> Yours sincerely,
>
> Ozan
Thanks for your feedback. Concerning texmf/bibtex, I think you brought up
a good idea that we have missed so far.
Cheers,
Ulrik Vieth.
================================================================================
From owner-twg-tds@shsu.edu Fri, 20 Oct 1995 08:11: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: <199510201301.OAA20255@spock.iti.informatik.th-darmstadt.de>
Subject: Re: texmf/tex/config
To: TWG-TDS@SHSU.edu
Date: Fri, 20 Oct 1995 14:01:48 +0100 (MEZ)
Content-Type: text
Ulrik and Karl wrote:
>
> Anyway, I thing the matter of config files may need
> some clarifications.
>
> 1. Should \path{config} be reserved for config files that affect the base
> format (and closely related packages) or should config files for
> individual packages go here as well? (Take the example of tdsguide.cfg
> if someone wanted to install tdsguidle.cls as a LaTeX package/bundle.)
config/ is for configuration files installed by a system
administrator. It is intended to serve as a place for files that will
most probably remain stable over updates of the actual package.
E.g., take language.dat from babel, or graphics.cfg: When a new
release is distributed, one can throw away all respective directories
and just install the new version. With config files lumped in the
actual directories one has first to remember which files one has
adapted a few months ago, and then save these files and restore them.
I.e., config/ is needed for the TeX administrator of a running system.
With it, package directories are less likely to have changed or
site-specific files.
> 2. Should \path{config} be reserved to local/user generated config files
> while leaving distributed config files (like Babel's hyphen.cfg)
> in the corresponding package directory? (Babel's configuration file
> is language.dat, which for some reason doesn't have a .cfg extension.)
That is exactly the purpose. lthyphen.cfg is not changed and is
therefore not placed in config/.
> 3. What about packages that may have arbitrary config files, such as
> myletter.cls, which has a \usename{} feature to load config files
> for individual letterheads.
As long as the config files are locally generated, they should be
placed in config/. (All of them: It's a Good Thing to know what one
has changed in distributions.)
> 4. Should \path{config} be restriced to the local tree if there is
> a distinction?
I don't understand this question.
> All these are good questions. I don't know the answers.
Yes, almost. I tried to provided them as far as I've understood the
questions. ;-)
> Here's a proposal:
>
> 1) we drop the explicit config/ directory;
Please not. It's a hassle to remember months later which files were
changed/adapted in an installation and which ones weren't.
> 2) config files as distributed with the package go wherever the rest of
> the package goes (why did we separate them in the first place?).
Yes, as long as they are not changed. (We didn't separate them. :-)
> 3) locally-modified config files are ``local additions'' and treated as
> such. No need for a separate directory.
It's clear that there is a similarity between config/ and local/,
both directories concern locally created (site-specific) files. But
then, I've never really understood what local/ is for, I put local
macros in proper TDS directories.
If one adds an explicit hint to local/ that this is the place to
store site-specific (adapted) configuration files, dropping config/
is fine with me. Otherwise I'm against dropping -- I think we need a
specific location for such files.
Cheers,
Joachim
PS: I'm away until Tuesday, don't await fast responses from me. Karl,
I'll send you the TOC changes then.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 20 Oct 1995 16:20:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 20 Oct 1995 17:20:23 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510202120.AA08589@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: .bib/.bst package subdirectories
I guess the need for a subdivision wasn't that much apparent as in the case
of texmf/tex, but it's true that it would be better not to throw packages
from various sources all in one directory.
Is it worth it? The thing is, unlike macro packages, .bib and .bst files
are generally independent, and also often not released as a unit.
I don't know. I suppose it's more consistent. I haven't made this change
in the current draft, but I'm not opposed to the idea.
The only problem that might
occur is that various BibTeX database handling software might not be up
to path searching yet as it is the case with BibTeX itself.
I don't think that's sufficient reason.
================================================================================
From owner-twg-tds@shsu.edu Fri, 20 Oct 1995 16:21:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 20 Oct 1995 17:20:23 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510202120.AA08581@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/tex/config
At least the teTeX distribution contains a couple of sample config
files to help people get going without much fuss and I think it's
good that they are collected in one place in a config/ directory.
They should go somewhere else. If a distribution supplies them, they're
a distribution file, not a locally-created file!
I'm confused about the whole thing. Do graphics and babel *require* a
config file, and yet do not supply a decent generic one to start from?
I'm guessing they're like LaTeX, and supply a config file a site can
change or not, and tetex does ... what?
As long as the config files are locally generated, they should be
placed in config/. (All of them: It's a Good Thing to know what one
has changed in distributions.)
I agree.
Please not. It's a hassle to remember months later which files were
changed/adapted in an installation and which ones weren't.
Right. Plus the CD-ROM argument.
If one adds an explicit hint to local/ that this is the place to
store site-specific (adapted) configuration files, dropping config/
is fine with me.
I've done this. I see no reason for two different site-specific directories.
================================================================================
From owner-twg-tds@shsu.edu Fri, 20 Oct 1995 16:21:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 20 Oct 1995 17:20:26 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510202120.AA08614@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: tds 0.101
Draft 0.101 of the TDS is in the now-usual place:
ftp.cs.umb.edu:/private/tex/tds/. I'll append a gzipped shar (modulo the
dvi), since it's pretty small. I think I've incorporated all the changes
we've been discussing, except for the proposed bibtex substructure.
Barbara/Sebastian, when is the deadline for TUG?
I've omitted the Martian example section, the short-lived file format
section, and a list of additional contributors. (I want to put that last
back, but it wasn't worth the extra page for this draft. There are some
other infelicities in the page breaks.)
#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.1).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1995-10-20 16:54 EDT by <karl@fosse>.
# Source directory was `/u/w/tds'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode name
# ------ ---------- ------------------------------------------
# 4217 -rw-rw-rw- tds.aux
# 60376 -r--r--r-- tds.tex
# 2872 -rw-rw-rw- tds.toc
# 18960 -rw-r--r-- tdsguide.cls
# 5860 -rw-rw-r-- fancyheadings.sty
# 1766 -rw-rw-r-- mflogo.sty
# 14216 -rw-rw-r-- path.sty
# 2180 -rw-rw-r-- Ulogo.fd
#
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
shar_touch=touch
else
shar_touch=:
echo
echo 'WARNING: not restoring timestamps. Consider getting and'
echo "installing GNU \`touch', distributed in GNU File Utilities..."
echo
fi
rm -f 1231235999 $$.touch
#
# ============= tds.aux ==============
if test -f 'tds.aux' && test X"$1" != X"-c"; then
echo 'x - skipping tds.aux (file already exists)'
else
echo 'x - extracting tds.aux (gzipped)'
sed 's/^X//' << 'SHAR_EOF' | uudecode &&
begin 600 _shargzi.tmp
M'XL(`)0*B#`"`ZU7VU+;,!!][U?H!\)@.PFT+X5<Z&0&"D-,X<$OLKT!36W)
M(\DEU*-_[UIVPL4&4CN3ER2[>\[>I%T%$A*Z)E^"DT?)-*Q8`H46D2F"2'`-
M7*N$<2"%@D@SP?%_GJ<AR.I?QRRXEB+.:Z%GS.=(>?@.V(%C_`<@UR(!(E9$
MX_<BT+$ZD8`,$)\H]A<("?(L`QE1A6)_MC2F-Z]KIH+_0544JAW16J%<\P,X
M2)J88MC')1=3L<S#F$D4"_E$ED!E],#X?0W,X3&A(22E']_>T[0P?1VQN5%:
M4H;:;>ROQ-9@9\H/6-'STR1[0!;-(C(MB\TX.4,T3E-`IM$>.%QSB4TFM[#D
M52RC?HGSS+40&@MA&]F7`*88]X,<FG,1T82<QC&K>W7<J$=#Q1KVI1Z969XE
M+*(:7E;AJ$'?JF8!*N5.Y\HSOL@&Y_`'$C*K6YUM^;M&Y6&37=!("@0Z;@2R
MD5BU2MZ=R#5GPC;5UP9/+;!*E;A'5WOVY)209,)T2C-$=@[W`.J:7S1A,7D#
M[33":5.K$6KU[EGTS$_!!ZL2NP@R#6N=B'M!BHNY?VJ"F*E(0FE(\1XL!J;`
MSTNUL\N?OC&V+]M]WZ)?G&VT+&MOQ_'\=?#WZG+IE]/-<9O-"9I>":6M@\.-
M2G<'\71.@M\@.1D<'(X@K>:N2JN)NYB8K?`84G_SPQF/CR`-$O&(E^C!"-;!
M0RC6I)AOU1T7P>X"E=$(5K0\MB0X24E[4!,6^G!G0QKU#VEL9B+*4]2EE;R%
M\8V&M=J1N)5UB%,[3;&<B-)K[@[Q%+]RS@X0\HP^^CB6-^H6KS;J%-BIN>$J
M@XBM&,3DBD%DCU!WP(E9I%D"SPXOE,HM9J]!-2GWAEAD%O+_=LB^Q*ZY$!(7
M5T[>V\><YK3\S,3BUH;=7?/,?$W+=)/721\LJY)&MEW*Y#?'X(Z6EJ6V[S%J
M$`4K>`NA&Y&C@\,](;KF*@]Q*R&S^?1FB17?RP5VW+GYIV:A"#YUL/:43$!K
M9+^E3]\1]&N?2D\W"PU9:HEOLEQ"?\AJ=>F$^`'H9DLIQRSQGS(@Y=Y:7]3[
MP"^/8XSYY3&Y!B62W%X)SR3NX1Y(/$N"BX)Z7G9V!GX'U7MS\;](O.MT;KF9
JN<:'OH8R&RML/&XO<+>Y`[6IH74?[GGYA-22A3D>GPWK/T/[KKIY$```
`
end
SHAR_EOF
echo 'gunzipping file tds.aux' &&
gzip -d < _shargzi.tmp > 'tds.aux' && rm -f _shargzi.tmp &&
$shar_touch -am 1020164695 'tds.aux' &&
chmod 0666 'tds.aux' ||
echo 'restore of tds.aux failed'
shar_count="`wc -c < 'tds.aux'`"
test 4217 -eq "$shar_count" ||
echo "tds.aux: original size 4217, current size $shar_count"
fi
# ============= tds.tex ==============
if test -f 'tds.tex' && test X"$1" != X"-c"; then
echo 'x - skipping tds.tex (file already exists)'
else
echo 'x - extracting tds.tex (gzipped)'
sed 's/^X//' << 'SHAR_EOF' | uudecode &&
begin 600 _shargzi.tmp
M'XL(`&L,B#`"`WQ;77/;.+)]QZ_`RY3M*DE.)C.9G>3E.I^3VGR5X\Q,W=56
M!2(AB1N*Y!"D98VM^]OOZ6X`!"5[\Q);(H%&?YP^W0W/\SKK-[;JLM(X]Z^\
M-<ONW[==[E9]D=N]^F$^>N"V[&[B-[VSC<F^FY6]-679=0>?-:9;XZ/19YME
M6:_J@P?3W2[M7WW1VL_#5YU9E/A*J1_TPJZ*2B_J^KN:N[IO,[LL2GM+'Q35
MLIZYU6:OYLNZW9BNL^WXR\[>[$=KT*=JCAU^MZTKZNKVT>SQH\?[>5=T>._V
M0K^"(%E7MSO]I6O[K.M;J[&XOIU?V3_W^@V6=_OYW+^NY]W:)LM!$M-WZ[J]
MO?KZ5O]1M]API=^V==]H/&W",O?M<GKUQ]OIU:LO9UB$!;X-5L`'&_/=LHSA
MN]*N3%G579&1GJ[6A=.NL5FQ+#+3D60;L\.Y=6N7MFUMKKM:&Z<AKO[V;6X6
MB_:VVZZF$%T=GN'D1./`!T_1IZ0'A\-U$WK@/[WK5'Q*GMBN;<5[9'4%W7>:
MY':ZZ'166M/B^R);>R6H/"K!127@&!MKJFZFU,NZV;7%:MWA^2S\O->/?_WU
MIXG^]6>]V/%.7J-?':073>-=]=FVF\*QB7!P^-U$TQH3;:I<YP4V+!9]9[$"
M=@QZY@.::J>:OFUJ9_7<;IJU<86[W1:P:H_SU'E4\9X7"]\L+4FOUK:UD&S5
MXA`VG^BFK:_AYM#_VG2RG5A-FZ:!2J`<^$59DGB%=3/UKB,EQ->^?8/5"D>Z
M]1O9FZ:USN$[2%MLFK*PN=J:EG;<\=FA:@CO+*3[J[>.9'7TL.M7J_`K9+0;
M4Y10CYJ7!2+'E,'6_^/6KI_9O-_36W@2RNA,J?WS\_D_35OJ%_"KG3[7CY_\
MK%]">[95OQ4XR&5M<GS\N=QM(.YZHC]<Z$<_/GGZ"!]^_7(QTW]8O;5E5F^L
M/_B&E(^CBQM':^!G<XTM"0LX>JJ=%F_+.@/MKR&5.KV`&JN\N/F_.5S]UMGL
MV:4M#72O+\GU;94A8#6LB.C#5DUI.Q\5]-49=IWC_7$\_:!)=P->5';;`)D0
M*21+O63OALC)-PDT%577WH]+\@V#TAR2DB5NW]%G><^_()*].]/9H?8M7NS+
MB5Z6]J8@-72[QCK;=00K;N<ZNR'GSB48ZM[!(V'JI6ILC9-J@WBH<HZ3;=V6
M^4QK\2_$9FLWMB3;MGPJ=N:V)T^I]'71=CV,LU-DH;J!=R1;.BSSJ;*ZAW+P
M7`5M:P=OU7:YQ*FPOX_*$Z=$\@(>MJ-]?118"?6JQGO5JB1,XO`F-P=N(62+
MBERN!'3,Q"W(@O#[OB33%H1O<`<'QZ6OKDDX1"9;M0LOXT$.BY4=',PBM(J-
M@>>&((>TW:'?08#<N@P@`;T`GJ`;T^8!N.Y';R`W`\C&9&WM8#,XB1/`(?W7
M=&I%\<K2,(),BRJWY+ZTK;<\.0HI^((\0'R'1&Q:`Q?)#"ERHL8"F]+5(;@=
M*=")!K,:)VP-PQSYO.ODL`$T%>^%!RDW!$M$+!9?(;4O+%`=^BA6E202^-)W
MCLBR5$!$VU:)9[RK=&-:R-J7IIV(;J]LMJY(^H.<2#GO3"TL,.Q:\@0>AA>3
M/\)Q<?2O57$S\6&_<=.\=ON)_@-ZJ[?.?XP$.5'R8^W.?\3W'TPFOW_ZLA<+
MR*_7&[>'A`"@-7Q:G-'DFZ*BA&!@44</JQS"E.3T%$J`@6ZMEZV5"&&T:K,"
M1QG;T@UN#ZB&8DQ>-Q[Q@P/=!W$%00DAO>P#!TJRF@_QD8R:A%;D^2P0O>&C
M'7D!FB?M^M=CHB/YIM,ISM7N(!&>6+8UUE4#(O95Q6KW6Z8NP1[-":3;X5?R
MFAGY!E$,\CTDO;()>_:<B)>%N'W1<D!['/).@J56IBK^YJQ8L,>RLRE)CA-8
M9TNBPG2ZZW%D:/L9<H:N+,#<X8C`+1!3Z%!_K^HM`GUE@VMO.('#`=D@AGTU
M48F(`/&7>E?W$(QAS&R`4,1/D&,YS\AB"FD8F9PEYF-KP7-'PG`.@9Z(652$
M2_K!5*225$09>N[Z1<!_@J3+NHSRBZ<"3?9[AJOVWN\\2!%1AN1_2X1[M0K_
MB]XX;7T^=/6R`T_`J81H>S0F%22`63&Z,F,"/#IDG1V%^@8'+-C)L!AIP<$%
MZ4-36>2=DBRHU`5X4-$"9U:EP6DG%-'D)<Z22WGLUR_A=*T%573%=73UBS9;
MXU?UT78,+Z=)JC^#D/PM'*LOE\0R3K$6\9SNC-$FHCBI:Z+A\H*1XE%"24&*
M(&2JTY1->(4RH5KN_(9P'#5BC-#LA%?T&A-=TR/0&$P+\%L"J">"N#7!Z['M
M!D"2K<D"`!APM:J#MHL*85DMRX+6`?R2GQ*BD!:U+9W=2OZLQGD+9WL#-QV)
MJHKNQ,6PX<2*B%\4E<1)DC*96)"L]^0$U5=%]YR1AOU"8!IHE!>TBRE9<W;5
M@D-UUJ]PB@BN2)\@<!(\[DP)Z@1<\7XHFU%I2+D*M44&4_&ZY8Z/`V([T:%:
M8)*<!M#+NL).#'%[2CXCI4RHCJ&B].[\#N2"LPOG,!7V8]$JL[',#NN*F(*<
MU=X8`D=D'UX`M&VS/.>L?L=^Q.ZER+:4I`@%O!SD?FQS<"+BG6(LD!V"0GIV
M&DHU\9@CB3U[.M$K6Q$QAQZH*G+'J6%":;[L<W+4V_F'-_L@[:O?W]WIO$7,
MM"`A\`80!ZANHFV7S<2%J8!+V8`'.YC7V7+IV1)BD8H0;RI2X8&\S!#P"A3;
M4XT`.2',,[*RI;!4`7[$+8;:*Y\,L"-)&O4%DFE!)(/I.KE=HNFA&H/T>RZF
MWQM(;O?!DR:^P&3V/"0K<*/&IVH.Z$%V[F_@I&`$\`M6QK(NRWI+&0,A00II
ML&1B7/<LEN?,$!LA[G/DX\V_YBCJ2E\>WGI][O^M/GO-DIN)/W@>3]HLH((B
M(Z>6)4(QYO_'Z^_E)\T5M>MQ0*@G/A?\=T_I,UF7?MRV]!#_&-<'22A-9BG9
MWR8_8Y_+X;>#O=)WO*[A:07Q5H`E*<N(+LG@3##@:0^*4R_*`F`WD\IKK,:T
MQ0-;0R_W-GCDJW$E]5:");9#Y.-(Y!US-WP`NX#;433`X"`F*RZK#S`:Y1'A
M>0HT7_K%T++X8CE#5"L(@`K5EISO'WI$?2"T#;5=DCJ(&];P!V`D@+#J-PO/
M.L=14U0!BE,8%,"/,$7ED@3_U9L/=\.;$6^C:)S3Z/$H44,=#,%M'U7[)(!@
MS,\E`C-4IT((_3<$*&>\3\4USM%N@?5"]S6<EL(I*<OTFHH@')JC'YX,WB#,
M;01TSQ`GY."4L:BTZ*1&ZZC/@VRV)6XA!V!*YVMB@8/`=R;\F*]Z*BNU#"J\
MOLE9U]R],OAFJZ]]?X\)>@2INDTV4@Y^4^:T0&Z)0X,XD=@QJU&]NJFO[5!U
M<Z$&<["/TR%MV]8H"L$0MDRP-^0+D9ZMJ47$#2Q4N'9D)2:JY+*.,A>%O^`U
MB">6F*3>_,=;%)46"K-FT(4>A"?+#=EPL)I^@=V8YV;U*K!UP_TGX%5!3*4$
MF'/PH]Q)'-.KU;'_DU[#5GVUP&>$(D+$6LO6RNN_;25MBW!TPZ4]<\=MX=9)
M1X!+8VHV$)>`(_MZAGC1)`K$@GJ&,X@E<H`ULN$I4IR4"VGK1&=K0[4VN619
M5RM8'<ZP##D!>AV:4@[R<FO*U1NK0@D,&@P[3]@;$&.I!'3:`_TE>9`V@!.P
MU[!:%;EBL)A(3_F51*Q6@KIT"H+HK<56QCVP%+,4'(HR=&@P<$Q&TZ#2*C9V
MRJ7,AI<&1+![3H&7E56^"43\EYD=>^!A"<QZ][U+5HHVOO=#C(M)CW1M#[Q%
M7(4J6]2A)(@^9;><BTXI<=V^_OC[N\M/'W^_N-S?7KW^\]W'SU^O`-2VNBX@
M($/)-4I#Z1:VY$'\+G/I8M6+\'SZ24KOSKB9%4O3T&7U<HS?9NHK*FME9L'1
ML6D*5G@HL(C-,*DM+3N[6O0M4B4Y!GFV=+&.8A0[$9,+82;=RJ%,&G*3\GO[
M!Q]N0VR(X!'WJ5$@L34HBU*<<94#'\2W2<)R(6%!)1\8B?!-`3*XFQSM0FLK
MZNZ32GRA:-F4T<HF]+0FVE-3$YL"=#80Q;I2D9H&)^!)#3EU&&C8?$`EZ5+:
MK&])*>4N9'#N4R:'*4+A!2&&EQG@2V[KKGRS/T'5F3K]Q`F,RUMZ_7[MC-Q'
M16&F73U%H$Q+ZAX%\$/."5T2BK+0UD?"I"Z4K3*D`NH?1_52#XK`*<30O1)P
M]<L5?Q-J?>I6A$S5AH*TE8XDZ8;1SG/ZA.;DM94*.9B-P@9&OI%ACWQ(.\9C
MJD0/"\D0\1CZH6-09F?6Y>%`<0D+7!U<YY2JVR]"M88&"KLA3I@2*S40J[,#
MBH9:D+IDV,Z->-GH\]^D76RRS#:=E>ZLE,@$5'SN!^P^CEC5]2W5*E3\$#65
MVJ\BXHRC"Q?*AHTU4^B<3C/FFC,VRO'S`#/4)`N;&:I-J)-"\4Q>E(0;OE('
MU-6/2D*C)G8)1]U`>DK>>?EJ>OGIPSYH<E#F18ER:V$[\+67-%!"8+[QM88+
ME)8\@-SGWC$![4@]@3;WF$_)64@YEMU:B^@'PVFG+&))TPYJTB!#=YQ^BRH6
MY\YW;FY%YG=?/NVGOSY]^FCO.W+J--!\RF98ZFQP;4,%G=X4-S:?\OJRX&$L
MI&U'>L.EKXSED,82U<\,3RK8B$.R`BJ%2H,LKJ5=<[@_M3GZ5@BFBIR;V@LZ
M5$2^Z>B'"/&9>+#62F^.%S4E96DBQ<*!>J)-!E(P:?%'$/%[K.A?FP(S*,%T
ME&+HB<!B)IRH>'S(SB.%Q:>KQ]FFG2WS.^E($<N#R1V#](+0@]>0A^LN/GR:
MKO#RP^7LS:L[2KSD5].Q`#H*@.00!R=@P!5U"7@:3ZWD30W!1,U00CHK$'4C
M(7]'Q6<J1?1-AHWP5QJ"M$66L!6F9`1@!%$VC^W9(0XD*037UR,L43P'<_=U
M:(."AML#L1-[&(EJ'(EZ')G2OB@H(GC-K:FZ$/H/Q4,*&X4;'+.ON"/$+24!
M0"8HB>+#`FST5`SWG!;C3$;`![G[SC-]XU14[+65>P980JHO;J<?0$-@)2[4
M`;%J46F?-*>O.)&<<6H8[2F32@1,Z9ND<'2$.UL^Z@GU,6()+&]W!"$X>H
M)6H;W\!19&5_1R#@/T=K:/KZ7IM.2XN=D'#F!!WY,@Q*/6E)_?2>O<FHVK1\
MFV&H+PARXZX""O0&%WNQ:(]K0E6OP\_N8&D$"@VHDJ63*R;#RO2"K%XEZP8I
M/DIWBGC_>!]*2H4,#X<>'+G3GBV6%$RQ*76QGT[C+_]+\[GPRZ/TFU\]*>3X
M=5E-4\<'&$I@O6S\*/.%AF<5=1[;Q][H(5BYX4Q"IFH,Q3A/2NDR!;==N:HI
MA$GQNZE!^6(*72B![=6IG:UFH='ZYMW[UQ\O/KR>W85/9J__O")T>XAJ/7"0
MT'*0)M!$M[[&XR,\GDZ?_/C+TU^XJ\8(J#P%I)L*'GPXBJ/(DZ@3#\T.GI[5
M2!,/G0!R/W_,N'QZE0Q/8KD1*0-7(4EJPH-#IYI>\4J%7?&,AY^'($#Y@U/=
M<1;4\8G`2N)E"#-FUE)$<X:6TCFTOVF3KFX\_S[=,*+G9VE'P^<^)B/6-H`L
M=6W*(D_-Q+%<#%U>?\M-NO_O?SQ__^3\_4_G[W\^?__T_/TOY^__<?[FTZ?9
MBXO+YX_58TW_?M3ZB=8_:?VSUD^U_D7K?TBGTR^EU&_^_D,B2"I"[.@)@%*G
MR@E\.W92T</]$O)\XKSY?I[=G#?]`E7>>;8YSYOBR:-'^*E]_&C6?!\$U4%6
M^A?E'8O+OT2<5%\HER8,#R2'O$MN1MD\Y`\N0P^!6;`4=6/32-\H,LP$1`#W
MD0M.AF[(.#YD4D]YF$MO00'?C?04;2"`<BU%LD$0SI.P*F'/(=_&`<BHMKBL
MZRZT@*Z`MGOEY[-U=T_V'_IK)O%@NC@$YL#=&=A3'?`"B&9IV`WX/AX+;:EI
MQPTEOHEA_.VUY!K=M]LY.\'^1)\N^0J?;P0(?40)?G)R)A'K^WIT\XHJ18D?
M*(:!3QA4J#(F<9SE&T@"CLM1'X<O]_0-M7EX\!4JT1GU5D0M30;[RW#73<8#
M-CYI)OTMT_#=`U76*[XPPC.L@[N-82[A1WM7S^Y.8*TO,FND;@7)4-:9&:IC
M;AT'67T)YH&H<'R;8AJOXDB*\!<H/<RF9D[8TG-:BWCGP)O]N+%W[3F)4)[#
M:JV]._[B;J*.GBV+Q9V_L2)?H<*_8\3S)46VKHLL5B]LBF!U$$-'WP-YI8JE
M8@8:;*UQQ'F(OH%IE5""SY(PJ(I3^2,O=;[73,,2[[1D&5`'5+KMP2!2G0[D
MR'=[\-]G_N]%L9`V$(\*DN%C&#]PO$DFD29_&`E=^U$`9Q>@Q&CJCG1"Q!P'
MJ+@1&NX<'5RR.HSC]Z1H?9'+\'K<)SCZ[K!?@H(B[9;$!EF8'23-_[H-"=2H
M;]_8O&"TLO+)R4R_IG:\=+E)%\,L@YT5Y+QN<Z]SZ9G5VTIQ+O#7[^1=SI&A
M1\Y,C4HASA;!5ST=SSBVBV[-(3KHZ[[;0O3N+KD6(CS_V[<*"]-)3DZ>JV'>
M$^48XJ5&<N<O$GY"?E54?;\)11IC8"+AEB<"F5P]U.$:5A[6%!W&FT\4%40,
MDY&R7(\(<P6O]9,3F?#&009/6WP\;6RW1N+@@!G;R,D=J&1U%2.-IX/Z!;4I
MF4^+@;C<?\YM"[X#PBU7N:)(8`+J7-8[Q<W-\=V9H1RQR&[$DRB[,!/2%_'6
M*N=_/Z8A`29);6-&N2=<X5,26?=>9TA`A^\(WMQQ1CWZDD]\-QO$&5=&>0!A
M@;03OIV&X@@9OJT;)+/."E^9T;!2)9!OQV-ER<QT?^'^83,+EWX5JN+]:)@`
M<V4]WXXNJH/ZSP.`FQT&=1<J4&H/V/;:%Q'C@^KTF*10N6#D;Y$.'I:DU*-7
MV!FF)C?<=SP>3(`:Q9&[O(H:H,?Y9[GI[N+EP!>$5Q%J8FO%WU5PLVRYNE/A
MX?!I>![@\;6*9.T>&?S5P/!\&'.V=%V\"EH-FR?D^FHM?=YX@S8XJV(%E+MI
MW!6B33.DI6'`S7N.`,B7%UB';K.K9*Y%0S$P)OK8A>O;:=P0-H9L::0U<QC9
ME&-VL&HA@DGQ$J5!HJ+RR,?"YW_>R5W>\!<'\O$'\]T"-NE;258X58$0]O66
M&ET%>75=-'SU]&*8:\K@GTTTWMXK56Z"R67$HW[%U/W56_OW`!."0/&F<B0_
MWEYLNX/K#?H4U2[]:8:A?BQ(>0Y1RGK!X`OKY.=\7^,,'*<-V_"8'[P=N0HG
MI?Q\L%/1/K#7,HU^Z=<=W:LZ[S;-W=GSL!EE4+Z^@+"2J[=R5_5H;</-J%)N
M#BWJ:Y+Y8!%28^BPHX8JR$V'`#\%QUF;QC%D2VYB$0,<7IOV+OZIP+$)/M9(
M933P+,5W0^LO!<$PB.%\0+GAH&)0!]3"'!OSD,F\ZL7#;-J73]C,O=^K5_'.
MGWB;]^IXD4!RU0TU?%C[B8B2]MZ&4G]R6/0@)@D\^VJ8W$D)6\L-A["A&F_H
MC<S3/RZ_A]8IK/!<KM)M8C116/CK\#;]FP(A/?[O!P`0-`K>R4UD,,B"*F=F
M[M([),]'M>*;;7U%-Y+D(H7F"I<::XV@A:209#X@ASKH5OHVB3L>BM>AUS$[
M;CMZ+Y7>VS"Z3>]ZA+&/EU%.2?=HJG`NQ9=NP^0Q'5Y1RRZ)LH,T'S\\]P3[
M#NQE9F>3Y&)H^+,$?_$Y-BCE#LRA\\STZ?$,C_\@8A]3L_/]V[ZE@*2>3]("
M'OXD1'8<_8D$.\>H%)S$6M`,D]C@2ZQJKEO@($=J2(:;E1_7I9=8:&6Z:L0S
MDR]<]XP-*W;Q$T[EI?UOLF))J$N&!0<%\+:EJSZMDDS"M<,]F9D:<Q?E\1\>
M;.4:/)=*)0'W3GE62F6U:?S0-7;7-(_N>-04;A-AU4!DD\`<M0E#\^CN;*+,
M`=$ZLOGOW%9[0UN\*#H4]9+]#G6H-OX.JN=?!+^(LM$,*YE>D?[^O[AO;8[<
M.++]+/P*;(3W#NEH-C7:\-U=2M=>SDL>RR--S(PD;Y@3*W0WFH39#?0"W>30
M(O7;;YY\5&4!:`XMV6%]T;`!%`KUR,K'R9/(-^$E3%M-Y2TMNM-S.G0$`O?Q
MT<G#Z/"0I.XM:`\^;K<(0C2B-U?5)6,/FAC$ZX-3ZRP(D)-]NSYSNYXLYA2&
MAS,--I0:7SR(HH<<]B1"9L(`,=CE*%H9.3DJ,=7;(@EF;4.:]-J,0F1#,82F
MEN0)X/1W`&R^DAP?$7OJ'<B[%4R^U8WS_+%($*M`>K'9U?/ME.P'6T2DYA7U
M2GZ!#=?AY.24P&5)LLND>+8D[8Y#W.%,M9PQ1NBKB.=%*D[4MKHJ0@Q1$6B9
MC,]T,,<1,_JNV1S]D<7FL[CUU>SW9H4H+`*65AN0/4(&@54EZR^DY$08^0B,
M,54!FW4EUM*NAF%/%F:"<L].5P`CG5_TSUG:!@`=D`:&U#/H;SV'1%`9.AU.
M317=DWJF6N]U8B,SMLC\>"SX,P:9F:]!-HDH53+H,DC12/;I%#&#"=L^24-3
M8[;D;V#E4_32JO.(</IF2`?H64WP^V3.C9<D2:5Q15/\.5/!(@1NJ#/U]6G8
M0IUKH[<Z4)*9`RY@V9;WHL-M9]Z^SUQ.N6[X?>?FH=G>^KSL:6D!_SY*H<+#
M=B"%A\VLRVV!Q[6E@YK6!/X^5&&TK[6O];[\U0O-AA]K&1G#X2M?O;[G(^GF
MUW3SH)59-?,CI3[$O>WH]7XKBV:N30`.%;SI<J@.6WGFKP\:$]RNMB=_1#R(
M@/<ZP:[YW!A-`\CT`7'-1V>,-Q._+V>?S>^LZ?P<H-=$59,KQ]>X[_8PA87H
M!V])M8GO&GEXQ<Z>0_6"Q(=T#W<2PG%P$V^5J_`7)Y;(/$#![7V6[)J.LUXU
MH^<FSW"(7M+I:.9I,KX!>Y_\Z%,EEX:,,8B!>`)S$:(>1CJ[R1SR7J>"@0SJ
MUL!C#()6[*7:BLX:Z3FN]&`#''[*>F0(,P%W1,KDT+;53YAD'+U3D2X"KLA_
M^$'AX/@@RZ_A['UQ74C+G-^,0X[."/'/U%'R2H1&W>&PO7O*/7?V>%9TB$(4
M708$L@C5,=5-Q4Y<^][IEAXB=^_SX<F"U"\9+(0HN2OE&B-E8Z>K=V+H>UMQ
M@-8+)E`SLQ<EM;K(NETE&>HJ<-WKZ*DH1WL'P`OO^89IG<TX@M8R1(SA9_V>
M1VMBTS0KDS5A.*?X]?:0LR?6Y1KVU6*WWJ3WR<I8KK>T/VD#XQ":\*K2,PA&
M9^\HO@9$<ES??SL&BGRNT-.7:3-OU=C@Z&1WYRT,32DI5ME]L\D;KQN?^)#,
M)#->+RHR>Q`-'/,@0CW7!T*J6Z+=CF"B0JKM8/6LE]NP=A9PI#%$(<FTC">K
MW1B.-W/CA5/)A]?TD$DQ^G`@6?2OPRJA+<.*$/)W0S21TTFSD12F+$EB$C:`
MT20FO:1)3-&MHQO0>W+LIY$$'`T*HZ]P*/*>'F1SB#UK&9H+F.V)7<]#8CY=
ML>/S`TV*^T%N>22Y:DG>IW5'A!5M9\Y.*/#8<@=%3D;Y#+OD]HCWL'FA#[.!
M#^)V+!Y@R9NC40&[F(TJ76/+6%M]+[)7/UYM75MV7L2'Y4,KTR\O^C>H0<+?
M=JCF^9,;]0E(!L?8VZ/C<:)N@@#L%E^L0-7$\F/]76RS)&F"Y9J:8O"&7Q6F
MR-.J?#&`^ZHI_T[Z/<F?\^<=!OD8)#'.ARK`X(MM-_#R*3I6[W*I7!,-U&4)
M+#TL,29&VB^O7_>STC/M3_`]<5:$BUNR'16!%KK^V1=T_["?,"!JP0!>171X
MOYNE(F28'$MW9LPG&;S4V#4CFAM+&5WCE;(C0_Z2*`%Z2*MS2*.>A2#!]<5K
MGSG'WFP7[FMFW7S72CBJ:C$>DA@;H(^]0%82OHJ!K]'!8&_&7M>$A934+3A1
MJ1\E>,#.RE[/64"A;SC,,EX2G$TN4T?[(O$:*\U3EXLCBM<'M[A3V&8&C\NY
M@!$6(G4Y`S%WB)8!#II1[Q$&H.TF3JR:Q-+4;V3)B^BV-[QY#?96B:;;%MTV
MX_A[$UQ04>/4+P_^V+2'!W(CJ0`^DM!3RJ`%^>YMRVZ+4VMJCMJ!NID%<)*?
M)\63C$6QI^,Z!",=LHAT&#I)!"O'2@1H0W);Q+(=YDW;,JC*)V\Q(8/XQ>_=
M?V8G>.7?EIJ/RE2UP%.:ED:0$[5XFW@YR+#6F,H9<@XU)6Z2B9=#$%=.'($&
M!AV00.V/9Z>OW@I&I0=,*L?EOQX.;HH&_6=G@0FGS#HV"<CL\$X9SC6UPAZO
MN)3V:&)Z^.D99J:-.[R'*A1U?=$6UZ'[,V@6NN(?($&RT0X\3(2HV6'A:/R9
MFI1(@P441M=7%G%$SB)EA85."Z'7P<1!I]`TKK6EY$I&=+35S):*_$TC-JW7
M(%?!$,XL/KW8M79&S';5BA55Y`J-Z5VQ(?[JS*=`^S&YN-G0)^BHR!^B/F]8
M.ZR[5"K(';S]V6KO2N,0D/BU#!'+(3].`0<9<0R,0D=H+W-I$]QK0V3K,KZ+
M9XSO>+7&Z6;'P5K(.\*A$,VGY_6\V'0[(;^!>^>MA,C94L`\!<^F'JX<=H4J
MQI[)[4[S0631L&Z9S8P2JAA"4'Z(!L"C1Q/;$P*<94]QL9"&LN`>/E]!5YTA
MPHCYG34?H)HT:D/+UPM<_)3.*F3<5ATG1V2P(?&(^_XN6)3N?-(SW3&VF8V3
M';Q$M@GU8#G)7]`O)=`$;<BE1W,WC?I2NCFXJ@8(TX>?`,I;-6)>TLF0C9\,
M>7HRN!>MJ\[T@91'R&4)A.0%H8H"FA(,0%VV:6AR!1+>T/1T1C%A31US@#8$
M-Y,X)FR/YKH>'%0OZT#OHR&;H-AKEUA]X`4?&&V6EN<!]I*Z(>7T`S-`W3BR
M@*VE^HN'7>(.,XT.+3+;[Q]1\&$Y8ODUR^P>^X;E18_00:PKK,4[4B.$RZ&O
M1:@=8O]7U0;.CGUWXDW)[6-&K+=@V=\\:L#*E8']*OYF;[[J+]F+&'+\&58K
MA!NGEV%+";]>2(W2W&*ZL$140DW8".")Y_27+TS"LS1TH8$`FV/6I45)IM4J
MRG7.Z]1/G*;&JV!74A,571DW7@-N;?2J?<+/L&WYE>\MKP!_B0:N8]Y/2,D>
M8BUPFWL.^@B`\?*A6*Y5/)PN&L9PT/O7)9+#C./&-*:EWFCH7K[5(IUBR?K[
M-Y=.[F`Y[+W3'*ZYQ4B"@_K`!3<FQ@0C1`Q&99(VM0V?$QPFX7O&7HT!>ZQ/
MO,,4/%;PV(%ZEF4+]=YR94.AQ)ORS'0?WNA4V98FCJNNYQ]0_Q4BC%MQB2NE
MAOG)-65F;7Y+F@T-"@<+BADJ.-)-`G!1+0S&U"BU[N&X@AH6N&JH@O%Q7$%N
M1K*!VZ7`J@F**AV64>?F=)9A9M6#%G)$BSY(:Y7WFM(J,^AQQNJ*/EUCX19U
M]@K.=V@,.#O?-O.J!-]IK:Z%T_7;NR-I9$[=BT+D;S#A_N:#6H=+-T%;EHSJ
M"Q_!WCCI$Y^:$DK54:(5(MZ=@\>'/VD:<+F(.'1OI!5"FI&")C%^C/2G)CX[
M_(FQA45^#IU:$WA,-G6I@2[3?\@\R,'`-S\7C@S]DI'OD-=I=IC*>(:65$B9
M.F=-60:%6EX[^\JV[GJCH[4'&ZJ$KD+[YB)\2@"31P*8`=Y@7%JSH`\2V_)J
MBGB.,3'ES7"3S-=A5Y2[5=E&OV1%B_MG;I'0HX=M$>I#?J"J6KI!X\;Y]]_(
MJ)$5OK2`T]F<&A&^=0.8B(KZ+FK*D_R[9@5ZS^<#/5>@ZO>_F+TU\EZW9]FP
M#B:@;LZ!/?H/V9;I<AB)&3#D$`PP+0"NT7R_)\>/3B:7X2?H+/HMO0>GT3'O
MJ>/=MME4!3VR;:>;99'F^+UHVHBO#5)@H%/90:F,IYF;RYC#W#LLNSOA]G@0
M.^KAD(8B`9&I#NF/_IA/BZP.2R,$@&S>]0)ODL6&^$ZFL4<&"`%Q(L=352Y.
M6.9Y#6I17@%I>B#(2.#/#C5>6<TEEX8/-,Z^$J?!YRSTE'39`$QJP4G7V4=O
MNS#PTD6$5II+:"IP9P(;>*T(T=0."H7G`3K8'::DFGE*&_?4ID\L.CP`2-9'
MYLD3JO,(9"'?`;F+P.49LP8OYTW+M"^=IOYR:M!:,.]D3P'(XT9'#P&ZY=\^
M_?1LLMA4'$7\O_K'8<Q"#"_*3:3MY;S()(?1"(;4)SC-OVZ4!%D@J)RGQ="!
M">S#N:&-*\,G9"D=L\IK9B`.D8Y@\VY!Y;=UWP8_/2U-'"G(0D&\@_:T0@DC
MA84B_1)$6;)\,@<"#/XN1UTE+GDF.V$@0N`LH3.Z-CLFTRR%E<)\4M+/0UE[
MO5='>$MH)238CT!$:0*!$NWQ:K$W?-$(V9#`H;.TFTJ9SL,2T\F=_<=+VBNY
MLYMLN(0T4)QF/#-Z_XFC:1GF]"FA='_HNC$9[SE`#B>26*GH;_TV\QFNA,&]
MFY-ZR"AA6P>J35Q5!0LNWA@)=%NSW3V<A+[#H;=)8S\9,T0WESV;$COF[V&+
MTIBF-]1U'>W4L[.1OIPO_RE]>;#-S-WQ=HH2R-IQ8#GZ0<".Z&(Q*G#>+>F0
MO8Q1X;\LR<KAK?!MMW/!+^4-]IG4LAU9N)DH$']S="IS)A(3E?%Y+;NEA?C5
MN*<(B$[H'FQG"P>:L6AX26D^RWB2-+LMO+GRO=UD&,KA\5+I:QX<"='(5]A+
M#[PQL.D^<X-B@S2`ZHW-Z/N`M^SR\?,4HS"<%-G^MUX:?/:?/!$_!%<W_7CW
M2((#K+1DBV;+V<Z0=HC[\GF_J3Y@&]K/C%7NH63C+1FIZRM2P;=RJ.PZ5ZLB
M<-*':AQRIN&HXX2YAKD@2-VG^6D%G^53>@/I8]U<:^@7Y^LYI$-_V#0#;P;7
MY6HN?O@0ZL(Z*UI2(=9@7LA"+(XY^J&\R(='YB![C3S*(5K%@LAZB?(H"$ZI
MLA#'J5L+%>;2-`C3O^.$,BBPB)E[RJJT;'<&&]:CG2L,>+8NH004321ETA-+
M1P0QQ.E/GZK@?_;=R[L8%V(A_T"]!_2$[APVGC]&&L9LW.7NKW]%[W]UMEE_
M.OWL5V?_*B8+B#*JNEKOUGSU\:\.[41-YA!+<QQ<]++/PUC<!)8]1]NCNB[S
M)`?-@\\@"=(@@Z-WT@E-''W2JIJU\(1')UE2P<A:U2/-:&WUW&,&K9X&/Y(,
MXKW#8Y<]L@'DF&$EN70O72!<D<I]QT6AK*XDZHH%8#%PYVNHDVG#KN#]/@^I
M8WQZ0Q\.BY+5>%6Z`CFM$Y..@Y<$#Z=J]K*@\M.MV/'P(C"]Q""-)F2YI81%
M)-C[>1=OD#21/29->+.%AOR;HZ/'G](WTH"$W")^\+.CHW_+1)T?`S>/I`.Z
MI*R0Z)+%L:3Q4$V,T[0:6;PB^*1*%?)'A@;+MJ6UQ?XFW99=/,(T!&<^G;*6
M.&`,N25:<&18N)"-?,,L`1:>/4E@!WQ\3L2FCX+%R.7=<(4J`-),.$B,JMKW
M!M62BN[&TOA6-\QMSV)F8%N*AX!G(`NX5C[&31^,!IR*4UX%!1GGZCU<Q?T,
ML1#(E]*8I)8OX40F+L\CPKWP/9#858(:/F#W"-8\68A_F_676.E:WV*D;\*L
M)6E6-+O4R;8_]=)]+O0R'$C,7>#(!/9'^?X"$#[V5U%K[%ND\>=7#3[?$.G]
MY=>6F!:.;WNTIJ)&Q_&:=I$C7DG(*R1%R)Q*7H27<<.LB2Q[U73;D<POX3BL
MM[DO/A.4A_0*C`&&`ESLL*.N6!%4WS3MG*NJV04B?%)^?A_KZBS+Z]Q2/N3U
M.C!DHC%"8)J_16AV7[2N9WG8V'P<J#F*).E[0#,U3A74<C#"7[%>;C@8\+-`
M<+\(PA+4!A<[5.T=*#@=QZ++(R5IZO9\9^H^*LS=!=1$YK%>6.`Q:(F:?U-/
MP_'WCAED@^!^,@.=A=(91R7!]"R)\H_/D>W5P^E("EZZ[8#-WKOM^.(@T,R9
M12E.VK*)@)1&VI%$M"H.ZQX!`L5$D,JJX1AF:,_\H;FH:8?,9C<F,X5B_JMZ
MM[UXU!FKD:1UFN;0#<K)B>:MAE2"@_GQ[/7;.X<','-M&CKKI8"A/Y2^V^/F
MZ=X`FP_TV=F#]B@&\N^T1S6Q*]**G&Y-[B")+@-YA)@K=2DB)?KPG&8G."#6
MPJXK09$SC0#R*P5OPTA,]>&GD)-`.H1W;<O`=K'<<0&[?Z)H$&R_`6.4=\D8
ML4;W^^;62;;^3[/F`S;2YG;B_3]@=L&/@QRT$>`<IBK!S:UITR>:F`"4:#\4
M[,YE/#.';52@_",0I^.XHF1AC8F>'L`H;4AWC+;E9+3?7D%UX?&AURD/_4TX
M6R>>[56C_L4&1V>(,2B$G$L/<!QR(H554C^>&UY:;YI1JI]HY_B2:S7`D8.P
MO`03)1NV1Q?KA6A2*X<36<9KY<BE$>FI.9.)!-7?LG"UEU[:ES*%&=ENJ]R7
M^DIR2#J$_PVR.Q<%C2.T=P4E3''384AKV-\69YL&WKK8H-2P":UU6]_:T+KV
M0[IHYJ/CB=\'@YDFCB8D+.D5T?K<VC;9X.LSI/F3)Y*[2C;@CBSMB<%;G7V.
M1<0F/I?4#BR8+V/P:R(^*)?T;65PP-:J!?1P1ZCU*.C%P/-DU5#!#P"ELL#Z
MW&J]IQX7X%#P>B>>6.]=Z;=FFB_J5EJ6(,0*5RE:/&\%@@1POL$Z$]H69J"*
MP&U)EW:ZE(CFVQ1EEBYCM\"H9[WSTC(3[,"<3J?],S/<TG<DJS&-U/)J/IAH
M`;O3(55Q(C%H[',KO!>K//4RMR0*DV0A34(I-W_1P]<U[^UP$F=:8UN1O2`[
M".F:X3D9S,,]$CY9ZIR%F+W=K:$=23(B!"/_^>"360>RNN\@_EZ0`(PAWS,+
MG%<C/4@&3QS<452[,UW*-W&GU(IGH$#RA2D@*(O)!8\<<T';/SEU#>CY)!H#
MN/M#X[X@1S7/F'/3)[9$)WNR,/[0T`A4Z_SM_*)M%H^ZK`>TB)P4,@8QO=U@
MYN7*`#!0%8^<51^1W3)GR^)_[Q[1MGE67%6+[`_4=/=(10=$S`>10+WFMVO[
M:&D$/]S%K^Y#S26]CO%^@KBG4=;T-?=0GA^\Q"\J#(%7ZQ>%\@585):0>MZI
MAR6I`*'Y:X'VXE&G)58B=\X_#A;B\O&;)`_&"*OV$WBD8D2]++WTX![=QY[\
MA0I1?9;M`.`[''/ABM(OI2Q\+QE;*Z$>D\H^EN$W(#[`L'_WBC8_EP]V%"*)
M`+Y:=\>\,BU;A:<[EE#]_;M7?[Q+B_.NI10+F5R2RSN,LS=UO_[IH'A)9"M`
M*J)C<EO=6"67'AX;LZ:2K2\G4ERFN3[MT#1ZA%BYT\C5Q60T*D0@D(V@4'6`
M)/O"Y]!;I:>T)^IR[J2*6Y&2.6)%IJJ.B6M1=V*M^U`0481[=IIWERB!9T@(
M)]@#&TQ<SI#&@29EN^A",WFNZEP>_XNJG/M4NG.*>_V-(UID#UK(0R8:I31`
MIO!X`Z[R8=J$&&:L1E(3T`WRY+_NH\<BOE)"X_ZY(8\+]_`+1)Q_*W?R"F=(
M4MJC2_T:NAON%K[;D$M).%?V7P(DB$!L-JNL(6K*@O'<7#3Y$\Q]KR.*P0MM
M:/<1M*=61L"-/>A(\N@48=$OZKI&!_BM'NCQD`_Y(I5,U(ZE^/8Y'V8W(VQG
M0EF!AH)KTRT4N,8<8\Y@:2+'PDWO,.EM9%7!3<9/PQ+V3XNI>\0+(!@.20/1
MSR;+1N_2E>/&/CA4DZ?%DZJ?RAXB_ZG!,<5\7=X=]0N^=?,W?.O#OHGOTNZ%
M%A_N/:./7VY[NSGAYGGUXEU(#Q^=/9$)7ZAR]MOC.(2C/!=[UIT27%!+2M?C
M^F-ZGQ+&<'1DM!%A6.EQ$U"3/=D:.C=8P%^,I2J%3_+R8)ABK8G-NIG3Y3%<
M')*AL:>5J75\.E@J']\4-`BDD29-"*.U-3%"]SW.NR@ZZ\B(F.!-UN9'=IOQ
M,8?IJ9==ISW41)CC>"R,4&"Z33'5Y%%[8"R5-'V[2R7]^+C>\_JT56I.D)^2
M1_]SAD4SDD4G]DI!YA6//0X7MC7S\,@^[TOOMOO4EE1;&>%T@K(7;=)4BZ'=
M?<QC0/]P9WW(C)#D'K*A7)K+LD:+]A1OV=Y3_%OOJ6[EGW+;.]S`'J'PQ%^:
MF[)M;X,.PD_BGY@=?=^#(-TBO(L5J9JUM-*L%N=ENS[V[Y\W[>6FV/`+OY#5
MM%>(C!PF2<ZXNRM=L<*K/I`&/9MH>(;PI@ZLG<'M?Y`.^*UFA5$#:K@??Y(;
MVT64Y7K-SI(I2N>2%II.A_P6,S?XSS\_/OJ/]S*%]#JX7VP(/V*^6X](7GPB
M7R,*"<O2P+J4T@/8D4W;0]^B<H<>JM/.XC==7#"__+G1]PYP&_-M;"%G1`"0
M]CLK;(3+=S1SJ"@L'-BR]HK_/?8'KCD7NLADBB&!P-I.XW2@4]OUZCCO/RL^
M!3O(..%U<,]YO;O+O=.`$02,CW`9MVJ542MN,_)_9GN%'LI`W(ZL8&,5(`G6
M_3I,_*]M4^JG3`-)O]_RY^U2[AO1*AZ@4QCQESC3QA19T_X0A9Z.<6=A,1T)
MB7+9=K&_?351G]K0&HIM%#A&XS-]U2/(4O_VN.)/P1=#_Z!YVK;-8C<WE(TN
M_M`NG?(C[?+9'SLSU[]'3Y="$2^.%?9;1V#^ND)IV+V58$A]:)D-@BM,!J<X
M0P"EUJF`+E/W^-YJ'^]ZA8O*#^5<<]QLDD\"@2\@HVGE(F48;%PEBB*T-T%A
M5:D3&G)FZ-]3STC+*DX6W]HEKK*D_@FJ`#3GI:0)>KBO*QXR$XH;=MU;/5KG
MB'*5F=F)&PJLL"^#:[D@?R]X!K_=G"/M#H%*TT,XINDK0K"W!SOZ!'RV4E2*
M.>#K)@,W/)@$=$WYJF(VX5QVEM>9?2H7IN%F%@+3S\Z;9B%)+!=%N^:^NKN8
M1Y8S>3B/MY7"@OC^'9\0-UR`VQ4RBI[/_NSW/'Y!J+/<.E$77-4J$?`DD[B*
ML4.ORN76@&D.%>L8N**3>H_34ID&\_N9!D/_7^\KAZ1\G8ZLRV#-S-ZA97HD
M?"H<#NQO%@T]PJ)"/:)]S(C]&+,XLY%:H3A'3?#KEPR)6S_]TOQEU^VP^[\'
MS&Y5E5=EQ)\Z87!12.1BTW`9:([PY+-68L>2];HH"Z;G9BZC3*=EOFO9^UC4
M3``W1SA@RR?+VM&6]A9+$M:;)71SAIY>MJI=M0;:FV0,L%BMN)R*TMF@*KV/
M0G$;CJD97UMTE_3.%T@9XCKP2ELJ!;.%,"-&#Z74&(LK+0L&O'N[0RVF1=ML
M2&MX]"@U`,-.CCKF--'T3Q<IG5P<]KMLB,4OW-W]8KS&]4J"<<$U.4`+;`5Q
MIX;'&WJNN_3Q>KXR</ZZN%3.?!)@M&#!.KLZN9\G(7M*@DIR*Q?E6A*)F-V4
ME+DE$$6*:Z2]<ET''=@3ORAB*_QRQ)F;H&TW<29'$/7YLKQQ:$$`[*^*:L4U
M?TDH"V![PEEQ1UO)\8:(-DX#LI!^^`$IN:B[0Q.GM59YM=.7:X%K)G)=KG;=
M!9<$5E"P(JXSS;A6\1R+\>F2,U@15["@Y5]N)!`AZ&*LL;TL"$C"0FHZZ0DW
M$T%VAP)]:&S+I13OJ<S,>M_L)EN74E%R>">V$Y!%I08V`F*L=9JXJ6%9URRW
MUT7+C#=TP'$Z8;..W]P;-T\M1>=4VZG/MLT6)&IF96MTN@_.RK0HJ]##RB%M
M\TW'*6VHEO01!AEK-`6B0(8)I[_`X#ECI:J;-A-F_WFL8[(=#>O/#97\CN'9
M&-VYU`Q<<8*>MJGY0:;,2<XD[7.R#%AD1EZ`L:6=F:"8HD;#/!P&FO_?KGE&
ML-Y'-T80,ZP>X!0'46&W`5)9I^F>K8_"T[O->+^8-'=BY3(9]6RP!*Y>]4&Q
M2^[3TVQ<8+<R[#[<Q:]3UHWAGG)E\B"-FID@?#6%A%U7D$R:11]6=%RUC\3V
MZF$*(ATV3+TLV<[?O$W(84UYFS-L(I0[1*)O>@DX-4$6")..HXST>C/K,%7G
M5Y7*,&2YV:E3+`&W\EM\`24'&XK%$[8:JUE0*\I62T'(A&9C$\H"F@O\X;SH
M2]@\?TZ-;35C#Z\-&<!<S2_62^''A1G#SEY/(V2%ZH/Y;:('RZX"D"ULSZ1F
MEENX6-I27:ZG@$0)*?V14B0LB^CCJ6W2\.>7JQN5PZ-2K=LP"2>3=N:!M)-G
ML^QB/HP.))ZC\W)[HRGD4?A>]WKG9PI;LF(UBHZ<JV9U)9%3@1:RTH*2L#P&
MW@$7D(<NR4$1[A/2*A3M*6N+^N,/;R>D_;.<\RX5PG;;'@>W]G"BG&#VT+9E
MPAKL@VYW?BXGI*^!'>A-A2V3QN$";&WLU2:CI-NUF[;J!`Y>#5*W%*4:EOGV
MPDI76NW6`],0!09A@?E#(3+IZ/XNBP>1)$\DQ8P[8PR,#_`++JKS"Z[=LD7A
M%-%F,`_\K;ICLU2'2OL_,8ARU9IHTX5HZ2LDBCYLD)!V569*06>5U[CRNH@@
MZ!3<*%<(K)A+8%02L\X,*KC==DB%]WRY1"UQX65E9ZW6`5/)#9Y]]REO:/M3
MNS>DTXA$I7[3\N:*J\Q4T*'$,NLG>XZC'@=AX#SG+R_"\@6&PC"-^UHRM2%+
M&)N!;'FM5>E<?63)M0,L24P$$4AB?F1NT]#+AB5IV9Z:'@K-7(V29KV:KRVP
MV"HJGKX[_?K..!9`.\QT^5I?!NZ#JV(EQ5)2]O*&W0KY6X^!?6L$URE:_R.W
M9F]B12]_2Z3+-B8&*7#%\ZV%<'A:=1WQZEO2:8L\-&6KY>-3H<3!U^.08$DV
MYMTDXPH+UAW.]^.QRB6MU5$2,&JO]S@7IX;.LMT'BQS6[1'+M8O%>0`2K9NL
M_$#[P<@!D/X81X8Y)>#MPW'(5E>_))J.&1+!0YG=`(46Y7%TB?8J*B.W=]%,
MLI"".TSX&WVU6LE\H`+3>B23LA)"8/9B("('K`W0?*IPABQ#5_`9NLX5\`"`
MJFL)7S?[S.K,0];$>1,F#BX]5TKE))>K%M)7N<888V5[XCH6Y\-69\+>FE,)
M+8:<<`=;GO'SI]\R"L90AP[W-!FI$7IP>7C7*PI3KM7GJ30>8")KV6@][+7P
M&B+^:721CM26Z?WXI\55Q:_,!%#E+OWWV?_Y;VT)\A7*5;64)+M1($5DZPKE
M2XWF8WSS3CB#$68'N^>JK1%J)UI9!/Q6RPP/*(4(DG_75L9.4^34/F#I9@4;
M)MKKW,!?63^[-D+)R$:^,UZ.RKGS0C$RK#"KVKH.!*"N_F5QTRA0`D1)217A
MBM-IK6R&%'<=BS5C"=57%>TG/GZX'MML%2J^WY,3O4=&LB!B\<VB(S.WCW(C
M:_$LSI"]L71D11C0DJ?CF94<2*]9`U6[+N>7W21+:`*A]D+N`*6.M[)=\S5D
M`[4&OE=6C;3$6[%O13#1S%J`>%>EE-]FUT33GA?XT$4"UI0:S*75MQ??V7A-
MFSTGS#2FTS>J%Y'Y0M].ZX@UHI!97U]@!`2=ZW/K,Y`<S2L-!^WY+'S(55,M
MDL$TD\YX\UQ&>Q'3P><TG&5^H!5'V"]4="%I%JI[D+,.Q[P2D_/0<GV=\CN3
M0HMT[E^Z'K(YI(FY14:**3A0NI!Z*PM9]9C)/8>QL/'+>2(RQ7\RG]9LKL80
M@!H)T?9/S[-,L\G2Y3KU56S[<IJU=W9VE*%*0\1Y=C=TXP=Q-V:N!.CX-TD2
MA7%@P";B#M]L&HW8Y?,5J#1N9/Y"T$TJ1T9)-2`*=O^^T\SS>Y)GAJ6D3]YG
M8`XJ(L/7F0P-'OCQ^=??O7SSS=??G;ZY^_'=\S^]^.;K=V_/_N?MMT^>O7QS
MY\5+9N)E.O:J</+0VS1>=W(61NE?_N7V\WSD9ZE37F2:H27Y3IC8,*AC[_J*
MC^RR<.^2VED\+\?@%]*'[/A,;SSY<R1;GT[?WXZ]`Z<=G:(;+&_IUF>?'HZ_
M[]>_CA^7_/[SO@Z':3X<S./09_I`5-D>#N?9V>UT/%,IJMP/B])XS?N!3^R)
M><82U7VUE7?5O5$KR0&5:B(*(+@J+7E6C@DKJ<N;2-Q7RP(^Q%0Y9I]=;_-/
M\]?B9F:(]1R;+Q/:E8#R8H@7UZZ0!]0Z9H71G%/1>I/L`>C+(A1#:@')5=:%
MA-K#CD_FZ"F#XDE67<U+P@(5&I(=J5++4LL^U%6?L[-]2\>M?(J/&SD:5@%3
M*1'^]/81'+RGED?#E#E<>4Q21!7V?7\;:"0W>A<X!DDYFPS(75BOS/]]^BDM
MEX/GZZ):Q7US=/E?\VY*HGU:+G:WRF;$\V(UZ27Z:![RWM)!TL6PWK&+'Z>T
M?$D9-JG59B%IKL=F:("I)NWJ7^MRC5**;4B$X`1PF0A39;,>U%\`EIJ0,-3B
M_+W3>2VI_)FESF'PJ@63S<M](/^G#T$B66X5H*WV$=U,AN86*I4D(K#]+QW=
M:G`<Y!(V%,EF\U\5DZI"DK+L["^__O8NU%.?YE]6$J[F\K9[#&+:]LOJ0\!*
MQ8#_;18'[U#<87Y=QPW\L+31'ST0H:KO1GMA#/I5K4+_1](V\@T[^S_RC&!"
M^)DJX($^]A`G)NE3BN^I9I=Z?$WI@/C(\W1W>-PEP'$UX>[>)[EXX3&OJMM1
M$MG25AX]MYD6U934`6R]$Q#%'I_7NV.;^VZJ)QDKT(6D8<+I2<)MD4EL,C0=
MB]ZY8E\);(2N6P2+=/Y6\2(=>Z0P\_V``]#&7%5(A*G5]=#B#`,8B7QR[LNI
M],70:PDSLKT=$'(9U%FMK>7RC7J&ZTP3+K6)$<,=Z3\DDK44VK;9Z+G?MX`3
MEV`,,UI];)*_.+3DFX7PT;9K@H6]6G?_LZ"%WPE'WA!B*D(HF^9(CAK@V\:^
M,;RHV^Z6RPSP7-I;\5E:3$><98PS"H1XF61AY!K5X#OUFH0=%BCD,@F_.=>C
MI2@!H&6M%!\"@I`V*D2?W]I<+6"UN3#OT^F?7M^%1Z^*#Q]Y5#_[]$_RD#KE
MY2$NY"G49I(<ANRVZ5DN^4$.URJU=%^]D#82R&,_54T)TO38K[HYV:BTS':=
M7#;D((.KS]LXR&/C%Z%[BV9NF=NLWLBA1@\4LN%&P6MDU]")4":)ZW"$P*\[
MFKT>+FH*NVT?=1(_<_Y@*31`VP=%@\C,YS(;G,7<:%P=Q1ZA]5X)SY)$<@9X
M-V8HXH5?*:<83DS::EMA"0PF=W!52ZG`+J$_O&BN,XTV!,0($_2*FT!?[)VK
MT;.QC1FCH,!"?C2"YK2",(G"O54>&L-8R(\T_\^Z,3(8\3;+)V?.-56/Q,;M
MJM2_,3U*?5RN?$[FOC8$$.K0K85%,MH2_0#..J(\$MP=@U%VM<;%67:\2#/'
M;7SQ]E?PW]![`AF.+U2D<+;V4KFF![7W`HUZH&!QR=!9T<OC/NG1F*_EW4>/
MIY\>OWE^^NS5\^0GY-7A;V5:&%S3+QI<TV0(_(1_#JY+'63]97!58+YVM=O>
MC%S]YMUC_#A=+I*+`J:W1]?+/1<??WKO-9"W>U+V4U4&@P/&QVIT=>IDZ^DL
MK+)LWG2;1@I;C2W)DU%:>0QM,@@V-_LN^SG:=X^?JWA/,A/I:_"PX=K')K1?
MUMIWQJ8UWC/LL$WNOGO<%'LB8\W&4L+]?H,TK0^[69;`'AK_WHW]]?!ULW7H
M0UA/O3QCKE(ZK$4G>0R9BOH`H$@>!8A%3/-"GY))$497L3H88-"E;4NREU',
M'1T=P5^W6T.RLCQ#O:_,K,]!GP(52SR(D',"![X4?$55B&=O\S^:W7"G`1S[
M%BY'$%-C(^/N@),D1JLS5J_Y+"CF<P[YG@^Q39%C44+*7(F#;#:)PX%>U,KN
MA&H(RHD8&&X/'L8HJV*ZNC=;'W6P?A$^=Z]SL5BNWW_BV#V.Z8>?Q\RM#4*S
M>O_)OL^QFZJ9O=71`=G%;MN_V&WMXGQYOK]UQF('X]ML4GUPU;S_Y'>_"W]U
M]HXH`^S61;%UMY)JZ_]JK_Q?VP_6C&YZW6URN5R]_R1%Z.?PD<R[_(]5MSFT
MN]K6-4G:[4>';[EXGV91Z`=L.LXF[(U",:RN;>E.UMYZ^]%WDGKO>DD'C_\K
MSABT$+(APQ#0%G4WKC!>X:]UL?%_+=.%J%6\XL=$DLGP1'SM,JR0S67:SM^?
M#]]>1+;%1X=MLW*?2/J=]8T3?<.7;/P@T?$TLC;OFS^ZP3]AK6[[>WO["_?V
M56^*KI8_M[F!]^)L6>7_"CLT#T9-8M7,2M@PXPQG<BFU:%YV<,XQI?@3OIY_
M7]S\[BY[9KBS;9^!2&$0'%5&>+]%G3..9#YIU._:,"IKY51_XVDTD*.>KC'2
MFP2`KP7?)>R2Q3:;2?#;%8$Y9Q9V93KGKC2;JE9`$%.+T,-:]W:N+6:(N997
MAH)!I3GZ7@'$7@L#(73%;3F_4/0O*^S(`Y*$"^J)W!+P^WP'P%D<16/3)Z+J
M#I5R_7PGP:\\.Q"3"9W?L*-#\X*XYIWW&HG^\L,/#+WNRKHK'SW""?ARZ>B/
MI"^`#G!/+-PPAB@)6(.JSEPA$43J2(%4YU6M=7YJ8"7!H1OR6N=FX@$V^:$$
MK$/,37[Q0?2W-\H/TZ]JWQT&')SYBISS7B$$5G*/[5`6#X-:U(&9U\I#<-DS
M\?(S([0F%%F!FKH),8!Q-(9B+V`15-VT!]%BHJ:WMH;O^L`"A=1:)^^K6SHN
ME?+,3[F`=YEM/F;A:'(H3&[FHX$5+\]DP017R(,QK!8K)+0';$#?(<D%F`JE
MI=<Z'BT&E51";I,S;T:K)9YD]S*BCGV_<6Z&-_B>7$A/&!25L^]P=0)$R659
M;ABB%1,5A(QR91#,(O,\7P%='0DON2,J"I)!-CB7(I+)QJ@-$\7ECQ5=LE.7
M"6K.L/L720(*$3D0:KQ)2AHT"94!NEYU=/;K2.M:FD>C[&9K!''(J0@MNPK4
M?`E.5.S^%"FRKZKN1Y9<E,G7RBN!=*B=0C,4)'*RCT5.7#2D(\()NHV[RP(C
MGV,6Z.S:3@(V-TT;R=P&$FBXL:#;QE28N$\;HY,2PL(PVGZ%*YJB8JYZKM])
M9\%EC9R@&'/L<>DN2V1:@'JW$9L&[D:``Z+;F46:;`Y!&_-[7,:B(')AFR1I
MB;YK?MU5*%G'OM04QD'S*U2G65K-MW'K7J#BFJTH6!.AL?=@C,S!!^-ZDW6L
MR/6)<)G!>T?KS':FR':9"B!S%<RRWB#^J**M7)*5A(^]V0_?&2OGV"]/YV3I
M0)C2I?/S%5=(:Y7K,]2,<Z_SQ)9U2F$W57I?)0843#E=_-S@D:MJZ4ZG6&\]
M$W#<K-08<*B!*"=&)]J!$.A[]F*E4XASX&8<'&TD6YCNUM9@*Z`B;HVC`,5P
ML8_$;'CHV.#G2KEFY=]QN-SJE*UN?*ZH+U)Z)&E>?C7&$U/V3<:?9S#IDX^7
M;?X;BS/O+_ELA22@1AJOI06\35%S%8S4`2.'>RQ?RFIHI:4=SCDR&^BS)"&6
MZ^AI&A[<-[N:RZN+3[#,0NZ?H`A$->&3DT5R2;*IN4FY9^>%PC-#-@)M08E<
M>S`7BE6"7Z97M)R[Q`<MLH@`["QTT-^]>"4.'Y'P@F'K^O@M59DL/UV7*B)G
MUO>(N^[#*ZT,/9/K17XPB^KB&:F.(M$*+I;G>,6@;RC:B_8[^\L;.:I=0@G.
M^P*[V6F*7&RD$KPI@RSLBT26J8S9VLC2P0&<2-4%DL&A(I,5,^HC.`SUK'>G
M1G+L<PQ=!E0'"//*M9\RTX)%M0BN8<`OK#@X3X>54)&T'IY539)Q\K$ML7P#
MA3OGJ'!&&O-JUEK!#BGW!?R2AH&Q#]F/L<LQ4*0"W0A,AEV-;L=;_3_>`ZO5
M"%5>+E\)FR4I$,]#6UB)#:L`'E"]?'Q$$3>4#&L4Y4Y*A,>E-%)U#W2@V'(&
M\P@YB1!N/UD9<,/K+41XPJU:3_/3E=#@2V;B;%4Q*%Z)S]FOQ?#9U3;Z?U',
M8$;*#R>+-\)PJ05\%FQ\L"W#IXIH8KOM=4D:F`I1RS;N5PJFQ=F>E]ZG:CS`
M:44*^MR$%2F47-?+RR*Y>SF[S1Q/7[=,GY:JZ8>6LJ*=B^89G]TC)P@@W/R:
M-Y$=,#U&W$HB52#8_8$V[]844H";F_5`)C^LPN(O.3;V>Z-0!2R>)R\U+7K.
M&-R0>L$)^?6C;2A2M*K6U78_%#D+-51[B1_.\!#"2-F/7!K.C>*ZZ8WB:-T^
MY%RQ9%A)V%8K,W&^)DFND.SQ2PM8^B'Z)3.294]$KM7*<`!-R^/^&PSJ1SXZ
M$U2(XT5I^@50(1P9+H%2Q4TC]2YVG90=C1Z,/4N=C_;1&FEI-I%HT5;10//3
M.E>B-];)SD+ZBO;0ZIU;=1+%I^>CTZ2U'(]OI]EIG=@(,,91QTNI5LIHP?;I
MMM?Z830)DCPE_8"L9Q(0?\('@7#.J4`X'=^%S'K)@(Z'<BC^ADT=D>E\Y""]
M*&E=,3MR<$+6!\;YZ,Z9RBJIQ,!/RLN!`Z$YB5DC!OI>H3)93/*-QPTOE0D7
M:3+B#22S<.$2V&"%%/+[/)><'VT6N*E^)2MPB[A2T!M@1C4")DIER$P'MJN4
M[]>D=-.J?%%B9&I:]C[8@R07/6:$`+RQZT(:&*VY!=P-0"46-U84+^2\B_7,
MK<+[(87[W,(T\8O:>;9_NK3.,W9#.""O2R7XN90QBZ6:73EF=^QKAB`7+#+^
MS$U@_\$[7&PF+/E*\6XS8':Q7>"/5N4F*Q8+]FK2QB,Y&7#/2?U3V-ZA_RSW
M@M*P7LX_W&97W?3,>(EO_CK_H+AR4#@"KR:VN+66HMAO_GHWS;]IJ3L9BQ-3
M"JHUUU3@OL72"DDI`!G@75U!.9$0+;8-UHD@]`!IMI2+",K&><+*'BL:-.)P
MS=9;Q><(Y0]IF_:@1RB3X;4K;%*D3AY@*HB\[B3]PW]QKV"W.`@`P&9.:\F;
M7R$1J)]UFO(\>G/\]/XJ$^JJX81D3OG6O!P4X^-5RZGF675>2[F3MG3LW\VL
MF^_LEV[:5SCPLYZ5:]N27",R"AU=Z[J[`MMHYFBY%3)O"F`ECDXW"1@D";$C
M.TC/*YA>/?)O4SW!+`&'?N`=%ZN3DTVE'1Z4N@E)+X`_Z]WRD9SD+GP.H5GI
MIE%?3)Q'`PNKQT,.:98=/#[\*0B%'A[!3E!,P<%GAS\QN(EW.0LKN!*IV>NB
M9;21BCAY58`;L/FI2/>@VJ2O"?4DV4D][=4EFU&;5;.OJ@XNI3&GD?"^S[H8
MNRQN`N.@8QN_$]B$?D1JZO"*%%8-5S?!5$/[;9+Z3Y')?0+-'F0/#%(`V%CQ
M>W53WZS97MEN,L_5*+XT\SS-&BY>>X%%(G*;`7_I\2F^`"M0$Y'="F"A-TP7
MM&3+Z:(\`?3FR*!TN-)==#L!*_>O@/>TF$]WE^DECXT!A\)Y,"?P`?_EV[P-
M_F!TC)0;MN9"0CY_<*;,*)&$0=@J.RG6#$<C#?7O[6(*]AB4)W$\14*EU#>S
M2"7@DE#H"-O__%$<=%&+RL;CS]OK\Z/MHGL?RO\!&N:SC+E%.>QY9X_,OJIO
MB\XW,F]6JX@*&B/09QL5;/B=-&U%=6ALU]"(=MOB(B+,#<<1JPI^A,-4ZN[Y
MNB63[/XO2/;O<:Q6<]0LCZC)^.IW5O,Y'ZWY;)^S]SU7%3@9CA%N/;*'CKG!
MHT]'/_`>MMR/OBSY*./CO=7=YW%_6:CQ%M*)RD5DY&=_K#D(37>*LZV+'YP8
M/`=6<5XG-]_?0_6(X-[CP#8_U6SZ:E7FH_UR*ER>[:/Q2@M!<DAE3QU(N9:*
MW*=6')`VZB"0>5$@^"I15L1K2F9%^MQ18?$^%&,E1AJ-Z$9SVL`6MT/.Z=N2
M-@6#9M\4%]N_FFZI4_TM'SM?(@2>O[-0>_Z4U!S4<2.;HJ@Z*,U?LP<U_YY4
MR@MK(C+RS"^*"N?0-^K^SN?N`V/5#/I&8=.XZ$A-*'^<?O:;,[#2D93:7MSE
M9__O[WKE$O0H3XIV1H=[_J1DQNRSWV9?%>V*_FQAROTV^ZZ:7U;YDQ81*OJ3
M2P/E3X$;[R"HSFARFC4-]/,.(3:ZXW1%P_"'<KEL2V[@#TW9GN=?U7P8XH?7
MM*1)TKXJYE^1#D@MO(%A^(I,0;[<GP[ZZ>E%6\E/;S<5S3*_YSEIC'0&T_GU
M#I+FLK@NT-CK"Y+`-%7%S:KA^[Y=M=5E_EV%._'V8K?*OVO^LBWP5S)K]+2`
M\6T:(A#?J9OIS/TSIT[FXK3;<$"%/Z=<T6+$7)+.2'__'J`4$@M/2*F4R7T"
M6L>G-$:HW7U&3:PQK$]W9,+?A-E[MJN1H(^_7]'<%"1M7]`D[CIIXSD&]`59
M'S,NSG66/8%_H%WD7]+8KOC%-O]?DF(/XI3?9E^634LV^Y=TG-77"$W1;[IT
MZ/`%E$`:(H.0+.+?-VTM,T\KC<0/K<E:.B@?_54!/73C?BA1V`ES2<U\W]27
M39-_1<</W8#EA=Y]1<*,E\";AJ:*_FPO+XJU?'3Y(?^JN<2SSV=@YZ';7T%&
M=3QFS0S+LZWXKS^6-9GTKW;TPEI6HO3@S04BF-3"JZ*]S-]6]25_XVF]:,MK
D0#:OJ`D9BV=D\]*:VRV&2^YL62F*2@^/N^S_`U&`<.;8ZP``
`
end
SHAR_EOF
echo 'gunzipping file tds.tex' &&
gzip -d < _shargzi.tmp > 'tds.tex' && rm -f _shargzi.tmp &&
$shar_touch -am 1020165495 'tds.tex' &&
chmod 0444 'tds.tex' ||
echo 'restore of tds.tex failed'
shar_count="`wc -c < 'tds.tex'`"
test 60376 -eq "$shar_count" ||
echo "tds.tex: original size 60376, current size $shar_count"
fi
# ============= tds.toc ==============
if test -f 'tds.toc' && test X"$1" != X"-c"; then
echo 'x - skipping tds.toc (file already exists)'
else
echo 'x - extracting tds.toc (gzipped)'
sed 's/^X//' << 'SHAR_EOF' | uudecode &&
begin 600 _shargzi.tmp
M'XL(`)0*B#`"`ZU6RV[;,!"\]ROX`S8LR:^<&K]2&,@+L=+TH`LEK6.B$BF0
M5.I4V'_O2G;B)+`#,2A\L;V<V>7L<L@H4=*"M"83$EAE(+%"2:PB6>8QZ-V_
M'BZEU2HM]\$`OT4?<&5\`MKU,-P`NU,9,+5FEKY7D4W-N0;B@_3<B+_`HK(H
M0"?<4#2<KQ`=D_@X4_*)EE+0',4>!?KX`R1HGF'5;Y_.ISVMRC@5FL)*/[,5
M<)ULA'QTI&FJ-E9S0:M/83^!4QV3K-CP&*Q(V*Q63TAV(3*0/`=B'#@S^GA#
M+=*O).Q=A0.7W05XIY0E59JFAQH`JZ$+01\O5<(S-DE3L6^L$WZ`\[+(1,(M
MO!5EU'(X`@Q5T;F$)\C8?-]K<8+@5!$!M>B*)UH1;.P"\_%"-9*?.;4P:(:B
MAK*IL#DOB,'K.5/X^)-G(F4?B#R7'01XK61G73-446%A:S/UJ%AUM0@G&*7"
M)!IJ(*<#5'6PHL_;91<WUR%BTS?GU'W\2L;;FU58&X_GN^0:8#6-?H.6K-/M
M#2#?F9O)&UM;3O$U-H8\?/GA#8<CR*-,_:&CUAW`-MK$:LNJQ>MRSR>N7Y$I
M>`)K7H\>B\YSYES>$.<J*7-:RW?Q8_"CV#YY7)Z35H1Q<+4^S=^[E,W)9P>N
M0<O\$[R7IH!$K`6D[%9`T@Q"6_@4EWF1P:&,I3%EP^#@(=/:85-5-`1.MY=;
M%A^OE*;[4;)3]XHW<N$+<+'E]?;9>Q$ZJYV@2=.46HRQDS<0,RGR`+&?L%&W
M]R6\C[=E3*[,YHO9_8H$^R^'8MQR+&:X-(P>)*0V9U.PEG(]\.?O1''67N'9
MBZVSE=7T*BHUN!+L#+X%_A.*%ZNO39*%SP6P^L+<GW-WMGH*4])%INP.C,K*
M9NP/E'[/F3)H*,G"S>$:.4%S@B/XX"9O!/.]EDV?XQUD]`JH][6FULO&2EK#
4%_4SS6H1ES1Q>^`_$X,)93@+``#X
`
end
SHAR_EOF
echo 'gunzipping file tds.toc' &&
gzip -d < _shargzi.tmp > 'tds.toc' && rm -f _shargzi.tmp &&
$shar_touch -am 1020164695 'tds.toc' &&
chmod 0666 'tds.toc' ||
echo 'restore of tds.toc failed'
shar_count="`wc -c < 'tds.toc'`"
test 2872 -eq "$shar_count" ||
echo "tds.toc: original size 2872, current size $shar_count"
fi
# ============= tdsguide.cls ==============
if test -f 'tdsguide.cls' && test X"$1" != X"-c"; then
echo 'x - skipping tdsguide.cls (file already exists)'
else
echo 'x - extracting tdsguide.cls (gzipped)'
sed 's/^X//' << 'SHAR_EOF' | uudecode &&
begin 600 _shargzi.tmp
M'XL(`+,(B#`"`]Q;6W?;1I)^YZ_H1*%ESR%I2YDD$\?,D2S+&>Y:EV/*F]D3
M3"P0;)`8X<*@`5$TAO]]OZKJ!D!2EIU=/ZT>;+(OU=75=?FJNME5WXR+5:Q'
MT^>JF)I9&4WU((A-[U8=#'Y0!S_^^-W39]\]/?B;>O;C\V??/__V1V6">9Y-
MU>G=0GW3Z?:_R%^GT^UTU1O_2O]#3;.@3'1:J"#VC:FYXA&/YY$ILGRE_$+I
M=/JD(Q.OT&R'+_+L%J.-2OS\IERH1RKV5UE9J##+53'7ZNK56.5ZD>7%`',[
MWKG64X-U7V=YXA<5\W"HUQWOTE(Z(;J58V--2ZJI#OTR+I311;GH>%%XI[P3
MOS@U@;_07IFB/TKUM*/PYP5S/T=#,V#X;*?C8J'3X<%.\TF<&3T\W&D?S=(L
MU\,?=SK>Z*+0^?!@E]0%-H^.75K'01'=ZN'!MYV=KG?F))OJH1?X18`/U][[
MCA=&'1)!MZN&7^1/3E#^+BZO1A?G8SZ79LUALS$6_J]:!7X*V<<Z*%21J=)H
M'*D?J[/3J^/7%^=73^G#Y<7X2L79+#-JLN*C3T+Z"@K9HHBR=*!>0B_0D:J@
MS'-2.>J'IJ2%48^743%7UY?[4*'K\?X3E92F4!/HH?)O_2CV)[$&A973A1XO
MP02@C$7NIR;4H#H=8#,D3VC0>^&@\F)=>(6^*^@;=1RY\4?4LE9=-8N2A'9%
M>D368+Y2SQ]WO%<::I[K"]Y`)>3655=.CJG6JWBYCOT[[B&E]5*]C$*HZM74
MO,K]L.A8H2O/M81^;/3V&E/JJ9=P0XN\U-)R">N0H>8J$UOQ3D2<TKRN_+R(
M@EBONY:9K16P13_>64&8^=\NL:M`HLM6=?]OOJJEL2<7YZ]'O[Q[>TR*VU.C
M\[^?OAU='9^?G/;4\?DK=7&%!G5V\>K=FU/6:\P,LC2,9F6NH3'.;W6\TSL=
ME(65B7%'B_'>*%V4Q2A\'<7Z]`[^KW%&@R"<D>"Z]5$6JX6&MZO^\CE_O__^
M'ZVY]=]'V]6;+("5"?\J!#^JS0G9X?3/TOR<O_LFKFWCNA*/'*5P;U&AK")8
MJ6ZIVE^J/Z-+$@,"74_H>&\R?RJ3W"!>W)].50*'C'^F9:QIW;?ZCS+*]:4?
MW/@S7?EQ7!3KG5W`T+D'P>PVRK.4+'UG[L(OYO=,Q5P^@M1/$.X>*9W`*Q$K
M.3@&#]MDK$;=0^;L-::?75IG^7A24F#3\'5QMGRRNY?03X/57/O3*)V9=9M0
MKF\'*LU`C;T&/D)(&F>C:+C.S1>('!OF=W[ZJSH[?ON?[RX?BAFD'6&F_`GA
M@"R/9N1PU/B7LS<L06,=M,G*/-#4LG<`K>*VD%$!J-3-'=YF9*`0*BV3B<[5
M8S//RG@J<2@`!A%!/1&G6V0WAMSR?V'_F-39V,#;T_-7<!"O+D[>G9V>7_7'
MEZ<GH]>CD]:NX##\0L_`-XZ948S.$T/M9.Q+*#U8H(\]M=#YW%\896(_+2CR
M8)GK]_L]!8G@7S^=XI.W3R!I6@847LQ"<_A7%/5-.U05Q?LT>V_BRIO%V<2/
MZ^B"#KL.>B7(0%CM*2TJ*8(<M8..]>\M^@V9:F.^\DQLT--RYZUICM!$XQQG
M>08`5KN_+05@S-/JM<CF_9"0S$ZSAV:O:;8<`>*YL-5B':W0AFYK-`)6$L6K
MG?G-)NNNO0.[!4#89@-NEV9E"IW@5!.L8*G8Q8%;8S_0!#VJ+?&J9B0=5)`E
M"8Y[:%MENK]8Q!%$!"UDTI@<%=7>@?=T;:?%I$Q^O#D-XY*P\L@-_9L__YNM
MP/,GDQPP>P5'`16-8SU5C)G@-70>^#"&1ZI<+.SGF(W10`N#HL3H%7D^\IV@
M`GMBK@S<MR9$!XJDT9"RD`2,@KY.^R;ZH'=IDIX_OIK[16MIV\4$*2XIGS[/
M.+,P:DG?U-R/PSX\4PY;(4XP(UD4A!;/8?9J.<_4-!*S-@FXQ2YA7'XA<;N(
M$CUXHJ[?"F^*>-L'F40#RJDLU6J11<"4/)5,=`[02AC1@4V:,%"CD!OS%A5R
M6`9Y2SYSTPX.%P"82[A28TH-UI=^GD+[?U)12`Z7(&M_IE,<7H%FRE!R6'5.
M=&CW/6'91!`]"1I2Q79B.&62-AD`3@7#K8*QD&@K&2`OG,4$&K<:-*E6X@=Y
MYHZ>/%`!#`U"X-0O[T`Z\I&CD<MDIADY(Q80*R!!Z5%N`L1+0Z$APGE0#!LT
MT?IM-L&4$]%AQL=6/$<DGMJ3X`#2(R_D1F]Q)*W^]!;Q2;MNU4?/3L2S?4,6
MW'O6JKZR.5,4HK>>_O/!H2/-O4<TX\B*'YR\,_B?R?#1P;_B-.WD?7;7&PH^
M4*RG232;%RS_;L<[0[Q&N'B)%.:F\]'CH)-&(HOT.-UG24(+["%#18I-*E85
M.&!@[L`Z4DK>^'_$M#GOQ+1@-G\G^;:VL/8^6+E*ND5CVNZ0-@=?4NT<DO)J
M,X6'6:]MX$2*HW$Z%'+)W]SE[-4H3Q&W!?\#GQ0CYQ3OQ.@*ZF1L[),2@>3V
ME@9L=NZ;R`SY$TUH@2EU'>N9'PL000A<P-A5%JHPIQ.3T-[I;&=%+`H(*0W3
M8BC_W0.;V#.1[4[]%)::E4@TX=&A![-T,Y6FYN'7/[R^%\2-5!S=:":49FE_
M3/X!`?FG_A-.MEG,K4TX[<=.G+[N9G0<&ZL"ZA$C85@W<0I]\"?HG))P#G6R
MW0,RT*C^84.+(I'ZS9M/LCNR\6>+HO+FQB@K'\6[6_]S8PUW)A6[B\BPKA(B
M)+P1A38(#3Q/N0%92A%!1@U:#%.,O&\CS?ZM3ML(AN$M8?&H+YSRO;GXY6(L
MP.S8AC(D?JJ%`9.5A=(6"`X&`_5;_U_FGQUVH%H=)V/%):*(G3&V#WU,J+G/
M"MYCD]XWDE28@@(^N4IRXN3;;84,`Y"+D:$TP87B3DT,I`:B0/CV$&Z"CR]@
MW1ZX)]6O+L[&ZRI(S&I=)>LJ;<G]V+O1>=H?''S__0_0"X\C[N`[?<<*4IVM
M7?_A=^@>WP]TA*6S,?BKB+6^AT\._^`CP?7J2M_1_W8T9,6C:;?`@*/ST=7I
M/];>4=-]]KK=>_9ZL_-RH_.2.Z7W<BQ=)J@N$>_&01XMBK4D=@C.B%^-RVWJ
M0STUR:SYG^G"YP!`^-HU$"EERTT$%BR:B38A`$WK$32!]BQ3=\2*T!NZ!ZPL
M'&SIV*^]L]=<C?+.+O>5OEOP>IDJEIGB'83BTVAX3[Q3[8,QW:QB+EJ9#2@T
MX'+:7`<W=874#5375$O;M]@!]DPIQP8V`[\UXAJH8T"*C!!W>ZF<L.$B*N#$
M/VS6PD@X[XEE\%+12NL'XO]&?>RW@W]N9Q-$`V&FZUSBG7+-.VO5JDS?G7ZZ
M(%@C]X9IX&-+"EJ\[7+<^NWA>X>M"8[1C6CHU5*K]@Y;24Y3O&/M>\=!O@4]
M0Q^!@H[I932!-<#^KZ/)_D"<Z!)P;"FET?I\"LY]H:KP3"&0!+)?92#)OM%Y
M%.)DLTR4C+(FQ9JWB(!"V8.0+K`[`A%6_,9E]61$S`5,,Y@6=P^B-Y.T<-LW
M7G)4S+_IJ@?^NK3+@'0?2LQP`@E&4,8<-FQL-00:U;@&@!"VM&VB&<_8?@=D
MMK#//<A&CE5D7+VT#NT9_%G5VHT:O72^[MG?=&(]V!<H;S21AJXJQN_.SH[?
MCDYMQ+FR)^NKNH0(.$G>P\CM!EV@1#GV0[<D<O4A)VRO03B`1%11%`]!I7`J
MZ@FD>EZO[B#$U(Q+'&2^6ML.4']ZWY'!'\5^*MD%`!:&N7T,E"DGN].V)LB8
M9@[/VIY(^:X="?1\J^-F/(W;683C)\=&BHLT*Y*/<93J9NX+6V%9_?STH_RY
M(4X^C$O:TD''*RMYJM20<W9S;(U.XLC<OZ604E"UA2\SQ+=1QLF'*8>#S!'Y
ME"KDFH$.,(QRA!3!`D$6ETFJ'N/("0_4!T[PZ@G'&YTG$9B'+4\(5YG8-W.'
M*L(L)@?$7<LY\!U%!V`5+/2J)B4L<S[>>/LD2S-Q]B^:HM3/-(IB@S^;N1I`
MNU0Q4&,^,:>4=&Y"66"H,)+Q@?Q1^E-$$OZ?]L%$T*^+I:9[&MZW$8&T#XC"
MWTZD=0?-@CXV$L<8C#(,A=9'R2+F]$JH<+I6=SJ8Q3<['$*GFK`]_@NX_B>;
M((R_Q.Z09",3MT@*/.,$=<Y.EY:LKXQ(381,0'@;,N9<?")76!0D21JNC\*[
MPP#LI`<=!R+;60Y6J&=S:<,A9@G8K')(N.D(`+,I;*-O,U."4$<;R24T#0XW
M;X_IP1=3;NT&WJ39DJC<^4P77HBY%4VU.DI'DMWHE,._&J6FH*H#%U]("+9`
M06(9G5T@8H$T]DW5`LG.&!XUAM9T$Y=B#38=1*:8KL`#UU1,ENA)-H6"^Y0\
MVUO".*-,K:TY8J@1%V%67*D`'1S&)">F^7:0T#U+T!(AM<JD:F-E9.KO60;5
MGI24A`S<06V(XS$GC)M6]F0;(2(@T5=6\TY7J@O!/#.:"NFYG@BCEBG0:RHJ
M5)VB@LKQ^&0T4HO,1'+3.0K)0-F]B/08A<*2>[R=N<\BDK)!S.D[81'P^1Y6
M;>0J@,[H'/Q2OE,T92`PC3-<"'2TIA,#N]NKHEOHC;,MF[^(*`9DDA2OI!:5
M93=26JL]'1^`%:R5'E='+%;E#3D5@#?N`1-`6[",ER417=6&))#-C8!K?>O'
M)7E&MFNN2K1R,;N>VP"T)%Z9R!HI"8Z%/O<!YU("2IF47Q@:@U_XNHQ0F-,7
MX5;JA;P?*R&RPA`GM6]:ZL1N6`2X&9;KZCS<&.?G2\X*J6XI,K#6SM6V5&M.
M"PP@9RP7WYS"/_:-.P`Y./(8E'1/IX(=;G4NBW(L>"+7XVV#=)5;XI-6IWH?
MD>[1J+8:P,/G*Z3>6&(&MJA$!?0(EC).-PC&VM-CSBPQT^1:9+2LD!E?'B',
M?"#P'M,%&U36$^<!&K198[.2^F!I3KV9A)TF16<J!CCU;\;"F"B6UPZ3W(''
MZF2RAB%:AQV,)#B<S,+[9R4YC\)LZ%`KR;%.RR4!]2)<5&E=T'NWYB9:$(/T
MOS39:Y>C*$7@T+$%JZXUU4NBM-GJY%ZY1`C&002I:-,\$<``6$J0XVLVT2N*
MD*;&W4@?;`3@3K(HNS>1E20$MEQ$A^!-MFH)[B9DR_+X&UOV>[&$O3VO3'G;
M\S"*U:-V`0ED&`%LC0';[<2+CFU;QI(;Y$'KVD<W#+9/NGXIT%479?Z`Z^(P
M_UQ=#_81^:$`6LR%L6CMR2E'(F#34]<O!H/!S\U8O^7N'2"T=W%/]P6.B'<C
ML](X'!]#Q3MP9:@%UM@PR</A7'L4HFW,8'1'[UI(.9<1X;-WK2)["W<B0M8[
MI8N**)V1NF[5A)I[M,&P>2*TU?7BXUU/=[IF+E%V^K!Q7/>M)LHZ&#;W7#15
M0/_NS!<[,U\,Z_5JZ+X[[^G.O*<R3T3ZF1>+15-ZA6K6Q2Z)_Q24J8I'9V=J
M),LP(*,Z4L1ON:@A&6S?G-9;KL0>/!DLM%KEA_8N]PY^KC9N"JG\3I?CMACM
MQD/7AA#`;NI=U#EF*[%PBNE`C204%C>X*$=1J0Q#0IR`]HS#.,3YC>8RKNR1
M-V;[@8)/V(E:H(L00U'X>@)\=M/G6?N"F2:@2%<M")5R<;C_6(@.U)XWYH@E
M(=8\H00"JPBVE+O&&H*ZA0P5"FS0[BEZ\L"UDUSJ*VUW7J.?1MR\>>?4P[)`
M(DZ.E7<DY2`2"$O9U8S6-MF3Z+R$S(S^PP@DHU7OD8)Q94+P[[KOWS<YD\=(
M@9Y3`-'J:Z_XFH4@Y\=J[2*>U)LY:0S#**!'C+ZY'_+`*\7^@FY>*!/7?Y1\
M:2EJ#$8E8;.HYZ4(D'='@$98%$<OVB#``%H<\P5)SP9MTE"I*S*7&3PQ2<9)
M0A+^AMA&*LS4Z5H3>LE1WX**UK49)SJL,P)ZY)6>T?#N4TL@R!*IB49\Y^DJ
MHQNE2KKMWSOD=WM[!T.U=VA?/+@W$<QAI;9:H8/5[[^/ZL+VU)QD\5@OJJ>/
MUA^K>W%6DR-9)%UG/;,W7U2\X&RAQ=>&FE7MXB?)K>&L\51.31MF.BY*;I1`
M-XE@(YO!^:-D=DEMCF\YGV8Q=ROI_J>1K>C\J]XG'QKS;319)60R;6[?6KDA
M/\<5%1%'Y$^R6RWZ;E/&:5WFWDC+K!]@+2"'%0,<3]MN8XE$T*J7C05-CDY5
M61V&,#6&_]@LW<RP3R3+S'7B+UHY`"682)9]\I"M&Z1]`.$X6RQ6G./]A*33
M-P:J*#Z"L,*2XS@93:?;/&K8RB;M+81/-^[;70RTC8C.3S>NXIO'L)3N4F(O
M1)CMI040E/00N+YZ-:8[K>?])RUE;&&[3[M&BT%VRNCMSAV%'K0P`\V@MLKC
M&TN("DZ%[/:>X-GH7WV1]3%U?[&%0A]>IAUV[UGD4\;0X/]/F\$7+2R_.?[O
MBW=7]CDJWQ\B!/GR]D3"%+LA&R:AC_Q<@:^-^-4CU+M^]3SA8F6`^7;*,IH6
M<_*>1)B_#+_];A%TO`R)9C2%,>0`FVI(^=B"X"I&J$[S<F-K'$REWY#J\+L/
M>I>_.^RP0PE0NKG&QJB.-\_"D+#-4/4/HI3W3QZ2WLQT*#&2BN00^=)#EQ-4
MYP,<FN7^8FZ+F'(SX2'HT+5/L#)%KHM@/CQ$?GOO_89>(H^$=\K#,HX579YJ
MTW/7X(E.,F&(DI_A@;Y3B[@TBCXD48I/=.7:4'.HLN;*_.3>BXB7@EOK==1G
M_G7=)"GIL'C([(T6=.8><WX^/490?-WT59-O"5URQQ2DN39#^2O4,%E02Q2(
M=I5I1-7QYTXO79;<E3K#DMRE)%22Z$QI;CHK$2<V:QIN.8(^]`Z%JC:,#Z0D
MW?;&#(BX_LBUN3F_U<9T>LW$QF`K%'R94MCGE)B`\?[,C[@&P&D[H>R#P8%.
M8`_9@KX]J%M.O:#O.0R2<G>)8<QGU#IAUH[/(?D`/8X'M"V0&G2X*/$9'+8)
M,C)SVL?S16M!Q6GO0UJQK;7R'HRH2$PX(C9'S>\;PD(,N?5QX_4'CX_LM([]
MVJ8510\3LZZ7CXX=SD9G^WE9,Z1?G_3&_:%=[U,+/KSB9R])/Y^B9T0D/;AQ
ML1P#S*X_Z+K29@;\(KE5T:_L^+X=N@:]RIX@G"0TP5X$VG%K&4!PLVG!VF]M
MC6C;1_0:8ZM-D"Q5RFCR.$V>27.5!W#R,M?C<C(6,F-7#7,_#=GI!9.'[`O9
M/S[CC^(AGPT.]9U[4RL3W%$<"1"RC?;_=76P[K:5W(&IS9I#Y7TX6G<?LHYV
M0*AG];^U//8'/]0\]HE%)M9MVV;CRNP[+49/[L$3DSNH]UR3V&2"R;';;7&>
M4U[/=]_*>T/O$Y1G0JG6@81D_FU(QGG?0Y*K^]?5H6/BBTONWG.O"?U)R7W:
M*WU2<O%G2NXSA->2W[=6#_Z?"R^E'U3$\D+T00G60>%^Z=7=Z^JOK>U\4>G=
M[W!VMMM([Z/FVB=[33[*@2,4\GUG7LI+,`?_/R'$P/Y48E.&'?@\I*DE74)7
M119,]:*8DY6V%[6^6G[&8M]@TE6=E%>6F05&'%W.*,N5J.->L4VUX<=R1*-]
M&TT5%<6/3=+ZB@WAQ?!U%<DF]]G]\\,,>IOD:BTM@KP2_4IASABCCG=J[T"B
MW=\18.CJ0CU"&,D*?M!!V`,9.?V@67ZE1'*(*131[WD"_M#=?C5K7Z8B[=HY
ME1?]OD"<KSKN/<ZM_(I'\1OIUJ]ZK.;F;C%(/];IK)AC!VC*RUASY%Y7SP9_
M713,&/'-C/$'HDCL$Q77TZ)"36TJ3.-+I(4?^Z$D!7E^B\++J)=DU%RJ;)=&
M^1D8_5IBO_FE]@`'T!0V7=V%:KZ,2>2=+#7_3RM7T],V$$3O57_$%B'12DE*
MG`2*.55MD9#:'DJ%*@$%.]ZD!L>.[(00(?Y[Y\W,.AL;3BTWG&2]'[.S;^>]
M&4<K+9Q\K>;OS9VU3"7.-!RKNO&.A`HY/+'ZHW0QA!:Y1]ZR+F#*21[',,&Q
MWDS79FH!^9TX7B*52;1F8G4EW4(`D]8X)D\P<_K=%FB:EP7YGEDF%XVG1^7`
M+MT/GQ@AN?^4@&*<Y*F$O>RMF-XCA(/P6H^[E_6C7?]WB/VP&IY#Q3=>KM#C
MTYY*?9.T=-D]BX4$_Z75AT7SN=C/?_CCV()4$OA:3%NE!'89(6K2'.H*^(4%
M-I4%M+2`ABD^\U$D$>U-YLXRSRU2,NFJ3L[*1B5N:UA'N9;)Q55RYF#4SE?-
M>MHJ-)6:W<0D^2JE6SI'F^OEH+MD5A6.!JDVJ\-:D48"R\5=?.7:/G5A$(EI
M4*.#P7SLOK(]!P?>'`3&!(.P3]-PV)@#U3:Z5)N(]IMP`\Q.PXHX38/;]+EV
M\L"T<6T=#]_D%K534LQ%,O:&8"H-IK*P@@!\+24SSTA7));HXM0TTH[)5^W1
MCC:CW:=UWN^'PX,P	&6XL;O>Z]E$A5+4MFW^OLFXOE/;P#>A#'5QT1,67D
M5:IVPIB+`<]ZU$F&#*(DF;(_X]RV,>WU]8QY"<YS>W%HP\;0]LF2PU%S(7^0
M:T_+=CA")01>#-OS,ZUW#;QWT<;I'X;]83@*&N\ZH<'AJ-KO'0:2R2:[(E'2
M4<MKJ)I)AO?6[3!>4!;\-C+IWM%.$NT6>5DW/^2J$>N&,X>`!R.*K:BVB@DK
M?9:T?8]]#;,*,)SXQ$R+(I$5?#99BF/W=<+M+61/BQ(;TK!0G@>&X+F3$$D,
M)IW0&0(E=#I#01!;PQ#L7.:\&S,;>#,+]_0A#()P-&C,[.DVSMFL6FB^;ZD!
M!#B]H&\4;3[P$0A@'K:'/L72WI`UF]NJWI=BIHD1Q#+)R%1I_1R$83*-CTS>
ME!R4&6<VRMW/:["$@W-B(X3E67B`[H$[H_.EI`$A]4HZ@/?#W'F!6?`#`10`
M2.(:]4EFH2.J^;),D0?E::JQ,:D9'$L$U2XUV`P;<"0&?T';//,O1:*O9&<L
M$!6,1R[8H9Y::5[)BS43>%9[RYJE)-F0OJ(5@YBW8,RP%?)SJBV@8&KFFA;L
MVFQ=TGJ]NIL@5,D!Y99&2V:L0-O<T#>IJPRV]Y@S(CM<<3*V1GRU*6K'9=`[
M-/U,YWZ*7A</RH(3;./Z74@(<;A^;VL.3[44@CN$!:1M%4;H\-RHAO]!CFJF
MS0"<("29^!%0J:SCP%PTIRTU+U.<"%B-E2)"R^2MR,S1!'9^=F\K+K.#[38O
M;??3^9D!0N`'_2/S<5Z:HQ%9NJ$+1H(33@OPR$M[K<H/.+\E14*KN/`I+J5@
MOIV\URH&[O`&/.NTVH`R#N;N"G&H^#<5=2[Y@6$7SH#L'Y-)2)<<MG-!HK^%
MJ"Q4+=1K8*A_+'ZDE37."=7PJ1M"96%_=6-R=;8KMMYEGQ*:H7[&R*A+0Y^$
M)D\S?1HM%T6W(COV'\XB``."95@%`K3=Q&8I8",]V_E-W=^A#[[D2?CJ+QPL
&VI802@``
`
end
SHAR_EOF
echo 'gunzipping file tdsguide.cls' &&
gzip -d < _shargzi.tmp > 'tdsguide.cls' && rm -f _shargzi.tmp &&
$shar_touch -am 1020163895 'tdsguide.cls' &&
chmod 0644 'tdsguide.cls' ||
echo 'restore of tdsguide.cls failed'
shar_count="`wc -c < 'tdsguide.cls'`"
test 18960 -eq "$shar_count" ||
echo "tdsguide.cls: original size 18960, current size $shar_count"
fi
# ============= fancyheadings.sty ==============
if test -f 'fancyheadings.sty' && test X"$1" != X"-c"; then
echo 'x - skipping fancyheadings.sty (file already exists)'
else
echo 'x - extracting fancyheadings.sty (gzipped)'
sed 's/^X//' << 'SHAR_EOF' | uudecode &&
begin 600 _shargzi.tmp
M'XL(`&#-WB\"`YU86X_;MA)^]Z^8P%AD@^,HZ[WD[&Z!0NTI"K1`F^`D?0I3
ME*8H6X@DZI#4KC>"_WMG2.IJ.<GIDT1J+M_,D'/1&:2\%$\[R9.LW)K(V"=X
MD-IDJH1U='>Y.(.?B0"(`O>!EPFD2EE\C_#CVTQ:>.`EO%'&ZKI8P4^RLJ!2
M^(\JJAK)X)W(9"GD"OXH,R<:5>#W/ZR68F=)!D]JGG,4LKY>P=OH300_JCW<
M7D07MW<KN+JYN(7W/[8,*WB_D_"[M#NI<T1C4,)[F<MJITIY#_^Z6K^\NGAY
M<[6^O7@=087X8F$B7==1F<-Y(1[X_IFIR^LR?X:;69D^(YH7*.6=K&#]>@7K
MN[MK7/9NN+Y':S1JM[1.E8;:2'C,[`Z8ED0G"ZZW61F$7-YY(?<C*3?W\$.2
MR`00.;`LM:I*<\71(%QLE'4+YU]<NT7%MQ*$*HI@YAMAX7I.].M[^*\T&`F#
M0<PEF(H+?(.L;./V*L1LA!YE(!,12Q=X_)2H>I/+;NM+2O]]#V+'RRU:Q')I
M65Q\0BMV#%WA7L`JI&>)3-M/#:LTHA"VHSD@$13\DX3,0J&T!*TVM:%3\9,4
M<#.G]Q;U=M'P!O'";)3Z]`J?7-M[0)U9B4Z.$6#%J\IY]9SDHZ2LJ)2VO+3Y
MTPOG"A</HD0'O3)>+@'T8K*@1JL"*A.W-P6R%&4AZQ/(?68LG#_N,K$#LU-U
MGL`&Q>I:>G1Y#@85)EPG(')NC#0OZ/+\QI_@:NULO!G;>'?O3CFZJU*&'*QE
M*1_#46@8@=!U+A^S!'W8#,]+%)%D@9!1OS^P>`K(Q$0)2+($2F7A4:%Y)!WO
MT),_R43B<D&5<^3`X.<R`I3U:XVNG$>Y]C![/]'%;J,-C]R4SRUH:2QZ/@'\
M;.J-D?^K94D19H37Z6F<XL-SEU*^H._2Z_,BA#R2X*`?AMM^9TX9^H`");7&
MO*%J@WXPF$;PM),GO!."ZFBQ<,<X)[\W+,[24NXMGAC]`5=[MXU1B)_\V\%3
MAP\?ENN/R\N&;=V>]#*6ZT/84&'CLF/S4I;KK[*LD<7SB'E@H@,FQL#$##`Q
MU2*.@(D)L%,L/3`]#TQWP/08F)X!IJ=:]!$P/0%VBJ4'EE,^G`DE;?M0NK<^
ME+2<AM+)&,;%;PQ#23O#4)Y@&81R'ICH@(DQ,#$#3$RUB"-@8@+L%,L@E//`
M=`=,CX'I&6!ZJD4?`=,38*=8/#!,BDE6R'*<$0?[1#RW[^[W*2;W\10G,?5[
M68K)-^Z3CS>C7R_79/Z(9+EF,C=R><G2#&TXHTZ)TCJ50NVJ^`/7&68D3$2^
MTOC\'2HYI40>J0BFQ?[<8ATM?:$:EG5J;9QXE"&X%2J1E*;__/,W.#<*M['K
MD)5)(<VP\H^U^4*1I<!](MYPFQ4@M*(:!AQ<A[)1-=4V5-0;'SM+&A:2O]`+
MWPEL."99K,U8G20>HF9].%M0O[-G*,-5[83%Z->6[@Q^__G=.U>S*A)9VN_@
M,KJXHU[E4B[`\\:BUIBI/TM6*EWPW+W&@W=R^(`JS4@K;0;YYR3S1:N"Q(Y`
M('&(U2]4YWB>?>9MN6N=U77&8/%^4,D8'2^XB*XKNQ@?2/8Y7LP<Q7[[B'KA
MB]"'P1%K\/:9G.ELN[/4MAP^-L=?<YGZCU0+(8NPM,NBHIZOA+_^<I3/G[MP
M&NQ'.UGT&1O<<@6=!-I22>)I%Z'TX/75)W!UFN=@]:"_"=<00X`U@CK`Y1,K
MX@H)51<,(T4?#W#FSVU9%QNI%R&SN?"^K3%\:NN&"SS>X1+@6?/M,VQQ@O'W
M@Z"L0.!I(<HR068'Q45_17<I=^.2=93N</CO],:!@DK-#K4S+.=5U^9#5?L.
MA.3@9<2D@(/1;H,#$1ZVSU(KH".\HMY=@7J@(:BJZ/X[AD3AO:3;LL6&47,K
MB9MZ'%U(8Z@_#.D\[N8^2E'+J^7U\@:S*G.:K.K37#.\T.P!/S>.:($^1=78
MTW.-RP^;CTW/A-'5?(NC@;,94QUUHU@<V(X<LSC%X]V)QBRO`D?+D']=%?EY
M>=UJ.G37[W!8WF!PAV;[&O-_F]W>QH4CG]AO_X']]I_9;[_%_F"VL[IU13,I
M16YN&Z>>F6R49F@P+1E./V3/A"7VCPX1L`?S*:M>3L:4%DSKQ5DPXX0WDP,)
MC!=_$5V%=-\5%=QN=4_*=\`_0=H9--;A1,R+[ZS`4=!!;\X6U!-UU:MI9TZ,
MBYN*P[(=,$M>R$-S.!N,K1,!@1#Y2<]@'EU26]1.SGC]Z@K'-X'@R)&8S'"(
MC9$<WQ)9V=WW5"^`LEZ0P79D`:QE@64YYWLJ:K"D3JHY8!GVZFA`.];H4]>\
M'OB>BF70U+&?5H:JFC"U.$./3(-O,*WP*COO.NU!8`1L9-KBI".=65_5!D>>
M'&EPOA.&`CO\0<!DF83=,_>;@0W_'B`B7N>6?B,,?B(LB,:?JX7O=[MCQ@8W
M)>74SG2DI+\_TE0&_(4;'U1?=KNE_V>#*W_WVI<@L6,=;(X@T,^-`8*.OK\4
M7_[OTQ)@Q0XC8E>/6)SC;COFME-E.\2Q6./7(7^82[K$WO/[E1]EVLEAPD]=
MQ#$`[03(`$`&`%+W\$8"CA&T`OQ*!@12]_A00#OST-+EPM&_1+Q`QO>M[OZX
M!M33ZWEZ3^8XB-4UK"[(.;8!^YC^L@F5L_:EC9!?^635_I)D,;[E>"#=;OMO
MDL7XYG>'$@.L_H=F._/L>WF^I\,Z2/``ZVUG3?_KLV?K%'Z)K?OCU8]8"*;`
1A@W"A`5AQ/H;(NO7O.06``"^
`
end
SHAR_EOF
echo 'gunzipping file fancyheadings.sty' &&
gzip -d < _shargzi.tmp > 'fancyheadings.sty' && rm -f _shargzi.tmp &&
$shar_touch -am 0614075295 'fancyheadings.sty' &&
chmod 0664 'fancyheadings.sty' ||
echo 'restore of fancyheadings.sty failed'
shar_count="`wc -c < 'fancyheadings.sty'`"
test 5860 -eq "$shar_count" ||
echo "fancyheadings.sty: original size 5860, current size $shar_count"
fi
# ============= mflogo.sty ==============
if test -f 'mflogo.sty' && test X"$1" != X"-c"; then
echo 'x - skipping mflogo.sty (file already exists)'
else
echo 'x - extracting mflogo.sty (gzipped)'
sed 's/^X//' << 'SHAR_EOF' | uudecode &&
begin 600 _shargzi.tmp
M'XL(`&#-WB\"`WU5_5?C1!3]G;_B*59`ET+KK@HBVBV%18%VH<5=]ZXR35[;
ML4DFS$R`&NO?[F22?KA[-*?GY.2^^]Y]'S.OM1IMU&K4GTA#[C>2$=-=/(K4
M6-6-G6T]HS$GK(7ED%1"1XV#@^=[C?V]1N/8.SY*.R$[80I58*R6*6561M+.
M:+M9;TYVZ@6I5&!26HYE(B(R*M,!>S5#CZSY<$&KI$/[1+3M@ZO42I680[I+
M13`58][:69#/+WO=ZW[KJD]7W?YYN^.CO%49"<V4*$LBBM2CR]PJ"F61WC"S
M[-*M*O7)G2J],CHE4B-?T(?)&N:"7I@"E<Z<=6(+$>EL,O&X[]Y:!<OBT9X(
M+0++NB^&D8]#^2!-6>\&PC"Y!RV\1!LGZ.`49WB%<_R$GW&!2URABQY>XQHW
MZ&.`6_R"-WB+7WT<NG`EKL41&")`",8(8TP@\0>FB!`C@4**>V@86&1XP".>
M,,.?99P35Z\U5#W81P--?(7G>(&O\0V^Q4')ZSP%D8B%[Y7C?>+I)RISA=%]
MIER#"9]Z\)4P$]I.LGC(>H>P6>FH*!)ZJ?.9?_78]3BQ"[#F7ZW8=<B()"S!
MSTO_5E`,400E'UO>>,$C2ZF;>^*IVQZ\]C-:H-BI_(V;@S332NJ+4C_*EJ4[
M\$O_:JLX%BOP6>E_*9,U+G9+?R67V3NP[E\W*I+ADHN]TK^M(M^Y"CTLJ1S+
M8&G`=U51QKB#)2KPJ.K_?2:BU9R^]Z\SS>Z.ZHJ-8P^^SMCX,<5"3PD_+/3C
MV'5;NJ,M+.''5?^&[HQ.N6CJ.P^^=)\F*H;HE5#ZEUU=</&^;)740>:./C]Y
MZF\>'"2AFU^@='DR?R_]S[1X6)O?W;_U2VKNP5O6[GJY/(?%><%?'^H77,P]
MM2^CD%=-_7N^@9!'*&YD(F+.5[=RS1*ZEN5^H^V_V&LVUBP/+F_7N+Q1;SJT
MI]6##-GTR@54!9N_6P:!<;N)USU+9(/^ZVFKI%I'(5V(/K]I,E7[[?T&["QE
ME=F\$CQ<K.0M%_!C%3I:)G),VX-(RRG=2K:3G:JBPG4D8AG-\IJ/X,0Y"50H
MDW$^F/OORNX+@^&(`UO`503+3[8PY4BUN^&!1;J`*L;R>[.1YVN*M-F85Y3+
MTWP5Z++3;\VQNP).NU?]);/W?\Q>]\8S.7$%I)E=;-F.6Q1N>7_T'U;?^`="
'-YSBY@8``,VQ
`
end
SHAR_EOF
echo 'gunzipping file mflogo.sty' &&
gzip -d < _shargzi.tmp > 'mflogo.sty' && rm -f _shargzi.tmp &&
$shar_touch -am 0614075295 'mflogo.sty' &&
chmod 0664 'mflogo.sty' ||
echo 'restore of mflogo.sty failed'
shar_count="`wc -c < 'mflogo.sty'`"
test 1766 -eq "$shar_count" ||
echo "mflogo.sty: original size 1766, current size $shar_count"
fi
# ============= path.sty ==============
if test -f 'path.sty' && test X"$1" != X"-c"; then
echo 'x - skipping path.sty (file already exists)'
else
echo 'x - extracting path.sty (gzipped)'
sed 's/^X//' << 'SHAR_EOF' | uudecode &&
begin 600 _shargzi.tmp
M'XL(`&#-WB\"`ZU;;7,;-Y+^KE^!Q,>3F)!<49+CK*5HZ?AE[;N4-V4[EU29
MV3,X`Y(H#0>S@QE)7,7WV^_I!C"#(2G*6[7>+8>B,`WTV]-/-\:]7D^(2:5N
MYSI3=P<]^A%_9%TM32F:/S^(KW]>ZDP7XH-<9Z;\>M`LO5:EU2:/EYZ.CL^B
M%:FLE!`=82>/Q7_5V5J,__SGDVAEI5>;*\=/GAX_$2]??(B6T5ESV2[%LD)6
MRY&MUM$JF::ELC86]F&IQ'.S*NI*E>*YRJM2-<MW_'GW^L>WSP?BEURSDM5:
MF+GXR>2IR?<]]G*QE"OQ6F?9@ZL&XGU=EFHM/OQZ<BR.7_XV$"_?_O6G9V]?
MQ%91F2J6)E>1(BI[BD_?GIV))]^?B;.ST_&3V)"OGOTF-@SY2MYV'CG%_[Z/
M'DF6*KFR]2IZY&P\/CL5IR=C,7[R^'LQ/GU\\EWTA%I)G74W^7GDXF/R/_)V
M]&XYRY/1LV3TRY4X>I/#YKFJ^O&6)E65G&618F_>_^U/S]X_?_,F6G:EUC>F
M3&VT#T6`H!`8-,$P$!0#HOW(G_9Y(-4V*56%X)7E>M#Y42L;'<#616'*2J7M
M`=:=!:E);%7J?-$LN&O"+)S/#L32V$KXSS)/A1J2!?<=T<>PL@@"/%`9,5,B
M,]C([8?OE[+:)R&1M<4C&M$S*Y6\HD,6I8'15U;,D>,?U&^C?0+>FY6BO+2B
MA%&A4&=[N3^#5)Z8FCROTG.!AQ4](*H;(]2M7!69LD_I<1;QBJR>P2Z]\I\C
MG>-L*UGIJU&=ZR%295:7BU$Z*T:IZBT4?I>O1XE%1$U*E4GZ/,(/C;1[_JST
M8EFMARL#JPP7-R.X/!G9]6IF,@T)B5D]).'#4EMVJDC5'&:%#<1*)J49B"F%
MW1^CT>B/O7%G]4IGLB1O_B1A_D,KI@"8&3\99#WD5ZLJ<CZ,J6XKH7/W>5VH
MFU)SV)F\VGL*F67FAJ)AN2Z6*A]FA)5MG$"MO?L7=9Y4M:1T`73(4B;8U8X>
MMA[;3=9912H0H.Z6)+3=F[ML^U1(^]".TXV\%G_\WU>3_^C]_3^_.>K_[[>?
MAC\\NOOZ\\??GYX?7EP.1G^9_NF/AR2^-C<*_AJ(M:F17WSJ?*&$KG`<D2N5
MJG3`N>6#_.F_?,9O)[VO1M\^]-B-J3,R@=6+G*()!Z`H(+M.1$]\)4;B9JF3
MY5Y\,*N5R5&*39+4)042JDU2E2;7B6"`;S#H"YV;(;PI`B-?6A0YX$!*X883
M[@W+<E&O4)DM*;1E%T)-SK*]9D'E%3G!1P:]`)AR=XQAS=X0G].10VJ%<SGD
MQI/"$!K>:*OVY_HBUW.-**E((0);(=[D*%!EI9,:,#`0,XG"FTF[WT\RITVA
M#9"+G`ZM&EL[F73,\B%`OE9T$H`+_M*49:)4_ZAU22%K'\;/J2U4HF5&/FBV
M1S&HU1?A9D&6UXFB?4F=4E'\H;31]C/EBA6,M$\0U,Q%6>>PP,S4%;FI%*Y"
M64`:_(J@SS@=]V,(H254KB@J.:BF`.`IVT/9RH[^=3O,9699-W*%B\`',)PV
M'WUYR5G)=1,"",R?,XF_82\!L'FV>D^?9NL'?:AS4!,1*/-#RZ5+`BY57R(=
M9,AE<+7.U$>8=$`[#?#A]SO\]?E+4*0AHW.M".)FYAI?HJ1!7XK\Y^^>#\??
M[<V7($$Z;\PUPE1<RZPFSFBH^,&&L_5#>$3)@:<H:U"K&%XK6$26J?CE[9O?
MQ$TBCHB=[L=8<*"^J"MT4-1$U!79'^*HW((+,KME8-FO45-E?4AP0IFT3IPF
M[\Q,E=5^+I>9:[D&X6C,XP_EW"($_G/0$S_\6_ZPJ-T55-O*E.M@44X^1WSX
MF6<H0K($=D.[RE":NI70EUH&5]3$#3R;`L\R4SC]WZK,`M]?C\0KI)3X42FD
MRL6,_C-94;#7E5R.5%I?>@PE^*G1V%TKMSDA=*%4AMWF`OT6A+3%`H@I&68&
M#H%N-,XL4>XMNW*JY[<4&I7BV,<B^@5(`(0HB>/N+$&NFFC>C=S))6>`=+/P
M9+=!@1P*%T_.?%4BDLR[#PD!I@4ZC:Q:'R-`?F4,9)O5MN9*B#"[LN"$#AD9
M?W%40#]^9W$PP%=";FF1F&$,>L!8&_I!"C'Y>I&MG0Y<?)PY24&P(G6[A)!*
M.(;K#`P!R96W2EOIJ:.`A5&5<H_II\==4DE!`;@$`J3-P($\_OK5CV)6:Y#)
MNC#.)#I5TCH'N^QVR`4)FR3[W)F'XFB%SHRL4"<)J,Z\SF`#'(-^-<^D1PK-
M:NM<SEP>(UIPXA1F1FQDV-71KVI9*A6SG[^+C^+W`4G(##BVF4,*61=^FS!-
M1$M(-4ASBRPSA#T@I_)!Z7M%MW]G=[(AX5A#^B`PVA:'<HD2^#S\5:!QTN"+
M:/^<50EL?3O(VG)H%Z"44)FR`#IV!C\`JZ41-\A+'USXB\"O\8K;$A8D<YKL
M6CGX]7L@,$D<?54JJ*[$PO<QI(P;.B'D4]VT-%SVEDJFE()4!B#BXU\59Z',
MH=970GSS#4O]/6B4B_\&?```2F#,Q14^3]#;U:N92_X5A*$1S$WIF3NG4S./
M(NS`_]^I:\T:+3U8'97$^BDK:$H%R%9E_REO2?,N\?'D9`@90Q*!DXBC(!N>
MVSC"P($'G1F9,:/."_XG86+<Y]"8HH=@X\MKHU/R#+,4Z4H)$FV!0\$B*\79
MBX567BMO1V:+%2,EA9C7YZ0O7MX6%$J^7W6P*^>0LS3F2AP!AG1U:$-OU0<H
M)0&<B4FYAMX#!I9HNPR-#GEJIG(\R%'H`A>:--3*'^*T+SAHH32<Y^H?AW>!
M!!Q^/K2#X/>C)3IU[%/G#%]]J,2`1%VI9X$N-A"#,T7[(,J9J""&]#^)*F1(
MZY3BY1=*-NYQ@+*]@>/]3DA)D60-BW-4%.%(Z(72@8S6>*A4*X1=2N%I:"*1
M$)AZ?<[ZB!/ZM:MCBEH<JNWSTJSX*YK:^"I'IV5@1F*FAH*NHM[J+TZ2"Z-3
M\?'X=/A")11&8PJCGUWBT.CN631@($<@)J&N],Q,@T3?DC4("5QQRKOUMP`^
M*^[!6NN3'F`%-149[/$L!=(#RJ[5-=D.5N`DG2YGYO;N\SG+)7S6W`<!XJM2
M.FG=K7B.X%+;D>P@B5*(CGUM$E<*J7BY"(,J72%.+YC.J:;R:XVVE%Q$IWZA
MY2(W5MNGXD/($S?*8,$#9WZ*>-O9!R6HQ+E(D^YVT,?KB=P=S4<L`">8(3D&
MHAB)L\=G_?/6VFAC_/PKEC)#T'"$L!^@%!3FF.%@])G/A"!H17[<T!S=H5R4
MLF"K$.R;&[0\-+J""PC?PED%#AM2<\?,C?=W^[J:'[S1?D_)Y\ICA[`BS7-T
M0><1=T9^91$?@K1H)\]>.SP>9E(YEZ(Z+Q5-#!-B$MOY246H46=+3GN"B(R5
M*JHA<*]59+-*>4K=E1!^R55T"@\I7G6E"U<$7>Z=`,)/AW]+*LX],3Y]>O;X
MZ9BQ_)4W`!5YU3"0T;^3*4\UP"?5..64)WCC[^Y"@];45JXS%^[NA$O5Y>=>
M4\4]H_C$47[H!@0@:X4I01[9HZ7)8`HTM[EKP*6XRNITH9CK,"T\M$R*)6BT
MG%$(:QI?H?QPB9$)$++(`/L`>!XD3[`\0Q,+CQPQ'T&9OP8!$Y\^)50\T#>E
MAX=;F]M^`R2`SI+T)6F6)LU+?*+J&18@TC]-#D,>T/"\[\87/,E%+2'8YZ;8
MERUR*9=/-L3=%&$R]>7PTP3V:G\0/XCQ^`!P5TTG)DOQM:^:/X09DXL-3V]S
M[)!D87X]=97X6I::;C`<H(A&:S?FIZ/DZL8MG283%M_]BO,GW@EX:@P"+6]D
M!S07:'1R?\%!%9\F$'-'<8%Y-24"4<LJGL+9T"S13(Q&8=::1',NL-2V_:+J
MQ[G'Y]/<T>P<<H3#_JIXUDE'<:;?]K/?7#G>0;<7AE&7AD"HF5SX:7R)S[:0
M]`!J&YU@!H*3+TI3%XV_$-GDL..#Z8*XT=0_:(L)HOE.1)[U*T^G=#%PVW,/
M3-V>O-RM1FEV.WA]MH:-;#.O6L.9>-&DTI-\4NI);%Z(0%J$$M=BU4Q5-TKE
M$8Z1WI`*`+Q@LUXR_G>Z/4?:"Z.YV!U,6>7-`_::YR]H.WL9?CY@V.NY6H>S
MLY[BB.=LE$J1%DY2?Q`>V:G"D:1YI6,U[*B^=V'S&.<'R$!NYS3Z]8%0108+
MAR8/TS-WL9.;X9'/$<L./.C.QULA_`N'?8WC)AN.([+#06:YG`):E..I(*Z5
M;FT/`5&*^#"/6ZH-J_NN,7HZI!9;9,-;T:D>C7N;_KG*W17,CF,-0N1M^<JA
M01`1\C*-M*1Y;$*`,/!!1Z'6#N:9+D>."XVUSFFTE7`9B0]ZU]4GG./1HS&K
MM"OTO/`=9]_G&6?PCH2HGW5>8OSE:U!NX[:<HVFHD;J6,A;D4B""<G=WU\UG
MOI@5E=39L!D-=:3XR[DH8/Y1:U6Y416-#ARU<XR_\^1F[E*;4Y=YDP["6;H!
MI7B@VK7^Q%O_46/]2QK^;-O?[SQ;NVD?!QK*AE*".SVQE#3\QWE5NM&K;`M!
MU0?EUR/0-2(!DB^[J2*W'FSJ"45U[J)N6U!`K([>7GD<"^KFQM<+5C'Z<=P[
MV#E-[)$^V'@-]U3)<N"8H1MQ@6*Z@$G-CBV#A4$!L._DMJ+2SU5C<^%495;=
MMWUS$^3:R`CY82MJ$MIRI^U]0MH;3;K9Z=2"QK)NM$0WOO>*N0"YG2,;P?RJ
M]:7_D4Q26WZ/H73#!L%7-O?(B-HHUP#XZ2C/ADHBTXJOYWS,WR?&30]O(]Y^
MG_V;PLTN[V+_QN4"<H$7W4V[TU'QX)^[*9W#[_'Y[G/WY\^]+XF-C2S<BI*Y
MWHYX#D:E^=T)@I9H3,IWKC3SF/N8)72CB-V6$@%A:_D!)?Z&S(1Z%$LBT87N
M.`W-B6;$1_Q\5J5;6I"V&U]VS-/C2:/!AHJ&*7D[GE_1P+<B"E%DH`DBK<M0
MWZ:H2MU@Z8D[ZI0_<V^^!>3J%BKQB$#S2$J5U-""+NNL(T/FG'YAP%Q3C;"!
MTT*\];.=0,PI&4V^C>I;U`ZM=MQD^G+LU/2W!0=;EG7DV])]JE#SN4JJT7XH
M!X6\VP'N**VQR</G7LL=,S=&N=K!$-H`V2JKFS2S#2LNG5S2JH8"<C<F4#<K
MTY:%WAZ^0*;O5H4C7W*]%:7M"MH<6KO2[D^OTKZWWJ:*$0$DZOYF'HS>OI01
MZ%-WR.GDR]RIQE,\;@"[JYHJ$%H#OL'T9=]?[Z+?+MW(?DZ13E2WF-"J,*N@
M"S9?<)EC*@[3W1?')/2"(-F5<KY'OCRG)';?TOP&0JC?8IGL(B_)1S1]K7);
MEVY*&O)-W'&*M2:FYCJB\Q?,YR_[##WH\%7AWLCCR[5PO//F90&*"NHQ]4H-
M$02VIIL+-T6R2WX=A<Q+PSC%]UIT:X:0*HR_=!#B#7UC:5C0<#`0#V<ZJ)!D
MQM=1B6)EBI*:59'7JQF,AUAA=A0N2YM,")V'[;0>)+3EX]S2!Z*QN[-M\O2A
MUN3DH)O27H.(P(GH4R>X0BIW&<7]8G8_'`H-Z[B1#3X.7;02R:-4RJFYR-RT
MP-*[LW:=5_*6L7(#>VEZ!LX%[`KY&-^7R[9#P4<ZW>7`#RXV<.&@%R%#!"]^
M!NF>#?/^:57Q.VN.[$0,A*_<EGK&/<YP.`S764=T04=WF)0@\0,^E/V)*0!S
M"EGD%45BN,3WN;/57Q"*\R!+76M36WZ!J!W]I+OL%848.6]'GP?5_=@9!J0I
MCKO,V6K+BPD$]%NB"H2$.0`E[FVHRK]]Y.UA.T2M*1"DN&U?XMM16OFRJ`/$
MT7W1SEXT7`BWC0/E,)NF;42]A<B!S8PABJJ.Y*T12!!S8_+#RA%Y<>3[K`97
MJ'A)NOCJGS?Y2*A$4\3,2'J+*,BAZ(C[`$3F/-.)?_?IC2\1%8(\-K>KJ':[
M1L/\)?FI#&0^&A#X6#JXKV5E8K`GH`XZW7*'`[7-I.U<*7,BM6,U'MIF.^6L
M_94#:#LQLA6__D4-1-,IY'66A4;AG''5RRG5D%.Y\G>X^X-DWU2GJK9@E&IL
M2_O'VZ,>;_F#[2:!IGM^G-?^UAF#@=+?GL83/YRK,R\,MPT1QXI/PX?ST]JH
MRZQ<.].\]PMJFN<-]739ZZR]8RH3"?J2^4P+U/X%)F_N@[AC#$]X8N(R$\``
M5X8I"R/6H_%HH]*XLSXXPN%]?O4)S<\,-G\;O5(0#2W=ZP9N1*V;M.SVAOYB
M.12$K37AM1(.IB/;%PR4W1[R+KZM#%Y]M#4J")7U8%=/XQ3;+*)-N;^_%/([
M+\/ED-[IH%>!ZI4J=>)?R*5,.^B9@M/0L?4DJ\,KL-$B*@BEK$S));*!9O>N
M6AC(]-P^Y`9_L%`*/MY,T+D:-`G=33HMHQV9ULVI#<?Y=;3LGH9.EVR=P
M8ODVVW<)O3:7#'>A7>3RLPR:0F1T0TN4T]_0>C(Z"*\M(XC=&W]\]\/O4\8H
M-#X^I[L_=4O7T6YF[:4V&])EPQ;9=?#9]&M!HG]U)3BX,>#(W[`UU0;G1<B[
MJP]W\5P#!ZACH9:JMG+!QR.##=T;3[QOUS5D8@^9_A8(J'/L(S(SICCHOK,Y
M1WBUAHV>V4*J^^=57_YXPR_#OG[]A3AY_+B[5*;7W`4V:Y`9'L_1115*>O#?
MNLCI)MP[1:_9.(^84B\8%"-G\]L9)17:H413'4FCB[SN#5Z0^2)<WFS\DX,=
M5RT;3:A+5J:1Q`9W_Q,%%[OM#?],EL['#_Z+`_H'!U^W_^*@=_#_X3#1?8@W
"```;
`
end
SHAR_EOF
echo 'gunzipping file path.sty' &&
gzip -d < _shargzi.tmp > 'path.sty' && rm -f _shargzi.tmp &&
$shar_touch -am 0614075295 'path.sty' &&
chmod 0664 'path.sty' ||
echo 'restore of path.sty failed'
shar_count="`wc -c < 'path.sty'`"
test 14216 -eq "$shar_count" ||
echo "path.sty: original size 14216, current size $shar_count"
fi
# ============= Ulogo.fd ==============
if test -f 'Ulogo.fd' && test X"$1" != X"-c"; then
echo 'x - skipping Ulogo.fd (file already exists)'
else
echo 'x - extracting Ulogo.fd (gzipped)'
sed 's/^X//' << 'SHAR_EOF' | uudecode &&
begin 600 _shargzi.tmp
M'XL(`&#-WB\"`[56:W/C-!3]WE\A%DK3I74>V](')=!-'UOH:]NDL'"!RK:2
MB,B2*\E]8,)OYTIR'LT,TYV=P9.)XG//U;DZ5[*SO$R6EI=)=\@-P4^?"T9N
M>T(-5-1/5];(@$FFJ64I49+L-7=V-NK-1KW9;/NT!VZ'Q`X9255BK.8Y*2P7
MW#Z16BMJ#5<C1PKS,Z(T'W!)!3&JT`GS6H8\,,UV)[2L[Y53^TA(S4^N<LN5
M-+M546M")52LK$X23LXN+ZZZ^^==<G[1/>D<^ID^J()0S8A4EE`AU`-6;Q5)
MN2LQ+BS#DJNU^@*/E)X%48VHOE_48L&&,4=WH43E3Q@=6B?",<:EQ[U_<ZN8
M&@"=(=4TL4QW:2S\/*3LY3G3ZPDUC.`%^_`6.G``AW`$Q_`.3N`'^!%.X0S.
MX0(NX3U<P35TH0<W\!/\#!_@%S\/.<4ESLU#(88$4F#0AP$,@<.?,`(!&4A0
MD,,=:#!@H8![>(!'>(*_PCP'N%YK2'5!`YK0@C>P`9OP-6S!-NP$WN%C(FA&
MO5?(^\S3#U2!"R-WA4*#";SRX#MJAJ0FBRQF>I7`YY6.$H+JJ<X7?KADZ+&T
M$W#9#_L9.F2H3`/X9<C?3UP3:1+XL.*#IZQO28Y]EYY:\^"5[]$$A=4JWV`?
MN!E54J^#OBBF2T?P*S]T5);1&;@6\L^XG./">LA7?%H]@I$?KI7@Z90+]9#?
M4<([5Z&[@<HRGDP#\$VU*&-P8]$*W*O\ORNHF/7I6S\<:X;G5%=L:'OP?<&,
M;U-&]8C`=Q/]+$.W.6YM:@E\/_,OQCTZ8L[47SWX%F^-<$WT2A#R@ZL3+OP6
MK.(Z*7#KLT=/_=V#/9EB_Q*EP\[\(^0?:WH_U[_;Y_J!6GKPAFD\7EAG[/8+
M_+VH[[@P]M0N%RF;F?K/>`E2U@=W(B7-6#D[E7.1%"TK_5.ML5EO-><B]U@W
M&E<VHQ:B#YA;'BEI7=CDM'I\53]SK=(B8>DDHE4&[G$B![L!6L*"`G`[*Z-"
M5JJL>=7%K+UIL170GB2%VUI/:#XB-YS9806M8M4'#,^I9J[N(YIQ\53VQJ63
M'Y?/H]=#FK-9,!N7<ERB_-YVF^SMM-U;@+PF+NC`9J/MOJ*=33>VW-=&M.&&
MK:CE,EJ-:,O=MS:B;;QW><W&TLNBW/Z'JA&?JFO$1RD;$937V\28(JYDZUF=
MVY>R39PLVO5L!OFII<?]ETN/_Q_I]".4'Z?2"Z;%J.N3F4RYS`L[>0<>XF,<
17ZT+_S&BI7\![IAT:H0(``"/
`
end
SHAR_EOF
echo 'gunzipping file Ulogo.fd' &&
gzip -d < _shargzi.tmp > 'Ulogo.fd' && rm -f _shargzi.tmp &&
$shar_touch -am 0614075295 'Ulogo.fd' &&
chmod 0664 'Ulogo.fd' ||
echo 'restore of Ulogo.fd failed'
shar_count="`wc -c < 'Ulogo.fd'`"
test 2180 -eq "$shar_count" ||
echo "Ulogo.fd: original size 2180, current size $shar_count"
fi
exit 0
================================================================================
From owner-twg-tds@shsu.edu Fri, 20 Oct 1995 19:59:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 20 Oct 1995 23:17:54 +0100
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9510202217.AA02690@regulus.dbis.uh>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/tex/config
> At least the teTeX distribution contains a couple of sample config
> files to help people get going without much fuss and I think it's
> good that they are collected in one place in a config/ directory.
>
> They should go somewhere else. If a distribution supplies them, they're
> a distribution file, not a locally-created file!
Eek. config is such a nice name. And nothing in the name indicates that
I should not put files into the config directory.
> I'm confused about the whole thing. Do graphics and babel *require* a
> config file, and yet do not supply a decent generic one to start from?
> I'm guessing they're like LaTeX, and supply a config file a site can
> change or not, and tetex does ... what?
Well, I think the graphics package does not work if no driver is specified.
And in the config file, I specify dvips as driver for the graphics bundle.
This is a reasonable default IMO.
> As long as the config files are locally generated, they should be
> placed in config/. (All of them: It's a Good Thing to know what one
> has changed in distributions.)
>
> I agree.
Maybe, I have missed some arguments (too much email in the moment). What is
the argument against a local directory?
> If one adds an explicit hint to local/ that this is the place to
> store site-specific (adapted) configuration files, dropping config/
> is fine with me.
So, why can't we just go like this: I put teTeX's config files to
config and the site-specific files may go into local?
Thomas
================================================================================
From owner-twg-tds@shsu.edu Sat, 21 Oct 1995 11:11:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 21 Oct 1995 12:11:50 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510211611.AA17722@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/tex/config
Eek. config is such a nice name.
Nice but ambiguous.
And nothing in the name indicates that
I should not put files into the config directory.
That's true. I didn't mean to imply fault on your part for using in
tetex, but rather on our part for not specifying well enough :-).
Well, I think the graphics package does not work if no driver is specified.
And it doesn't supply a default config file? Hmph.
Maybe, I have missed some arguments (too much email in the moment). What is
the argument against a local directory?
There is no argument against the local/ directory. It's been there for a
couple of drafts, and I have heard no complaints.
So, why can't we just go like this: I put teTeX's config files to
config
I think tetex's config files should go somewhere under tetex,
offhand. But I don't know how to accomplish that. TEXINPUTS shouldn't
have to include texmf/tetex. Ugh.
and the site-specific files may go into local?
I agree with this, and I added text to that effect in 0.101. (BTW,
there may be problems with the shar file I included in the mail, I'm not
sure. The ftp version should be ok, though.)
================================================================================
From owner-twg-tds@shsu.edu Sun, 22 Oct 1995 11:04:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 22 Oct 1995 12:03:59 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510221603.AA00308@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu, jans@insanus.matematik.su.se, ozan@insanus.matematik.su.se
Subject: Re: Questions and suggestions about TDS
"texmf/metafont/lamstex",
If the lamstex mf files are actually fonts, not macro definitions,
they'd go in texmf/fonts/source/lamstex.
"texmf/bst" and "texmf/bib" directories. Why? Is it not reasonabel that the
"texmf/bst"-directory is subdivided as "texmf/bibtex/bst/package", or
Do you know of any actual bst and bib packages that are
maintained/upgraded like macro packages, etc.?
Thanks for your comments.
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 Oct 1995 09:20:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 23 Oct 1995 10:19:43 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510231419.AA14142@terminus.cs.umb.edu>
To: beebe@science.utah.edu, opbibtex@cs.stanford.edu
CC: twg-tds@shsu.edu, ozan@matematik.su.se
Subject: texmf/bibtex substructure
Oren, Nelson -- there's been a suggestion to introduce package names for
BibTeX in the ``standard'' TeX directory (tds) structure tree that's been in
the works for 1.5+ years now. Meaning, the standard would be to store
bibtex-related files in subdirectories, like this:
texmf/bibtex/bib/{base,...}
texmf/bibtex/bst/{base,...}
where the `base' directory would be reserved for Oren's standard and
semi-standard styles (in the bst case) and for xampl.bib and whatever
else he wants (in the bib case).
The `...' would be package names, if anything else was distributed as a
unit, with the name `misc' reserved for single-file packages -- pretty
much everything, as far as I know.
This is the way the rest of the tree is organized. I personally am not
sure if it's desirable to introduce this level into the bibtex tree.
What do you think?
P.S. You can get the latest draft tds from
ftp.cs.umb.edu:/private/tex/tds.tar.gz.
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 Oct 1995 09:58:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 23 Oct 1995 10:57:37 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510231457.AA14525@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: tds draft date
TUGboat deadline for the TDS draft is 11/15, so send those comments now :-).
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 Oct 1995 10:20:05 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Sun, 22 Oct 1995 19:09:21 -0700 (PDT)
Message-ID: <199510230209.TAA11837@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: "somehow"
In TDS 0.101, it says:
> \item Many font files will have the same name (e.g., \path|cmr10.pk|),
> as discussed in Section~\ref{sec:Valid Font Bitmaps}. An implementation
> must therefore somehow distinguish these files by mode and
> resolution. (Again, all implementations we know of already have this.)
The word "somehow" seems out of place here, since the TDS does restrict
how this can be accomplished.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 Oct 1995 10:20:06 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Sun, 22 Oct 1995 19:30:57 -0700 (PDT)
Message-ID: <199510230230.TAA11882@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.100
> Date: Fri, 20 Oct 95 00:12:19 BST
> From: David Carlisle <carlisle@cs.man.ac.uk>
> To: TWG-TDS@SHSU.edu
> Subject: Re: tds 0.100
> Paul> Is that _useful_ semantics?
>
> well there are thousands of documents out there that have
> \input chapter1/file1.tex
> \input chapter1/file2.tex
> \input chapter2/file1.tex
>
> where your typical thesis directory has subdirectories for each
> chapter.
>
> Your proposed semantics would send TeX looking in rather different
> places for these files, although I suppose if it finds them in the end
> it does not matter too much.
Only if they keep their thesis within a TDS-style directory. Recall what I
said about my proposed semantics:
| ... if you say \input latex/file.tex, and the search path
| is .:/usr/local/texmf/tex//, then:
| (1) first it checks for ./latex/file.tex
| (2) then it looks recursively within /usr/local/texmf/tex/latex for a file
| named file.tex.
As I see it, they probably run TeX from within the thesis directory.
In that case TeX would continue to find the right files on the first try.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 Oct 1995 10:49:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 23 Oct 1995 16:43:26 +0100
Message-ID: <9510231543.AA03041@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: beebe@science.utah.edu, opbibtex@cs.stanford.edu, ozan@matematik.su.se
Subject: Re: texmf/bibtex substructure
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
Karl wrote:
> This is the way the rest of the tree is organized. I personally am not
> sure if it's desirable to introduce this level into the bibtex tree.
> What do you think?
Since I'm the one on the TWG-TDS who suggested to follow the idea
brought forward to us by a contributer to introduce package-level
subdirectories below texmf/bibtex, let me illustrate what this setup
would mean in a small-scale example. It includes the following:
- BibTeX base distribution (CTAN:bibtex/distribs/styles)
- adaptable BibTeX styles (CTAN:bibtex/contrib/abststyles)
- styles for phyiscs journals (CTAN:bibtex/contrib/phy-bstyles)
- BibTeX styles from AMS-LaTeX
- BibTeX styles from RevTeX (APS)
It is true that most other BibTeX styles on CTAN are single-file
packages, which would have to go into texmf/bibtex/bst/misc, but
for those styles which are part of some packages, I still think
it would be clearer to subdivide them.
Cheers,
Ulrik.
P.S. bibtex/doc below should actually be texmf/doc/bibtex, but it
was easier to put it into the same tmp directory. xampl.bib is in
doc/base rather than bib/base, since I consider it documentation.
bibtex:
total 6
drwxr-xr-x 6 vieth 512 Oct 23 16:11 bib
drwxr-xr-x 8 vieth 1024 Oct 23 16:15 bst
drwxr-xr-x 5 vieth 512 Oct 23 16:18 doc
bibtex/bib:
total 14
-rw-r--r-- 1 vieth 2301 Oct 13 1994 README
drwxr-xr-x 2 vieth 512 Oct 23 16:10 abst
drwxr-xr-x 2 vieth 512 Oct 23 16:11 ams
drwxr-xr-x 2 vieth 512 Oct 23 16:10 base
drwxr-xr-x 2 vieth 512 Oct 23 16:10 phybst
bibtex/bib/abst:
total 18
-rw-r--r-- 1 vieth 1622 May 25 1992 acompat.bib
-rw-r--r-- 1 vieth 3065 May 25 1992 jourabbr.bib
-rw-r--r-- 1 vieth 3311 May 25 1992 jourfull.bib
bibtex/bib/ams:
total 178
-rw-r--r-- 1 vieth 90285 Jan 20 1995 mrabbrev.bib
bibtex/bib/base:
total 0
bibtex/bib/phybst:
total 12
-rw-r--r-- 1 vieth 2129 Jun 15 1992 physjabb.bib
-rw-r--r-- 1 vieth 2843 Jun 15 1992 physjful.bib
bibtex/bst:
total 12
drwxr-xr-x 2 vieth 512 Oct 23 16:12 abst
drwxr-xr-x 2 vieth 512 Oct 23 16:11 ams
drwxr-xr-x 2 vieth 512 Oct 23 16:13 aps
drwxr-xr-x 2 vieth 512 Oct 23 16:12 base
drwxr-xr-x 2 vieth 512 Oct 23 16:15 misc
drwxr-xr-x 2 vieth 512 Oct 23 16:13 phybst
bibtex/bst/abst:
total 212
-rw-r--r-- 1 vieth 17727 May 25 1992 aabbrv.bst
-rw-r--r-- 1 vieth 20260 May 25 1992 aalpha.bst
-rw-r--r-- 1 vieth 17787 May 25 1992 anotit.bst
-rw-r--r-- 1 vieth 17727 May 25 1992 aplain.bst
-rw-r--r-- 1 vieth 15818 May 25 1992 aunsnot.bst
-rw-r--r-- 1 vieth 15756 May 25 1992 aunsrt.bst
bibtex/bst/ams:
total 112
-rw-r--r-- 1 vieth 29480 Jan 20 1995 amsalpha.bst
-rw-r--r-- 1 vieth 26829 Jan 20 1995 amsplain.bst
bibtex/bst/aps:
total 40
-rw-r--r-- 1 vieth 20018 Nov 10 1992 prsty.bst
bibtex/bst/base:
total 156
-rw-r--r-- 1 vieth 20285 Jul 20 1992 abbrv.bst
-rw-r--r-- 1 vieth 22183 Jul 20 1992 alpha.bst
-rw-r--r-- 1 vieth 21794 Jul 20 1992 apalike.bst
-rw-r--r-- 1 vieth 16932 Nov 15 1993 ieeetr.bst
-rw-r--r-- 1 vieth 19253 Jul 20 1992 plain.bst
-rw-r--r-- 1 vieth 17956 Nov 15 1993 siam.bst
-rw-r--r-- 1 vieth 16936 Jul 20 1992 unsrt.bst
bibtex/bst/misc:
total 152
-rw-r--r-- 1 vieth 19367 Nov 15 1993 acm.bst
bibtex/bst/phybst:
total 394
-rw-r--r-- 1 vieth 18972 Jun 15 1992 aip.bst
-rw-r--r-- 1 vieth 18973 Jun 15 1992 cpc.bst
-rw-r--r-- 1 vieth 19023 Jun 15 1992 iaea.bst
-rw-r--r-- 1 vieth 18974 Jun 15 1992 jcp.bst
-rw-r--r-- 1 vieth 19022 Jun 15 1992 nf.bst
-rw-r--r-- 1 vieth 18924 Jun 15 1992 nflet.bst
-rw-r--r-- 1 vieth 18842 Jun 15 1992 pf.bst
-rw-r--r-- 1 vieth 21050 Jun 15 1992 ppcf.bst
-rw-r--r-- 1 vieth 18832 Jun 15 1992 report.bst
-rw-r--r-- 1 vieth 23734 Jun 15 1992 rmp.bst
bibtex/doc:
total 6
drwxr-xr-x 2 vieth 512 Oct 23 16:17 abst
drwxr-xr-x 2 vieth 512 Oct 23 16:17 base
drwxr-xr-x 2 vieth 512 Oct 23 16:18 phybst
bibtex/doc/abst:
total 132
-rw-r--r-- 1 vieth 7325 Apr 10 1992 README.abst
-rw-r--r-- 1 vieth 1340 Apr 5 1992 abstdok.bbl
-rw-r--r-- 1 vieth 32132 Mar 2 1995 abstdok.dvi
-rw-r--r-- 1 vieth 24562 Apr 8 1992 abstdok.tex
-rw-r--r-- 1 vieth 79239 Jul 8 1991 btxabst.doc
bibtex/doc/base:
total 620
-rw-r--r-- 1 vieth 67262 Jul 20 1992 btxbst.doc
-rw-r--r-- 1 vieth 596 Jul 20 1992 btxdoc.bbl
-rw-r--r-- 1 vieth 2306 Jul 20 1992 btxdoc.bib
-rw-r--r-- 1 vieth 53540 Oct 13 1994 btxdoc.dvi
-rw-r--r-- 1 vieth 41569 Jul 20 1992 btxdoc.tex
-rw-r--r-- 1 vieth 33188 Oct 13 1994 btxhak.dvi
-rw-r--r-- 1 vieth 25553 Jul 20 1992 btxhak.tex
-rw-r--r-- 1 vieth 9894 Aug 15 1990 xampl.bib
bibtex/doc/phys:
total 214
-rw-r--r-- 1 vieth 2043 Jun 15 1992 README.phy
-rw-r--r-- 1 vieth 6716 Jun 15 1992 cpp.el
-rw-r--r-- 1 vieth 92563 Jun 15 1992 physics.btx
-rw-r--r-- 1 vieth 2413 Jun 15 1992 physjabb.btx
-rw-r--r-- 1 vieth 3125 Jun 15 1992 physjful.btx
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 Oct 1995 11:33:13 CDT
Sender: owner-twg-tds@SHSU.edu
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
Reply-To: TWG-TDS@SHSU.edu
Date: Mon, 23 Oct 1995 10:32:44 -0600 (MDT)
To: "K. Berry" <kb@cs.umb.edu>
CC: beebe@math.utah.edu, beebe@science.utah.edu, opbibtex@cs.stanford.edu, twg-tds@shsu.edu, ozan@matematik.su.se
Subject: Re: texmf/bibtex substructure
Message-ID: <CMM.0.91.0.814465963.beebe@plot79.math.utah.edu>
I think the proposed TDS structure for BibTeX looks fine. Certainly,
user-contributed files should be separated from Oren's master files.
Also, although a lot of the 50+ .bst files are standalone, there
are a few (Harvard, Chicago, AGU, ...) that have associated LaTeX
styles, and sometimes, README, and test files, so they should
get separate subdirectories to avoid filename collision.
By the time sample LaTeX files are introduced to illustrate the
various citation options, and the bibliography formatting, one
gets a substantial number of files. In the current collection
on ftp.math.utah.edu:/pub/tex/bibtex, there are about 240 files,
of which 62 are .bst files. For small systems, that is probably
too many to have in one directory, so your proposed splitting
would help.
========================================================================
Nelson H. F. Beebe Tel: +1 801 581 5254
Center for Scientific Computing FAX: +1 801 581 4148
Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu
University of Utah URL: http://www.math.utah.edu/~beebe
Salt Lake City, UT 84112, USA
========================================================================
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 Oct 1995 13:31:49 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Mon, 23 Oct 1995 11:31:43 -0700 (PDT)
Message-ID: <199510231831.LAA12711@tashkent.berkeley.edu>
To: twg-tds@shsu.edu
Subject: tds 0.101
The current TDS draft says:
> We recommend all implementations have default search paths that start
> with the current directory (e.g., `\path|.|'). Allowing users to
> include the parent directory (e.g., `\path|..|') is also helpful,
>
> \subsubsection{Web2c 7.0}
Either the comma should be changed to a period, or the rest of the sentence
should be put in.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 Oct 1995 13:35:45 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Mon, 23 Oct 1995 11:35:42 -0700 (PDT)
Message-ID: <199510231835.LAA12722@tashkent.berkeley.edu>
To: twg-tds@shsu.edu
Subject: tds 0.101 nit #2
The current TDS draft says:
> it's necessary to combine many different types of files into a single
and
> In this case, however, it isn't easy to limit subdirectory searching to
Use of contractions is discouraged in formal writing.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Mon, 23 Oct 1995 14:16:26 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Mon, 23 Oct 1995 11:31:43 -0700 (PDT)
Message-ID: <199510231831.LAA12711@tashkent.berkeley.edu>
To: twg-tds@shsu.edu
Subject: tds 0.101
The current TDS draft says:
> We recommend all implementations have default search paths that start
> with the current directory (e.g., `\path|.|'). Allowing users to
> include the parent directory (e.g., `\path|..|') is also helpful,
>
> \subsubsection{Web2c 7.0}
Either the comma should be changed to a period, or the rest of the sentence
should be put in.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 Oct 1995 04:29:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 24 Oct 1995 09:26:20 GMT
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510240926.JAA02593@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: texmf/bibtex substructure
References: <9510231543.AA03041@macbeth.uni-duesseldorf.de>
> - BibTeX base distribution (CTAN:bibtex/distribs/styles)
> - adaptable BibTeX styles (CTAN:bibtex/contrib/abststyles)
> - styles for phyiscs journals (CTAN:bibtex/contrib/phy-bstyles)
please, no! lets not start a breakdown in terms of usage like this,
it starts to have ramifications all over the shop. it breaks the
principle that one can easilu identify a package and remove/changed
it, if 3 otherwise-unrelated styles are in one directory just because
they are all physics-related.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 Oct 1995 05:37:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 24 Oct 1995 11:34:14 +0100
Message-ID: <9510241034.AA03393@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/bibtex substructure
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
Sebastian wrote:
>> - BibTeX base distribution (CTAN:bibtex/distribs/styles)
>> - adaptable BibTeX styles (CTAN:bibtex/contrib/abststyles)
>> - styles for phyiscs journals (CTAN:bibtex/contrib/phy-bstyles)
> please, no! lets not start a breakdown in terms of usage like this,
> it starts to have ramifications all over the shop. it breaks the
> principle that one can easilu identify a package and remove/changed
> it, if 3 otherwise-unrelated styles are in one directory just because
> they are all physics-related.
Sorry, but I think you've misunderstood this. As the CTAN directories
above indicate, these are indeed distribution packages maintained by
different pepole, so it fits quite well with the principle that one
can easily identify and maintain a package. The BibTeX style files
for pyhsics journals are not grouped together just because they are
all physics-related, but because they are maintained by the same person
at PPPL and generated from a common source by use of a preprocessor.
Hope this clarifies this misunderstanding.
Cheers,
Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 Oct 1995 05:58:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 24 Oct 1995 10:55:43 GMT
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510241055.KAA06457@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: texmf/bibtex substructure
References: <9510241034.AA03393@macbeth.uni-duesseldorf.de>
> Sorry, but I think you've misunderstood this. As the CTAN directories
..
> for pyhsics journals are not grouped together just because they are
> all physics-related, but because they are maintained by the same person
> at PPPL and generated from a common source by use of a preprocessor.
>
you are right, i misunderstood you! sorry.
re Nelson's post, i think he misunderstood the TDS. the LaTeX style
files that go with eg the Harvard package do *not* go in the BibTeX
tree, surely?
for what its worth, i think the proposed bibtex breakup is needed
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 Oct 1995 06:14:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 24 Oct 95 11:10:36 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9510241110.AA24473@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/tex/config
Karl> I'm confused about the whole thing. Do graphics and babel
Karl> *require* a config file, and yet do not supply a decent generic
Karl> one to start from?
In the case of graphics at least, the answer to this is yes. If no
config file is supplied then you have to say what driver you are
using in the document file, as in \usepackage[dvips]{graphics}
If you always use dvips (and xdvi which counts as the same thing as
far as this is concerned) then you can make a config file that
defaults to dvips and so the document can then just say
\usepackage{graphics}
So the config file probably should not go in the graphics directory
but it makes a lot of sense for tetex to put one somewhere, as it is
setting up a dvips based installation. Not sure where is best in this
case `local' does not sound right as that should be *really local*
but either `config' or a special `tetex' ``package'' directory are
possibilities I suppose.
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 Oct 1995 06:14:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 24 Oct 95 11:14:18 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9510241114.AA24491@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: about the committee
> In fact, what would people think of changing this appendix to be
> just a list of names,
OK with me.
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 Oct 1995 06:19:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 24 Oct 95 11:19:33 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9510241119.AA24494@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/tex/config
> Well, I think the graphics package does not work if no driver is
> specified.
> And it doesn't supply a default config file? Hmph.
OK Karl, you get to suggest a default syntax for \specials that does
not generate me lots of hate mail from users of <name any
non-dvips-driver-here>
As I mentioned before the package does work but you have to explicitly
mention which driver you want. However as the documentation file does
not force a particular driver you need a config file to latex the
documentation:-)
Followups to TWG-DVI :-)
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 Oct 1995 06:33:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 24 Oct 1995 11:28:07 GMT
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510241128.LAA06997@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: about the committee
References: <9510241114.AA24491@r8h.cs.man.ac.uk>
> > In fact, what would people think of changing this appendix to be
> > just a list of names,
>
> OK with me.
>
i agree. it looks a little odd at present
s
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 Oct 1995 07:16:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 24 Oct 1995 12:13:44 GMT
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510241213.MAA08928@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: texmf/tex/config
References: <9510241110.AA24473@r8h.cs.man.ac.uk>
> In the case of graphics at least, the answer to this is yes. If no
> config file is supplied then you have to say what driver you are
> using in the document file, as in \usepackage[dvips]{graphics}
graphics just leaves everything undefined, correctly, doesnt
it? ie if you say
\includegraphics{foo.eps}
it will says "cant do .eps files, sorry" - quite rightly. just as
\includegraphics{foo.tiff}
will generate an error with the dvips driver
so i think we are talking cross-purposes. graphics does have a default
setup, just not in terms of a config file
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 24 Oct 1995 16:16:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 24 Oct 95 14:14:51 PDT
From: Oren Patashnik <opbibtex@labrea.Stanford.EDU>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9510242114.AA27262@labrea.Stanford.EDU>
To: kb@cs.umb.edu
CC: beebe@science.utah.edu, twg-tds@shsu.edu, ozan@matematik.su.se
Subject: texmf/bibtex substructure
[If you want me to see followups to this message, please email me a
copy directly, since I'm not on the twg-tds mailing list.]
Generally, I don't have strong feelings about whether or not the
directory structure gets changed now; I can see good arguments for
both sides. I probably will have stronger feelings about it when
BibTeX 1.0 eventually comes out. (Actually, I think I prefer a
structure that generates the least amount of email for me. :-) I do
have a few observations, based on browsing through the CTAN and
through the texmf/ subdirectory.
(1) The apalike.{bst,doc,sty,tex} files point up some of the difficulties:
apalike.bst---the bibliography style file
apalike.doc---the documentation file for apalike.sty
apalike.sty---apalike.doc with comments removed
apalike.tex---roughly, an apalike.sty equivalent, for use with btxmac
I'm not sure where these files belong, but currently, it often happens
that the only file that users actually have is apalike.bst (I know
that that's the only file of the four that exists on our system, aside
from my own personal copies). At the very least apalike.sty should
exist by default as well.
(2) Ulrik commented:
xampl.bib is in doc/base rather than bib/base, since I consider it
documentation.
Actually, I think of xampl.bib both as documentation and as sample
input for .bst writers to test their styles on; if forced to pick one
place or the other, I'd probably pick bib/base, at least for BibTeX
0.99. In any case, if it is moved to doc/base, then the README file
in bib/base should probably say so, and/or the BIBINPUTS variable
should have xampl.bib added to it.
(3) I noticed the file bibshare, in texmf/doc/bibtex/; while it gives
some not unreasonable suggestions for sharing database files, it
probably doesn't belong in that directory, since the other files are
all "base" files. The file should probably be moved, although I'm not
sure where, and the person who wrote bibshare should probably add some
comments saying for whom the advice is intended, and add their name.
Perhaps that information was obvious in the context of its original
directory. [By the way, some of the advice in that file may change,
given the @ALIAS command that's to appear in BibTeX 1.0. Also, the
suggestion
Address entries must always include the country
at the end of that file seems wrong to me---if the address is "London"
or "Paris" or "Rome" then omitting the country seems preferable
(unless if course it's a different London or Paris or Rome).]
(4) Currently, in CTAN's /tex-archive/biblio/bibtex/distribs/styles/
there is no acm.bst; there should be. (That is, acm.bst should be in
the same place as apalike.bst, ieeetr.bst, and siam.bst.)
--Oren Patashnik (opbibtex@cs.stanford.edu)
================================================================================
From owner-twg-tds@shsu.edu Thu, 26 Oct 1995 14:01:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 26 Oct 1995 15:00:10 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510261900.AA07984@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: tds 0.101
Either the comma should be changed to a period, or the rest of the sentence
should be put in.
Right -- fixed -- thanks.
Use of contractions is discouraged in formal writing.
R-F-T.
> must therefore somehow distinguish these files by mode and
> resolution. (Again, all implementations we know of already have this.)
The word "somehow" seems out of place here, since the TDS does restrict
how this can be accomplished.
RFT.
================================================================================
From owner-twg-tds@shsu.edu Thu, 26 Oct 1995 14:01:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 26 Oct 1995 15:00:09 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510261900.AA07976@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/tex/config
but either `config' or a special `tetex' ``package'' directory are
possibilities I suppose.
`tetex' sounds better than `config' to me. That wouldn't be a special
case. I like the uniformity of having `local' directories mean
`locally-generated files'. I think having `config' as well will confuse
the issue.
(Yes, we have to be sure it's clear that `local' includes configuration
files ...)
OK Karl, you get to suggest a default syntax for \specials that does
not generate me lots of hate mail from users of <name any
non-dvips-driver-here>
:-). Sorry. I withdraw the implied accusation of poor practice :-).
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 Oct 1995 13:51:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 27 Oct 1995 14:51:11 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510271851.AA06640@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: tds 0.102
OK, I've made another tds draft with the bibtex changes, etc.
Our deadline for TUG is 11/15, so keep those eagle eyes reading.
I'd like to include the location of Ulrik's and Phil's email archives,
but I seem to have foolishly disposed of the relevant messages
... figuring I'd find them in the archives, no doubt :-). Please inform,
and I'll adjust appropriately.
I also changed the ``replaceable'' stuff to be typeset as <italics>.
If any objections, speak now ...
ftp.cs.umb.edu:/private/tex/tds.tar.gz. Here's the DVI file:
#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.1).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1995-10-27 14:42 EDT by <karl@fosse>.
# Source directory was `/u/w/tds'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode name
# ------ ---------- ------------------------------------------
# 79228 -rw-rw-rw- tds.dvi
#
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
shar_touch=touch
else
shar_touch=:
echo
echo 'WARNING: not restoring timestamps. Consider getting and'
echo "installing GNU \`touch', distributed in GNU File Utilities..."
echo
fi
rm -f 1231235999 $$.touch
#
# ============= tds.dvi ==============
if test -f 'tds.dvi' && test X"$1" != X"-c"; then
echo 'x - skipping tds.dvi (file already exists)'
else
echo 'x - extracting tds.dvi (gzipped)'
sed 's/^X//' << 'SHAR_EOF' | uudecode &&
begin 600 _shargzi.tmp
M'XL(`#PDD3`"`^Q<:Y`<U74>S8Q6CI!D$6R5>0@C48E6,+OL[$J(E0BP>K*%
MWCLK*49.Z)V^,].HIWO4MWMWAX)2$1/*/':]S4631L)>4<B\!"0,":7P-$$K
MV08<AY1)4DZ!8J@81*529G]$(0CEG'-OS_0^2*B*L45EIVI+\^B^]YSSG7>?
MJ_^(3_O6/3^X8$4,7HGWSK\HPW9<9'MNR7,O2K>W+VU.MS2W+EN>7M*Z]"ZX
M8EKL,[Q.P^M`O!R+#1PX]6`L=B!^-;[]9$XL/N!;6QX;_?+JO_\W-W;VNB?I
M;WJVZ*27/=M1F;[,76TX+.O:3EETN8Z7=3V'B9SMB,R`?^KZ^X83AYO6#/H-
M*_([Q%K#9'QP>!ZL?$_L^1?\;?XGW]_&'&[8E@\+M0#=K8/#"S:V#^#+7]GR
MU.C<'8>VG!6;!03B'VW;^ERF>UTE<>*1[?[IZ=ML9Y=AY<4ZQ_9*PK:$AOM^
M,M,?CN_MAGV3_H(=8C(*&S/;AQYWUC5E5G<M'L37\/EOO@)DO?C1'9O@VIZA
MKD'FX"ZMRU("A0H7Q*817>><FCLZYY+C?_!<;";0A'\-1<W*6>Y?[X%U_-3Q
MAT;//15;M+S^<[;H&NF6(YF"P2L)\4N#`YFZL__T+8NTG"MX*6!!UIB5#307
M1-$\>!!X'<!U(C?8EEFFNWQY5_/@HW,W7C'@?^WXP=$9U_WJAG)M-Q)22U7>
M>_UYO+1OW7R&R]/JHJ@-'7ZG+'H")AR68X[#=.':0N/"+3"Q<_0\^R_O.A;[
M'5@(_Y*P6/M(9ON^%]M)5G[BO$<)I^I"`1COA)\"^J&ZT$]<?R[BS@NVXZ;\
MQ,Z[X,.-'G<''R`RX5J\K)+H[NXK,(NVR]K6OL/ON*S?!;IV!8P+PQ59DVF.
MZ"L8V:!`:'9?-1Q?=`&@F7BG?X?0:VCR&IH@H"+3K`#$\A!MMLHN[04V'2-?
M$"ZAUG"!\[WJ/V0!(?@`-(S.7K`PM2^*$2^G6P[/1@CG/G:H"I@O22&Q[4M%
M#XD,"9Y(3C<'#9;Z%VZ^&7AB3M'@J-F5A+X:Y.MQ!JL58EF[%)3]TY<\EA*:
MI>./N@%\&#V>RV`'8$2WA];-SWI%!NR0(0%?95'RG!)\;W,FCO09;@',W4\\
M<+!H5T`?=$!7$+Q^LO'A*BRL9*ZNK"2\QW*,Q%1@#NO9A^SD'108TP&J6UXJ
M.7;0:^BH"P7-E818MFMDF=!*N#%``N"`?9DFH%8R&&_VDV^,=+JX:/WNG1I7
M6QM<0BTI$*R_Y##.X1+@R"B63`/>]@%&F@-T"%>04&H2!!7@#._GS-+%;H]Q
MY([CS=S+Y\./DA-6U`P3E7CT_+=/7-D_QN[<=,M1MR_?Y.K\&E[@7C/3/5&%
M97I0J"115S.%6D'1?IWFF+CY2C"/LKA,I-N6BE5,JJHCKC5`!EMM38=?-IOE
M(K!72(D-':*EM>WR%OBRNZNC66Q'?ICH"YB9M8M,":Y(L/*03VFDW=UUS'$/
M%*D6]/JG=Q\#LK0>DY%G0S48697Q3R\_U+%15`M`N6CLD.A8NM$O5HN"AJX%
MMBF9S%4&SJPL6]P,#NY"\KOOW7`P/3AX-P:&>.RSO2Z)!`:TI>&/<SK\<T_L
MF6N^6]4=\$;(`UBWZ!U"S4>U%]*;@S$!F\/)6/R.6"R7FW8P%D-GJ\++J7?1
MT:$+F_\G/]EZ>6Q.+D=^'HV1IUM_N,JV7&:Y?/#1<V_;-2"OO/"\#Q=NBT+<
MTY]N^5%ZT%]T_/N=UM"3[:YC#VTYIH-G`#(&[IFVZ1\_:AL<//CEVVZ$%>"B
M:KH9KK[J^*.9`FG85AOEFR/S'B$7=XT/5\;W?%P%J55F'/NJ_`0?Q-2[7].[
M`?]WM_T48'E`8I)N;B5(`'!P";T"PP,:N#_M5SVU>Z:@.,/`>TB:Y(]:R?C6
M,8LYF@D6EW_YS24U:*NMRMRZO![P5+7HC3&X"Z)*%EQ&`5(X/W;[MZ:@_MS@
MJ@/26K<U2#PTPP(`7.XG3ZR=$O\9#UT;0;<5TP7(SJP\!C#*2S';<!CSD[-?
MF(+QMP34Y1&@EA!0ZRFOTTQT=AVZ;JB@=O6WIS`ZH]!:2FBM]J`L@3*9(5S8
MK+"T(@//>'KW%%R_`4"6U3.*-LHHP*G-/&27FM:S7LCK&5C1SS)A+P<*4,@T
M%K[WQ+)ZIM&F,HT-6M:Q.204?S>%VQ=0#ZZH(=JF4I6U&-ULF:@,W9B?0O4+
MC6][!%^9SVRTK::<Q!<3FM&OG[S7OJI>XYMVWDZW_'C#FLS0L0LZU@X-MF_:
MF!%5:B</]6^:4H?_.RRSM_UM.AW!1:8OH<@W#^T^NJDKXR<&WI_JC)RAZ+5&
MT)/IS$K_])Y/1AO^21S8&IL!=C1#]?.7/=4)/[6U5B<TL_V&7ZZ8LJ8O)N:7
MRQ2VUDA&9RH?"21>?WD*U#,"K#"]74+I;9=7+&I.&=+8/VP\F8YTS):H/'82
M,*G1KFI]H1;PIY]<,`7P9X5A:1V&#H*AV^*EH2W'\!$IT['$V&RP+%47J2U+
M(Y>OE(\8\-$*(O)D>VA>/\MT<N[1'5]S#J7K=65UI0*R0[=+(7K1)PWQP9&I
M>/H;0;T.RDI54VRP'7K\8UMB7&=:C&E+SRB=FC*N_UFXRR+"E0G]FGX-[03E
M6S.8T(4U==$32YQ(J+4MN=^P9][_/S%+\5U1]TBKI(_A%7`J&7Q4+S2QDKGX
MU'D[-D,T<#OEJ\'1G/W>,^EZ'55=%>U\T).5<#3";WCP["G]_6U!6X=HU<16
MQCB<;G]X"J<S"[&V3T^IH\A-/[E\"KE?B_1;TW57N)I<X59F:JY,R[:&PRR8
M:#7^\_+(Q6OHVE6V'/_`62K;P:NN?7I]*\Z@T.@+O6C^I=HZ*%\T!9/X;$,P
M#:L^URD8XN.'X,6;&S[JM'"&15^E9E@&A^<]VT6_3ZS8*XEM0S1.B%-^]M[#
M[_0)YN0\,^4GMKT]F_4;/2:#MT.N*)<"QB&4T$/#;4.\S%U6Q+$TO3;>9GM<
MLW2.PS!PL0UQ6VB.[5DZ9:Q]<)7MF'JSG_3Z.UTUI4B37I7$A\^P?M>!.&^6
M)2F.2W-+L)YP/!S<LD2OX;B>9N(<HVD*&[9P-"1'2%IXL]_0>6*3Q81GY>!^
MSP+D!3=T)MA9D)FIV2P[5TE8]TP0Q"(NB%W#-%P:"C-X.,K&Y("@9<-B5AZ(
MVHEC@8&[4/0%6E#&P3'#PBDP4Q@N</?"'AS+HEDJAW'/!/W#R;<B#F`I(KCA
M,AK<*FBP62\RH1MGH7H&;K@8W$6S;7D6SGP].G?U:37V!:G1.:^7'`/K-YKM
MVR=G^Z@ZH"'`H.9RB!5;Z(QG0;<#S`E@`TO7''V2><3)AUUQRE62#J+=GUQY
M6Y&>D:0JR5M^JCJOG"82`Y!78*/0`D-E;GMKF9MAZ4R-F^&$3C!A]V"6B8.!
M,]HS'1QD6]0P=0GL7%!RM&R3HL`ULAJ@A/.9-`CI)^>\@DSO3[S_1'T0#I;7
M3&X':MR/!WW`=YD'KAT85M:6TY"@0(PH!J!<W`??3TX5W`52!**D$H1`AC("
MHB^V.MU*<L4R!+X'AV:!"!"ZD;?DB*PT@%TTBP>Z4K0#G3E677MQ`4N4-`<8
M]$S-`<;<OR`T*<UE5%)8R+S:G$8$Y0!S)7%KBYQA;LQL!\FL6^PG;OT]+$N8
M:;!>@=IV:XM!N@!6BJ8%=@EI8;=E]*?V)^Y>-+*AJVGUIJYJ2FP'F&S8JX^+
MD8T9^&)D4]=EK=54`-GA"%ZAMJ?YTP>,D6T;NJJU><6"3?/"TG8TO6A8.)ZJ
MH4,E8]89>3>3S)=<10^JB\AA0P(OH!E')VMHI@@5J`8\:1%75?!$U>W#P4H-
M:V5I!*&6CYF63(X>FC@M:>`DJX4#J`@<T6,[GS*PJSS?&-X$,BO0JHD'O%EY
M0$5ZR6$`+`'UIR<FFTE6,[S(W\U21$[9Q0(2)&,7QPQE>I9%`"I"</@Z]$QD
ME<)V:MJ)K@SJJ.27O@XZ#`[RSM_OQ%'I`'THMT6!F:5)6/1H)GF6=-R&H_R<
M\N5*7V&7O&89-]'(+XB0KJ$97+6+$4[R6K8+&O;TOH**+Z"-3BK0]B<.O.1B
MI`6HE_O3OW0__!18V#KA("FS'&B<`T;!+G"\?>`-\RPT4/"DHAR@H7#\2@/3
MEE8PT71#01#-S?[T-^_K!/__VMHR",;V@"6*%EH1W#[.C!N`/,W)JBY+R;'S
MCD;,"A`@`@L^"9E5P[$@?0B5)^)9P`T\/=ZDMJS-SI*^@O,8,VG;/#@\/_ES
M-9)Z$0VOAH<4U/#JJS1FVG;P(G+V)QZ)CIF.+BA>_,+6V,S1MMKL.4^WO`9>
M>G#X*W=\HF(]W)><]TUG_'AJ<MZE51D1P#XPWMW$Z$>%IYSRG\R^FAR93`EN
MYUR"$L2W'[8H:5FQBZ:-P=,&:/D!_!+.<8?1#,6`Q@&BP&%V-3S-(<,HHTLL
M`B(@00.SAA+L@Z(&$S:*`7RK60R2"W/,C'<'&F\E_KVOS'*X*_*F!K).^?&_
M><Y0&LX96H>*X6(5V(_#"LSB1F\PF5UW.-F@0+]M9&[0%Z"K;JS-2U<7^_'O
M_JL67L,%)$FSS-`3-VI`R<D43IV[B\F%UR(QRA]49.9/P+KE-W(T7IY?T#A8
M97+KLP"6")&J[>G'3WXUA(I&WG-HA+*S1#E#?5`_ZD#HU`'NH$0O$471@]Q#
MZ75:E?@'#^2T+!ZUB(VX:G\>597]\0]NQ\,`=8J"*EH,^.K=GG2>@!W@"=H_
MVU`K0?`K!V!:Y(P!`L%,SOID$F61`$*2:UX8$P3P&NO_2Q:WSO[$Z/-C&/*3
MYW=+HU=9$@1WS$C1GL@%4(#&;-0-*.8%X"U%CP&!=US8#CS+<%?44YE*8M,'
MJ(U^8LLT&1W!H<LY*XV.!'"6=U@>,TG<0S2R7CR<82$@!L1H^G9QZ*.5%P9[
M"$)[H-""RX!2P"IA["3>`7W:QRS3#+^!\0HSJ53MC`H>DXAXBE=ISAE\`I0J
MO<RB:!&Q>,`T,?=QE?_MBQ2=P-Z%^9U'+ZLNE/%?YB,A3<@#3BI1B`EL2][#
M5_B)1=_!2,9D,XX6.>JR_F+N,DCY7%X%S?W&NYDZHO(L`FH/9A6H%=%A;/Q-
MV@`(16=XTD#J!/IW/,@A:*87;VWBM19?1%\3;S>,.^`B>4M.<W9&S7D_FO-"
MD9?SQ*"A>+2'3XCF01C*:07("4U/1Z,:-R<`^<_1U=LZ_<1;OX`JS5"U68@C
MZ">DH@`3&1USL\TI,FX\M_0I^8.**5`K<&;FZKD)>/EWC_=A7(*\?&=4AQ:&
MEC/V;`_FF;`(X.GA"11@$LB'2#KT%F@B(P\4>FS2W?I!(3TUWCD#N#>]2`D=
M7UG4#+)M#>U'T(D0M!I`^]7O9)0#.P),^LG<>55M0*P?&#XUNG3`_SB7>ZH#
M2M78ZW=,\FAXVIZ/6P>&I^TY/3KSK`,]5T5/8!2-=,M?+<2C;\N;JU'&B2IU
MD(NJ5+!O2&<H%'.O!$H9IH8JEU,3K=I8065-2"5"0<L\%:\".R"(<K9IVG!W
M'Z(/&U!@`HA*L#$J<0#^'I9!8UN.'0-:YDC)P9-3MLA#\E<$VM<]_$9ULX26
M_"^._I&&NU@=2U?%T"<#9E"^9'GSA+Y"6[2MD/QL;87%G9]O6X&8/0HZCK8$
M-UQ[X-[J>OF)C!V/WG$O"^(KH*H<S:FQ1T&!*QC#>/BQS\$%:A_5442YU>'"
M$1(L@QP@*R"=Q@9$[`?7'S9@\V]\^Z7J5OJ%X?>5Y!/SQQ,`]Y?HB&-V%RB0
MO+.:\J<GYH#/011S98J<4BE4E+;R7%XRGF35I$@??TB!)G,Y:BIHY.M[H#`%
MY[5+,*S0AR^^XKAJQ;12*T8=:A@<GO?*W6%:)MTD9]2<"<MR+)HX%3_P';@(
M+(_0KP!YD';GZ0Q<&)=%U85J"0/#V4=48&A5R2(^BNH:5.%C[^,.GI,X\4@7
MTX2313XA6MQ?DH1LT-!D(/0LV#'12453!RRD;%!D"'<0SZS`*\H@*\NW,2[&
ML,(8&(U@?O(&KD)[))A<^J)6RY^.9M9N`"_\8157J23C%^))P?%+E2F'P=)Y
M@K>'C4L@(!FB_S=_A(Z?C%)Z$H`^V;1YLPGN;GQ\D.447:,(10^_V$_N/F98
M,I^E5L<$2J-YJ@3\\+\`L#;8$3J5>E^'"M`"]D5`FNAXL0[%3!9%JWUJ]0E>
M_HKC,E_1C3E9JCRPP^/BL5$K3+W[(/>M)&^^F<1"I0YUZZB]I;QJU-NB((ZN
MQ9ND("TF\P323>&5`IV`IL.W&OS:%_4H]20@$E(^>!\SK-=?JZ_)09%-[!CB
MDCK#@A8J`F05*`'"ZFD3-L^*-OI>'>JVGU\J3XI2U0J:87N.E!%S'#P0F@M;
M!%27V-0B<$01U7;LPMB74X48\E;0<(>H^E`-B);&T8NA*XN$:"CJ8$G@K&.#
MBP'[RNM&,MN'7FQ?YR>N7%/-,<"!:=(7C4D"Q[`M=3M,OL;JC)\T[)5`BBPP
MLW8^K+"UL'_)^G'(W(#,NQ)_XT(38CKY,["*B,D1;+09QV?12!`B%T2H\"QI
MQ4!%#[8&DFMGJB>&\*?;-S%+-G*C"A(V?BH)XS^IV5'4I#(9O!!I@\)B?_YT
M!SE)F1A#12U[&5@+@/3LA2'=5)Y19W0,^8I2J*?T^JG:DN86R'46I><:VW$&
M;096LBX:DFE;^90@Y7%FVX$,[`#IN$.Q')BCH[$<#]B&?;BPO`1-2^V/]\XQ
M<I7X52O&"QBE5(="(#^@\H&2`&X(^H<:'/9WI<6,T0K%)69N1+Z5;ZH94;X2
M__A6M`J7PAKFA0R[6UQ,W"+HK3&8Q0ZYD%W49.;2C.S,1(!<OLB;J5Q3'
MUI!D2DT0>RS0[!5YFZS$T60%EKCFS\+2ARPD[,T%JBDGD0P/<DN)4G?!E1WR
M,*//R7/P),I:7X]$6DGD[J.J1"DL]M0<#T,V+-5(1G,TLV9'Y\;-W9DN/Y';
M6X7=>PT@5V9Y$EK'D.>=';0QV2`#7F?E/<D(BB85+?^^^4<J(BT&@=WQBTVU
M?JP(3YX##91:4H%47PE$\L<W&&XH72R)@2<RVF+)('BP3Q+T82^DWC*5"006
M+E!MD^F)'L^!U*2F=[P2?_@]33TZ2/GQ'P<R[I.?V1]_^/DJD('%2GC87O8&
MP]X&NF3*$H*JHDE=9HP?I."3=GG"A!HN@QJF$M?OQTQ;/I*1L&)G!F^EE@2H
M/Z1?/4'D?U4(`001@$P7W+F!O##\;$#!HUKV\7M?GJ!!Q:#^GST4M5W(2"4Q
M[RW80#[=P%81D[H4A)H$?$W@`)"Y>.?$*DZKM3-17%`L@3;4RC=)-796T#W+
MEK06-@_#_P$#>U@/WCDV'8'WGJ/$;I;#;(W\<50L1MA9`8+K"U`H->W`IO^#
M)%?KVX*:Q-_MK@4ED.+Z^8V;*-.0;3%8BH\;.HJ*'>3[T;]'2O<:E0%K<NTF
M,/`FD\$'4]X5%.H)CO3HE>0YKU*HE4ZC]O\S0.[3\,0EJM7/K"R$80K6-2BQ
MS0\(U?W`9%0&%`L:M6B[=,*`6YA'.&'GREG\W[Q=;7!<Y74VNRMC)RY@H.$C
MA8!AQE(C[5J6L0`WI?('H"!;+A+8DYKBJ]TKZ>+=O<O>7=LB`R$U]61"<+1S
M8;G53B:FDU*3E(3>SA"F=9E0S#(N<5K*%))I6@SIT*G#M($D/Z`$>K[>][[W
M[HIQ?H0?S&!I]_T\[_EXSG..N)L%G"Q9@ECD?/S;7'I_?#XDZ,-FC$U+"BH#
MEOS]-(KZ!2Y$'0YJ-V.!($9O')L26YS8:R+LA%U3,&1LG#RYJM*A2A$2#H96
MR4`_0;DA3#8A\<#&[-J^A&NO,1^NMZUYAA=_HTH@-M/UQZQ\WJ[4;,ZW,I1.
MT]*.%[T);.#QM*%C&NGZ(V&M7L7H'_$%3,)Q_`MC[J]%!IE\WV;Z@)572\/#
M\'P*T`IH6%7$$F9]1#C96=:?#G#P*F@%%K.\A1$YHK>H",3MK`31PU>8"W?V
MB*(A0C<I!ZV`8YV%B256<$7/;=H\<#/L<GQKV!F`KS,#\)[3"\"O.?R;S^O_
M?!7C_4:O&6]PS0F0#`S[ALNOCQ0KLQ8=8LW)XW2;+(\<35V%>.@Q,_##PVJF
MZA]'\<9WP@GU!;'W44H=SP_ASVI!K#9Z;2RG4X'-SK9MEW$H,!(@UP-T\D7%
M)$!\NP&_+!('S3-R_O34!7A$7^7.YU%`GAN=&`\'KEF_?HVD6OQ>(SXNX*1%
M2DWV889;'CDLGG[FEYS]=F$`Y_1YV$-?5SV.2$DL*9,L]ONQ3%0CO=+!(?Q]
M'G[$&,18WBUW*>0+D3TT!:;,4OH$&RRI^!T?@`["X,DW,R_N3:[.9PRX7N4$
M9!)&:W6%T7Q)M@ML4*EQ8@KABS7WX-$G1@FZ#$'8F)Q=U:;LBZPU3TUSCIQK
M@0--EI8O?*:._KT%.R,ODT\&3J7'>7]R%M,V,'WZZ#.P<1Q@`#0W>B(URJ6L
MT(E*_I!%GI+MU0QSUQZ?',R7JMEIL*_?>R*DS(%$+R"-W@H=M%HT7-NMR<?]
ML!?VCU_?M/7F[/6;P[ZLCY(_L.@"_NV@WBP&<*G_?(-U$CC?!?#V_R]/^0W*
M<Y:P/PY?*)R1D2T/.)L!+MX>#W9<]EV&N:O8IZ<%0U*F`AD%52?/&+V:T2)=
M0+$#&A2Z2ABK`)+Z2:7PZ5FOI6<]S@HV*B;V32/`YB\<!W<]<]Y]=2^1YCMO
MPCQ)Z:BV2$:ONYI<8#7)_PC&M]*8A+LZ&&7AZ$K($;\'==],[[V#FU5U><IQ
M)>]XT;.IEQ6NSO0>,F/D&T>WIT:)Q,90Y=Z&1N;`O4ZMF;GT>?);T'S!1NJU
M*!)F.@[?"=MZ2Z(6P4(X\=NI!0EJ#L#]!87R2`()B!LBJX"_(`^HUT*+RS!\
M8\GSE_0Q@,^;R![ZAE),T3%19%"2)EU>A$S/"S)==$J.N,K7(L<0I.7RDX>?
M.ANMR.#)1ZF<L9EY<`FQ++29)U73W\K\Y)N<$519#C&8T0<ITB27L8:/QV4F
M2G\@_=[@VX<>4V"HO3]O<T+7=F9F"<,RPN_L8JNCM333W[U(8`,!7S30IZ<&
MU?+P^5O4OSQ.Y^+Z>6+TLL%C,J?$+VQV!O!-P&RRIPB'EPEQ"#5IV9BNVX*W
M\6)_>"N>IVVNA89")P8>#3ZY8RC#C<S?OA122M?`(=HCX>?;G\,,TAKXGVM"
M4$#O?(+<60+\\B[RAGK>/0[R)"M'.<)EAW$ES;$E2E#7M8XTTOF)RD,HN`XH
M[68ZOT/A2RQ(*L-'<`S^P#CJ3.N$PM8D#>>U8`!LMX88&:QY^A6TE.7`8?H%
MCB3+=4D[12*#??2P;1VZ]W9V)@L[OWYT;,NVD:U;LG@,V2T[)U%)3^HG\VON
M,_7HRWL?4EX4!,,IB.%*_,"K_<W4\9,(K"(3!'<:#'Y^:.WP^N%^6%=`2CVP
M:K0%&_Y7R"1P-('>0+_&Y0JR0^(V-M/+ER!D5W+R+IA&V5LK?>'F:'NPLPV#
M(:((.V_IG33R_#H*1[5*0<JR-PGG[@^(#N%%F4J9$[Z%Q\HW0-:^7H;/B\+\
M,`5EN)@8??=U.\3Q,N:;=S^LGVZD`S@H9'`+7:(`0A_$<?,SD>+`-=3<B@H@
M>TMNG=H`]G4@F?Y7)F?!D^^77=6X75K!9@J@IQ";HE,062`5Y)!VPR](KGEL
M;6YL*#>V+C=V56YL?6YL.#=V=>[Z\?'LQI&;-PS*X(.-BZ][:VWS8U]X=\A?
MYU_EK_>'_:MEG/!&FTMUQ.08*^!Y54Z"#`%!3PA]2\],#_=95D>36!OEP7.5
M/;G\_ERE/E5T\KE\*5>H.$-KUN2HCV:VLD<ML8E+](=PD>L:G_K"_]`JQ:*$
M$^`[---O/FDXWN!%SK/74\*0MD!>IUA!I(E$!I:5?"-S[J&25:DP'HP!08#A
M@$^PAM9)$$:QXQ!STN&27SV(6**/L60K_2PY-"A'`;\P4BY>0`Q/\#\0WPHJ
M/NL;C[Z-J9%&S]_?B;(?%%S?]@(0Y,!"[BV]-%ZZS(XT7*6=5:"H[;D?JN1X
M,D*[RHS0EIY>A#9Z^6\^0GN!6BM!E'ZS.S]Q2%HKG3HBK95Z;@5[903M%(V4
MSZNZ1#:,-P\LKPA5MH!L8_0Z\^SZ@_-'V"\*Y^(>'9RTC<PZ#%Z.+ADM&[3@
M@2@,$_(-4CN^!:+03*\\PYLEJ)MXJY;N*:H7L9LE/USM]Z)+N:LSO$"EED3?
M5O4Q_K:/T$G"2&'J@@[HZ;CN[2=OC`P5N]@&2`)+_/+KBCXB,#=]4@XO6B$R
M7"KH@L50)#B&M[>.*]__N>V;6FAERQ+#NM4]H(YA0X'2!0'N.\CC18`+5`F(
M0U1T9Y!^&R`/Q+>#B*5";EG@U?/^;&!YP>[VY+7A:J/%[@2SA13ZF1ZXC+3A
M%><6B:>C.7>)PY:'(5H>&:U.S1XHV)6`&-0+Q)O*6$L5IY,A$R&\5=V`9,L(
M=])'-D0.]89&^L5OPPS$U5$14C-]]!?M7-VKYHHN[#0'TE"UT7)'/XO_*U=T
MIAA<;<#H[9Q;41`N4L7P74E,3%K(=?)V#+A+U=^@6V2I\D/,<X!;#DZ4B]X'
M`5<$F,%U5VW+0^>WD4F=XZ!=_2TX)G&402(BJE_LR03X8#R*6%4>B;P%>4?-
MM/L2,FC!':37A?['HIS?WCA+:"&&+^-/`M7J`OY-[1,6;94`)[W7HVPR$88:
ML`RCUW&7.HUMZUDGTCN2U*]@`!+.4,:8?`E0^C'N'W@+&.3"`94ITZH8YLDL
M3@)W7$<:;0PU&O4@.W5$]R!+*K,_.%M:GRX/(2)FZ'5!)7PT]J]RQQ4+I<',
M];I5Y2Y9_BYP/&`^WY+)5H&,W_'$%LFK<M[12!7HK'<S/?4,/2"(']TJ.RNN
M0/[$[RFS78?A%E9@G0@/1;4<.H5)?CV&^J1?Q7?VS`1LWD)+_3N?T(EBXSP_
MG-F-GYXSRCMT;GU7&6:C3:^"5YG[=$0KD`62$PCV0.4'P&#-BC?(.A(_B)V.
M11LR]:Z&5-MZ"?1-*<\P%'R+]J7WQ(G%JE*I\*L".3KL91:4+N'%&<4KBLR+
MGB+>FL$M8\+GO`P+_\%]<A>[54D.ULO#.L?MZ\S]R\.B,4IV;98<'PJ;_814
M>$Q\-R=62H38,8V>7Q0W8AIGUF)X)M*##D4M!-)M0.2-6+"2!,;"'!7CV?`Z
M7%2K\UP3D"`C,QGL@<:G+CHPF!7O>J25N7M.4?7!S\[<_9S.]..RP$E[_K58
M6&])LLYH1D[O?$.C9^6O8O1+^*:I>,43I1J6_10SXH68GV!+G8V6N58OLY$^
M9Z56D\WT.5>@%BZ`=6<5OYH*&CC+#AYEU:V`+P%;8"\8>9]/)@D]K?0E[Z*H
M/#5[C!V]QI*W?XC<JZ`[)4N63YS#']P*GU'`4N.,\QYXRH'(T$B=P2WGZ]3]
MVREW<O:$2H4HP(]?F-2>U`^&PYH":A#ZL:M(W)9Y5302`TI\WKX?<O4'=B;7
M;=.SXL8KV=WQ>]J-\<F!B7V9#+55L"@;DTQ`H[^\XTGP%N85:ZX(46L=#B=;
M@',/!>*2568NNFLC8_O%)$D&P4\A*GK9_/2,6KCMJY_&"`?9QM*GAV\IE]QY
M%4V8*Y,IF8'U%\>$TIR845S3*K9,+ZO+B)$:$E'@LOSYD[.2#J/B-L^D'LN<
M$(J0@BC.#900=%[!X!+L92`/5E_3RVA-,8U*IXDCVISPT-0()%N`+XP_U@X'
M(J6IVP/ED%B,F"KM9&@6M*US(!`.KXGC<[6*_F9J_FD!-[;?U$C=_CDX=5*W
M7@M&G_+G*-II;[7VV)/VSNTW*7^(C35OS(&(FD9D8/O8YKU.Q6LL^9?+0\J%
MC(CJIS(&(M_1I<;6(2?-#'PI6E$J*1;P:XVGJ_Y,KU/ND.XS(A>"JS--?TO!
MHDP/_+H`\Q?=*;(1<">%'+$X^S9PM5''I(H?!Y$HF&?8JS`3Y+2-J<$Z=TQN
MZCV!WF,1=ZU4"?LV=)N7$2FA6(%X%Z+"*7,"B\#A(C.<2;^SD5A\T!/WT#'3
M=>D\)E&#'1+L2)/TLH,Y:U4\,BH<R\@N<GNM*N*`/_V2F9^G'RN-[E5<MR@4
M^SXEN]N8TX9>BUMDV6=TGUU^0T>K)#F9,C1K!F]4^V916CR2B2`O3F`RZ%YO
M!MUGGE[0?>NS'TG0?16YJ$;CU5-'HI1GY*-NYK(1JAA*W_9Q>C[X!QQB/#]^
M;O9^A'5)@*@&)GW;<G$H,E\Z=8-"ZB2.^^-WU-D&(>@:EB&O`5/4RSHZM`M1
MP*T0IF;ZPMO15\,Z(W^1Y8@04YJ>X?E8/@<$"IS%_K^F,+?$!R"O"JMEZ6]O
M./'4TR,#.N4B4"_]S$5-B;RI.:KY@R#"$:H71HN<M4!E$/$EJ2+@SKKP(QL]
MMVQ#_(K@^8J9\2(SC8Y=/X;;LZZOR__P("!81DT9(RMYNFS8EV0'AM[H&U"]
M;DV3Q;O"]1DKU;4RU.!W4IV95],L2-H&'PF2<\N\?83\L*Y,\V02[`D.JR,@
M$%VPU*DGV`73/\I)-!;"19WU&2=K9[%$JJ<02:/?+</+-88DC7+>'1(BL_/Q
M@\'H%?H(OJFA[*!VF#Q).]6KJ+*R?>+$F%369\\K@VYY_#))PO#T7*J](*7:
M%'Z0!++F$,"#OFQP[RV#9Z0%E\YY0-8+5H^#[MM.@:,3'90?1OQ`LMZNZ%C#
M"839=I_MU<_*4T+^_H,3%+4K:5E0K+8H-H3Y0"OBFX2`KI6Y\/NRM7@-.FXK
MB>0@ECKZ&%KRNH=5I_U-^*>)#OG[JL(BK@9LUKU`.VVF4R4L!V8X](X4BYT+
MYFK2/647RU@AA"^B==4W3]>7MRJ*0D1>55\W,[_50B=DKI5Z[^`TQII<%(<J
M(YBU?,2K\+&A\%`&)^`D1C-]UFA;(=4APG1>H+WM`-PV$:Q@"+/22"H=&%&N
M8D>!?RO]M>>X"D\[WH%!(0B(/,#KPL-E1]0F4!E>OM@U4"<W7=`[,@,^`5SY
M=UZ3*H%N\WFH5;!LF&J$J1:83R_:L>.QT(O[I^(^`1@+RG#X4;U.T=FCR'QN
MC*/!-4\W#H24.Q1-U]7CDMSACZ;A/A-0:"/]HTVA6:V`GH@$\0().+6254&B
M![&I^A0=RM172E7IHT$X_>VW$M5Y2S^[,!H9`Y#IBW>J`E0+F6I3<)J*[X[-
M(S2#E@L`41JQ:K:.Q3I;^:ZJZNY1?\,]S+;2!_XJC^*&?"ZO2'\OJZBN%FT?
M7S>%ET&[4B_G:UD(2D'NOKJQ#>Z\52[2OZEWA.<&E)%\[P1'6<&T;1<#(0GB
M+LM<*CD-;CUQPK0OI)IT4)TLW5R5,YZ<\*DZO#?EA3+^X<8.-5:],T35.Y.-
M]U]:QPW$[6(C\S<Y:8XQWSJ*&BE6U0.!VO+U9LS*#A_.KW`)A?<[HE(5&;ID
M-98<NOH.MYJHP/SP&A"XWP?N&&EDEB]#3R].WT17L>34."RHEQ'VL@OQJE+%
M<D>2\\QL,V6]&K45M!X)N:<+TO_`=T=4`B.!3DPO<ALE73;M1JABHO%'("I7
MEBJTI4_F"8)J9K[WH`$&$6%98?=B"_%/814U4,?/F*T$7:<9)H";']5,*]`L
M:MA`BOF+AP4LZSQ@1FK27PEM91@H[.&0R.%"G:A"$NTR^OGHG+L1T!HA]YT+
M<*N*\F;P2%3\287'E&`ETG^L[(!A?B'E8GHX^I-U\N>H%OVJX8]J5T)H*U4[
M*FS$`P0U-G3X<#C-P53G^;#F4HQ5\#?ZLM'W2?O`"+]_V8(:04AK`[%:,>/[
M:\WOE^R:A6/`$%M/-M00O>6HQW>?W]'+.SGB4'+$BNLE1DPTI^X<8YTYQI0S
MQ0>S:??#:H0/1_@[=GF5.5[!S<=/&1G.B=)F]F>,$=;W=09GPV9PMNST@K/I
MJS^*HE$NTC*.++5M)_\,W:&++V62!)<R>!ID->OO5:FT?"N."S12?_+6L1WV
MU-I\(_7J6:%\)JK8G`&O]H]^#E92K")_(+</OQ'V^5W(DMTKE_UVH88.JEI#
M?#@4Z/U$^_C3/T>@BS^LLDVP#*RY:Z:^?P\N_?3FBP%<4=)7MZ9ADX&5B6I-
M4MH0Z_K$PB.?4&BKYPIA;8Y<'7)T*C6%`<F-J?)2SEYBC,,_;Z;^J1S2E=$?
M,J1V.=/"/]4<.LD'B,4Q2WA0YY`]6K0D?D,C]=Y*K"<AD%&%.&ZMF?K'K"J=
MD\*7"(LQ`V2XA4UV1Z5IZHUTNX+EG5F*-,SZ`.(30[P1@YCT6>&F$:M9D9/2
MIV;JG3?87HHAL/Q=<F9P"*O4.2+[E*!%F@(73@V^T`L)\,RX)DZ;+G4Y4W5Z
M=9*LBP07`TE:?V[*\C`9"RXCEIZQ]8'/&8HXTC!/S1Y3=EB:#BXYEJ<J:O<G
M!UGIG/^_78*17CDWS+/^X8-MNX3R#?;I\A?;\G00;\4OB_/DB1A@D:?4-M2K
M*N`3Q[:967UQP;8QQ>#5':9V3BVH/XIJ9B%AH&Y,53]A/)?^UP7TYQO84Q!8
MBQ:D;@\3UX56YMZWF!:OJ.H=\`*XQ2^\HC/W2*(#K[_(7BN]]2S"<6$?12DE
MNP31?U"H@YMFO/%>D:_I4BWL:_;TG)AQR2,%]^;.4RBJ8MFI1K*CG^T^K!?I
MR!%D&\L/9">X,$2=IHHH-V:'?$,52ATV*,Q%+IU?M!<3CEC_`BT;X^6?D6QD
M?EH!G\V!R!F)%AV+(XTCK]9HUF'B+!]*.(["<VJOU,Q\_4Q#[L[L^72[-%T+
M^UN9M[QV`:%QU+#+MOW[J"3K`N56A_V!=AC4_Z.I#YE<I\RV$,$,=P@C1Q/X
M#4H61*3</,9#.;$\+N;$#D[,%40^"/;K,9/D0U)WSW\RR,R*)TO4F^G7OAK5
MD_M,LQ&6.R+\])([JH()]\ADOJ;;T*ANBXE*=:&%T;7$DNNJ!Y<&BN+]+W;S
M%U=S7XIX]YLN@0<I-A!B*EFU\.U/U]$S;N_")Q$.T,..+T"'WX8V2^0(V[EN
M*<)VSA17\_,@IZ.M#\`4-7L&[[74WBG<,Z1HV>]>PL\2M%?/D2^W0<Y(8$AN
MG/*TB_^KS??'EMZX<0['`YF<)\B(DK,B.8D%-#-W/Q/&$EV8G?TQ(V1&'1ZG
M3^B.B;W-`;XP"S#BCI5LDR83PHK,BQDLCEQUQU_2#0+C7=\B4]=,7[(ZSN!7
MV$YO83+@S?;[6^@P^O##2FGZA@I'H^+H$D.KAGA;;R'BI5UR4:@*;93:X\\W
M,P,S\88&<!APCS4A*$3<)EN+:1VV?YJ*_IU?;0^2->B4&45`^_$[=5L#R]/(
M*=7$&JP,RJ7%2O#EQ1%FF;C;*/$\=VVCY_+WZ;FI9'6!JG\0P/SL%[N'CJ0!
M/:.*&84"CG+L6^PQ4/4&,DY@3BP-)HF0&J(2+HAU1*7+ELE)::9W?$/Y#KQL
M&'SG,,%9%I?>"4NWQ$Z21*1$F->\!-^=\O+U*K/#G2HN0&W1XP8ZJE!!X\7X
M8PX7.96.#I%1I<!%]AUG2;":PLB&%49V`_B4"AH'87GR%3(YE2L-\\&5S7RY
MH&-\TJ]X760M2=I0J.3*LXTS_V%=/#F#^[D!Y02[;[R^P#V@I.I!Q)#FJ*MB
M"X0!9Y@TAJ03MJJ=;4$BDF-4@8955#(?&.C,E<?%-S5D4)6S\</,['RT70;-
MF16-Q`6M7FT.5='2DU=PI\HKCW-E&"F%JN75F,_D\F7=(+GZ]+$3FK=L')A.
M:2RZAU[QV<%9B?F_VM\$5Z^1/OE-6K+,"!_Q:FALLS'2B>%>1VVM.JY<Z(.,
M"%2[)-[)0DT8Q;!KL^LB$7R(*\TR+YU-/6@/?I=227.!>@;P"Z<6$&NS6B72
ML1O0.T37KA90<S["P!-2&D0O/I`.MF63)7+_!TI8#=U`'0E(@-PJG!U<6\]O
M'QM/YBQTX8EJI1+UY`AF60$1JJ5"`)V:0!V36?TSMVRH39",__ZS'<B@8[[)
M4R/Z2K<>:BR_X/Z)<*"39]C*['K8#)O9=5+&,%`F,I`^$(/1T^0Z%!-!$A6Z
MH#<Q3XU%^C&.XL*NTUH3ZD&JP:\1B!L):2>Z<;6);BP_/73#^]>/`-WHYK$@
MOG3XE^B7I-YTNP&W"3)-TF/)?&82GR"L<!^&G6?<T9ZRINPBH0O;_ED3FU)O
M3H::SI30P!'\T6V!#>(\LTK6:=38$^4(LY59?Q^IY.5WX?#XPS@J@8UW+*8O
MR>L+(FHLH[&Z,7@C,W!F>W3;Z.26G7ZX3]X6S(4>(YG2Q_]2E*-4E=YUM)-;
M]NS?J=A:\15^?2Q%1+]H`C2P#F$8$1NL7E4E+E-UIT@A#C)EL/9&'/;`=-=I
M/#J=L*/U4\?1SLY58/-PN.F^>RG\OO3^66H-!S_ER*I"[:XA)`U(Y0;R%3(2
M(`*WWS=)Q;?45`[52H7Y27S6I.^G`F6'Y,1#P9FYYYC!=D.%Q%0'H[R5]J-U
M7>0"=.S%*:%?@GO9-D][&?L/^I$1`/8'1F9X2SEO5;PZH[_;`PC0)BAKZF-8
M27!@^9<J%<'0BFR#^3-6K96^[K$R)1(PJ5#'VEZ?*DHDIPBJGF,WVDA@1?U(
M)/6TBZ+%5?"L-GW0V>";>,$!=QBX`=UN"^3ABJ-1L3,J[YDB1CV$PM5)0V.?
M$-CA?G1D70%M^-"XL,ZZ;J21ON([)9N:^SC_W]O7P,E1UW<GMQN"$`$1?!!1
M>35W<+=W27@]$+F\00@)(2\(353F=F?OAMO=V<[L)CELZU/?4,&3<6`[S:F`
M4"PO3]5%6Q!$:Y.K[U6H/(6GQ2`JOCRVQ5@!K:6_M__+S.XEAU;ZJ9J[F_G/
MS/_E]_[[?L,JU[./$Q"T/(JFK95_[?-B.))P-8WU\(?NQH>8=;2!-#"_P2ON
M74,3Y0;PSF50C1M.H#,%?W/7.1-8@2'/-X!FM$/H\9,(5"XAQ;"(4'1VBTK[
MM]/M`N[=$>7HKO$[QJ]Z(=J*"\YX!0FF[[P^"^NEW"?5E:F[2@E`Y>!G3EG3
M($3@D+M*L""1>^I\.`PA80@F@OD"STN//KB(N8ATA8A="$)^,TC?FK)4UL"R
MO?TW"MY7,LW:3957).N2CI[]HC1)B.M9\\%)VDFHU),9AUH'<]D%6O<3O(^R
M<YS[E.P08W"(D-(6SW36QY%"IDO+&.Q`N"UX+7UU@EXXJ018)W^]$<LJ("7B
MN>?;5S)$/;F:K9Y/73DF;9WI**8XWNI_V?K%+K%N%^%S52S6OB$3?V%PE-4W
MW!/X:6048<IAE.BK]K[HJ$M/M-N.NB14-:_Q(>GO933,8U6X3+^B4+Q<4S8H
M$#K^,K-AK3&;+UPM62<2QU;^3Q>#4["WY#8<KV)6DU!8I.BYD(ZN<'DD+&!C
MLDXPFM,22^DHL)Z1JV)\39"EV8`+_`G-!V/:O/'+WVP;A%]60#21Y(;A1#!4
MD2!Y6*YBTM513#]@?ZZB4ZX:R3)2\E4%'-<E55WLZ=<-PVDGLVQN5'I-W2=U
M%AQ/Z7)O?<+<6U<@GV0F'.A.E3E0=TLIATEC=4U?]A/L)_<F)8PH![\C^=SU
M*0U[5F8'"N'IF?UE81G<)=9`9EV7\+*&#+Y62Y3?W/UUMEM3+4PMZAUTO&H$
MG-H[WD]XQ:"3?O6H*J<M"ZS(+)EN+&5H<#9)2!94BDF'.GIAJ0ER5D7LC.O-
M)2.FJ@=$9<DKJ4I9G_K5_5I?*CB>/BKPA>L?.YGL^J=?Z4AQIO3?2<&:2`+.
M!=DF_3!L7]BQN!MZ?G,"^EWD[U.O,!GVZQ;"<8E@8+;M?_AL>Y96A5372)=^
MB?V<'WQHU+-[$R5A;SF2SZ*`-=D--*HL8*2*)P54RCK,1:$]@ZI\$^ETS\7=
MJ?1*%W>/-XTRKN&EC:#ZGXH(9+W$<VPO\9"Y>8GOOO?W["5FQ0DO.>C:=VXC
MDWER*W*>4#6]7@.*GZM3(Y8#66&RUK#I.4;;NZ1/`>FX`FLGKA_&H*C9K94[
M\GXK7.$PHB',]?&+I'L!]P6U'P9X;>_2/B[S=^(Q=(ELI%\MXU5H.8)19&.3
M.,#'KH$)._\$&]"AZ*LR&:I(E^_M^-J$@LW+]]2P<IVA!U00$";`P^;[,7)T
M>`Z5_^A7*61P>U='%CL$]+[JWLQA\1:%6>3_#E#06U.:D50KZ4VM'M??<1NI
MQ\>VDHJ6UF3'4I1H#L3$-3)IBX@%DX_,%$F4_VK;C-NLN`'E*#PXS2@@%OSF
M,100,"['X1\[QQ(0&I%E%AG1Y57M&$`7,5ZL@I#;UNX54U=+*I`?O]FJNHO.
M.L-LTI*[2-+0NU6Q(,Q"X0$T<#:W7CCW05'SXJ+@0C][>>Q7FE7XJ,(#J]I=
MM0GE95H]]_^DZYL\-H_?!%,HYD4L048AI;E%"$22=<0XNK_6;R>OV`9DB`=L
MB*X5`VQ(T7M`X6"E6ES*50M2@BMTX7=B[J6N1`T^2(=QL-GPZYX#-S:"0KVL
M$"S%%@;A?]5#NAU&RQ0R6<F1W*5V*6U?MD#`J+U+L=OL-B@^/>VGE-VQ]N_4
M?'YC@.R.1ACEEGZWC;"&^,21.I7^(>U-7PKH:IG&KUM-'B?EMY:3<36;(9_[
MTGLMZ\L@QE`?A8'>P9KC(GD?=NJ=H`,HY\NEU>GZ3RSP8XCX16YI6.89Y&RK
MYQ,4!3-3A`>[Y&['!HM>+NKO^>H%1.?5)Y40$HX718OMQ0EVM7.DZ=RHY\D:
M2EOJTM=US\K'YN]3FX8_WC0[MO*'?$"CQ.O"WK/^K\'].F1K6_LMH9+:="`,
MQ9R\/3HJ7`S32Z\?]L6"32N?KSPC.WCDB=>^0C;%3-6'.PM8=$E`EB-UZ1N@
M!:<)T9V2"$R!#U+X?/;!^,NM]<`31#2LB1;T8<(SJ'(+'&*MU5)SIK31YU\+
M5RT;&IJ>?]=?E>H>[>DSAX82^'<?_5E!1TC-N7P?OD8K?][)5D)K=M`[C4:A
M,&-5]+X0+7S#Z>M]H>OB5@MJ9Z<B*%B>YC^!BU]4#U6XN=*HME^6,8&L(2HL
MG4G5$8,&(O(WK/G0`&7$(]+*G_D)5'S8(HOY5'=,(5<;6#LI.M?D"%TVI2E(
M3U2,=N'1G[^TIO8(J\A6[KZ3.&FGX!BILDIA*((!4M,.K/0_5CJ+X^\[I)WF
M1R'L-%C!;]$.EY<;4"`R_)*MW/25II10/T6!7JD]<L_CTN@`^P1['4"WKGC8
M!GR&8TLA[9+/X+&ZZ8@^19ZI/DB4@%C1.*F&<,:*&S#]C^W8H)'=L8/CF0QH
MD)A5R!O/J956SR.'F`KMAW^L>OF8)2T[V6%*!2U%I?FS5WL:C"JT/DY%O"L4
M?5:+RICQ55>I.ME'8JV!A^>(T*6CF6V/4D!2DE>L3\0<\`!_O*NRJT]@-*+J
MH[%2>G$Q"Y@W^&6M)J5.%,3(:LBQ\O_@\)8E6/4C&E$;@<M_<`$9@;=\WE$X
M-J(*M&I1&%1:`),*LNW!@ULS12JYN_?/9L;",FCT"2I5N;H,[B5MVTW_M25L
MFDRWPM?BZ(R(#!L<IR/>(%)0'W_.=E#X?\-:"D<4Q/E4ED.^\':]V0.4Y%(_
MP<*!=[6C"W89Y]HJM+1EJHT<&\&XFM-+@<HU&W4NA>19P@9OCF&FYYM=WE1,
MCQ.R*>X^?<#JX5*>2#6GV6+J'^R];<F0[4D>.C=/\L./O135U)F-B+G&ESW?
M-D7]8)(]\^WN%H4*!=EQB0L6B,1!CW3!??3#TG,H(K%A^BK\L;V8DVU<RE?R
M&U9M-2OGZ9X??P:$+LK,_E;/"\-D"\5U;R<<_83A"!/Y.P8ZGI:F'MWFP52!
MZOH8K@;?J`*.#Y*^>B$VWU$+6I7+-ICQT6IXXD@D4V95,`L-.AZ5/V$,H'`C
MJ#=JD!\+N%K61GAAR@5N-TQV6/7.5.WB#HLQ,@:7VC,?"R4?[SBP_HN2U^*L
M?(=*<\]L.P&87U4"8Y-2[5I,9)IH#.:J`S1QJLD--DOY+CG$UBMTC%O^BS;5
MKDCE'I^:F.)@H@=@TO]B1L#:36]-6&4NBT.%GE(]%]3HPA<R&XB\\5@#)@C&
M;#EHJC8:,9"(,+1_.O>_=F1(/A$6:N$+*<"O3".?'X33N=?\*WFN8$YA?48%
M[ZXD0\F>E3<\=`YRK[WFNVV5^$U0MR46F6:RL@\W"0NBA%L?I>R#^PQ5KL(R
MHKG$J7G--93N.*@]]-GA]M)3XEXF`(VQ`JV:-(GE8$F?E42!W17-SS]^G]?6
MO'2=/8D]SWV`BDE!`,78>FK@):F7&;\0O$VOF+!.34)\TRHV'!WZ:EV(C/H\
M4?H\,20=9>4(84AS-,#TD`X>,T:_P<&BI\0AEII47<V>8S1_!G=XF<8=OAR;
MPRM>"8MD5X/)W4@ZO3)"[]K[A,*,[]G[Q;;>8X8Z.Y8M$XZC&:7MDW$J=./H
M+Z@&IR1%CDD#$URP;R_^C\UDK"-*)%4PCF5ZV7M^L)',&71!0K5"Y&")X#,4
M-G:[M:'X`5E(X!EIJI\H?\D?CB089T;5[*5!CY`H\`C=+-O*/?$W;0N#(86S
M"A+3:IUDHN>-V.T8+QF*P$>I-]"M.>/M2X9@'F#.5..Q34VR9<O2MR]3#DN8
M:O,&F^X,J\?;M+'J&889$7M4%^!2BLYOY58^1/N;^^P0XX8[06'_772XIO[,
MK;P?(8E@%U*$4LYOB/9!PCDKJS/%K7'BWF2_#5J_%2AOY3[]'H,%-HX-S]2*
M`DY4X"KO&`R@4]\`<T/E6K;+!N+ERQ&%:8R`XBIO>P8-1T!)*!EX7%L1IIBY
M>DK?L=\;Y@,>S)0U:!Q.#D>YYZ]U.+GJ=H03!$E%V+Q#TPU!%I4RK56,2J%E
MP_YKY6[Z1H=(O^GSO*&<9L.7J#M&/0,F$2HI_T?P9%/%!@N6#:TI,_.J=(Z3
M?M+%8BH4I*!VIG/7?JY*I/"$@$O-*6B<E!@YMY<J*QPLI^M+M(>?M)7PC97H
MA5USXV9F4.?72JS7LGA!"Z]3C>VP7ZC`H!D0?DZN<%1;*@%*GUU#/3,PYAF_
M[)QR7'O-*B%%FH+5CO%!$X80T!K=$EN2QDC]W.RJJ<R[;0"CF8N+V,CDFQGF
M<SUW(S80Y'/?2<_=Z)]/W,W$SE#QQ_PE0]_$Q7W@@1$PH'?L0*/[:]2P8A/P
M^<BO\V]3V6W0\V\-NT.<$>E9?-E\U&0-F>2K_I."96L@^"[,$[%@<7+'AH(D
M?.'MGM\,52JYKS`-(N8B6X&+HG1WQ%;[I=WE@3BO6$542#8)G-7L>?;A=*I:
MM6W,7OP_6YT=)=`S;H[3Z>1D4`;3H$(SU7*=,G#I[MFY5#AWO$\F]V9#`4A!
M7;3@TQ'*]`5GWY\J8K-2_AE`R6C!V>>UK7X11\$]TJ1RO!WS`@LVW+SO9-I_
MBAWD8-Q_867)T#\0(.5N5:OQ#S+R[E%N_/$EOVWCD'$=+YXA<M?=G?6@8$'(
MI;[LMZ[F[1B):WO40`=8QU!5T!`(;K<:FNQ"BUSHZN\ML?V]17/S]VX]Z26`
M-EHFZ)M*C&R(YKWO?9=NVCQU\RO>?3)=DNE?CGI6OX-2U*MW@Q_N4?7(`+R,
M`LE3$',:X/$&8529C"_VQVOQ1?[H:*+8N?[HR72WXMI:TFR,+P[UXK0')/>$
M+Z(P4`OXV6N0`"CPJE2XI-'S!/=-G)14.>"^4ZX?>.XHO7T7%JO%L+ADZ%L;
M3)5@VRI.DH!#8>KVP[YTI)Z(768B6#I8\E-5LIEPGFY02V.VZOYTBQ:LNR"[
M-2O(L.=L-D%VZWX$V;S'9Q=D:F%S\_:TI0!%`_GEMWQL!.DVYCW.H0Z-%(^H
M;.S2UEP6S4AP\\5131]+YKKB#N&*2^50>`2#2HD1L+[(B`C(C^;"16Y#D`Q;
MJD%%:!P9294G"]\#O!Z-U]C$_6CQ9_SNPO;6V83M=#X7DP&]]W,I84O25!<*
M5J7P/#/;[?ZXBT"L4V]AF7^2,!4GF!^HS(SZ.U'`U!G$I)7[Q'P&9<1?@6%6
M_GJZT3U;'IW[ZA06ZZ[;P-71L=1%QU6WRJC%=RA4(8/^+>J[XCN44B$U@8E8
M$;S=YN:W3EW.45QK&(47*:Z[/@+/*AQ4;`YZVYNHX//4(RQ=:9UN;0US.W'V
M[.3['FOS:4XFM8E$HUI4*#+#RK7N\9\""0-2\*-_[U@YQ9B[OYALDFH7^!)"
M3,L&P%4?'TE>V,T*1RSS?O+DMFZ$E4GE""MS2&*(4Z.0I,'\P30]]NE3M<9@
M,+SET0M>LN\-,^&9$>%!X'\6(&/8V=]&J(K#MWT-LTV'1#?WW'479IL^?-T5
M1JFT]X]IH22D@K6:DWSD'ES\'Y*0+7V@52`^8B)QZU(1IC%?EUABM"VR`SM[
M[78<0:D[`"1'R8&%0Q>R=Z8``[3[8MU.:<32##S^Q0^M*:5QZ+"AA]Z/],\?
M]4"G]#_`8]*%R87HH$\^KQM#\D=]8+\5E[/)4I7K%K]`1T/8]^`1R3>4?(Z"
MZN`UX#YK_.+]RN2>[[),/C4ED]6"L)I6<]@AI`^`I9[8(IL,/UI=E1D1*8[O
M^)**Q@,OY8L3E*G#?B8C7Q(X>U/W^ULGF=W+MQZ4+90WLYIB<S70,P(&/QSE
M?GD\H=(@/W/3J83]TST?^F,%6<H]'B*X,(XINVBLZ94H.]I_-#&"Y*_ZLS6U
MZ=P)>]1L]N-XB%27$"J4!<7'2&%^@P+]A.:&1&JDW1(_2*CE`?Y6C-7'))9+
M)(]7&&;@UY+S*J*S$<:SHCT)G)9MFSS^`A=;/?[/;</^:J*:H6M[;IVH*[9H
M3#4,.::RFR'E[Q!F:\P;NQ7%(AHRF&9#@I84EJ!,IIPVL63LYKQ^;H"FXYXM
M*"KY112G19*\#3?&+M=HWO?^&,5JH6")J"Y7M'KV?:RM8W@J?2FA1<2I\HI=
M=P_/%<@.3X'[N/AJL=<X-\H=-90"\LDM[.O2+2=SP\&D5NX/W\C)?-6RWS^=
MVWF6RO')GZ2ED;4(7)+HQAQ-!<T$:QIAK1=!3?">#-PN''9<"W7>3R\L85Q=
M4/15=&VXR^O%6;/28.RA\=KAB"ZU'=&7S\T1_>0K?^\EK"E8PS=3)5XK_]/W
M*)+[6?8,7,$XRSQGLV&<]D<++GM%FK!#NNF\4`.V2S@5?FW2CV:W:>`:KE#J
M+&46?`O&;".3C.RFKB"R,[*MT>R\_#@R.T_\6U951(A)"6U]U&V&X45%8B,0
M$EK3]:UST/9^EWC,Q3[Y=.->%=,LFXKQ.#E;I<5A0I64J*QQHS9`*L1/"ZQM
MJM8NFG_CS>V^KB&5<;=BU;^BASI@Q67)QU&]>7M61__UW/='P"V\K+T8Y,A*
M!_-(\<7P['"Q^!8HJ7=R,T+7IS6JEO[<<]'F=9<(LYN9K:XW,@Q'E-M[/QD'
MN__)-%S"&EH]15K(4@4">%5?O*QW#?Y>X/3WWE_Q)HC6+YGD.BQDH:`_4".!
M16;-TEBED9L-E%`VC2.Z<8TT>=#B4'`LNB*O_@Y][2(]%FR<1$"X+D;G+%"*
MN[32C.!>-3<":82_XHCZ(=[2-6FXHP%-FI("]VWU?'3KK$J+(2+@/.)65V0S
MF0:RGB\M=D(K!TEG-NF$=S))`3A5@[CF]WSN`!@@&=2WW)?B/9>O`]U\S^UM
MW.6=X(^#VZOA(!T`K)79\2S:Q[173!:5MFB4.VFJ39U])^W2H,NBZ'P##,^`
MUQU%<X@T3$TQIJI2URQ:#,I(]O3!T#>1]TG%`&MAME<FK7X]H[3;*<>D>FP7
ML=?9,J,\SVZ&CH#!M7+AH3,K,:]>/4I:CZQHVS0\27X+;\)6F6*'EU7@RD7=
MZ1MK]"\BDYG=I+0`S,.&PC#KH)#H$J9=9FO'P^:F'3__D=]_F/;+IQ-.["8T
M"A`4=M*"A!TA7XJ[CMR&JMPD*T&!E)KCCMIRF.FJ;;S)P2EXW?=\Y1\.X):G
MUV.*%>4'HY.N^BB.,\=!T`O7[M@4>C?1P-[6#+=AR@BC3NBF-*U=P6@<KSYS
M.WI$^G9V9@;@);L\C-X6'/^Y?[)VN?FK7_P;&[\0NV&*57;<Y_3RVE7EJP72
MTUR<MA_!7=-QZ%2/AIB39A`N6%3#9(!3%?Z3GK".-LH9?:NT+'/5NM08RE=/
M6-_8455G1C"W$IYP647O5>D[BF6[M#-NHW24H<^^ZD-=ZBO5T%1WS8,ZNCQ-
M-R3H%Y6.#QYQ^=[W=>]HF658\_K4TJ`&+5;5@.NN^M.9SO+.],P3(*-5K+O?
M;YX===&,V_WL=L`P]I/VM,J78T%B-(_2N'=J[$SBC/(@:=A<6T;H(_<B3PLF
MTLS=LYP0BD]GPAMJ&)./L[=QM\1)MU7-)G75H)S-34\.)64RD].9)*+`4SHW
M]#O,3GT.LQ-USL[O/A7FJ1(\-P_6'Z?#MET"]UVR7]9LEO5PN]>MWASE[]S'
MLT<1B^P&:;13!Z(+TN1^SH,=8M8!>P$]3)T'P84T+RF(O&IDN9D4!??E%J7J
MN<M@#&UJ``'-J+86/J#B-8N8QC><1>Y9D&`R>[;V.?#>X^;RSE$*UC?L1X_M
M[Y3"A(#KEQU(F.=D).7HV.#EG.8-ND"&XLMV`#G*P+_S^5=\9[B$M7(8VJ=0
M&O\MT6X83E3T\29!5[2CBY9)P4`\>H0T;@]/(T/WZ!>RH'OFMA#=WHIK?E*9
M5C4^#,P]5`P:9^OSWW$J!7-JJM,*/]VVP@^?FQ6^^W,O0;'$Z8+"FHV&8W66
MHE^.V4B_)T`C_<@;/WQ`(SUCG:==3/3.AJ?N//SB-2(F0$H-VH8W_*Q,N6C;
M+>]2/Q;*SA]BP&/+%KBC7",4^%OU'21\S!WT8^J.L)*Y(W4]A=[EVJO]23<(
MM!C3[@1>>@#3ND/[X3VCC9WPZ`)AX,N8\GWJ:OP1]Y?<8/6*YN*G]],K:A[G
M5TIC;E"5`8I^,%%WZH&M2K)2E;ZFBU#M^@D*:5^W^V:OE=-I7VO.:!:\K<.Y
M/:`*M\=-79$_^E/MWAFUX&T!_3`J2,*2:@B&PDSK1[G$4MOX0;`#P,>2^_@'
MV1[\P]8E`V>_15\.S\;XN%J_N<4@,V_I92>0[4]2419.]`&38?8"@C@RNPPW
MB%.3A^`/^D#`.V#01ST_&_,T(Q8;>H`VX15I*&C0XWM6@,`8OGMD?=RN>D$@
M5)[6^\!QE)OMP&DH&W`&9Q!/2:-@EM+,$09*U=T<@@(S=%'*BR3L([GDPO5;
MR%`UD4Y&:*":+#LZJL@/]"BV)&E;41M\Q<RVMTY(I5%S=X2G<BASYE21)]8W
MD#H55:O6("C3=7.P^.AEYFKP[;)L-`5S+LF4[CX0CEXMC_K^1$$@Z^$;U-]Q
M#PZ,NL@_!BJF8UTL;X&&J<,>4R,XM;(WUG&'F5[XEWDHAO)WC^!AN1!.304#
MCPV9C%)3&-KBI\%$ZCA([?XD_02PP.0)9(O5Y.06^2?0SB=\_3F)0HU,14-K
MS]N"E(.E%4SQ@FQ%&SP7-\7-1W_AHZG:B107)!AN`>$;8LXQG2[%%ID:O32&
M*F9/G';2(-.#CGA[AMW>W>D6!?5#+?1PE+_T#Q0I5<-/_"X4][%+='S$Z:08
M=QT59;>A\6&"WO(^4..MW-;O<\9&X0/`OY&AHS$2Y;9^3ZA5.5=#+$+FQ:B/
M*E2E]C:A-!*9^F,N9A,5ZK^`;,.B6*3+HX2;R\E>&!UQGJLVY1R%.HQIH=`M
MF*N90JG$GXW()]V8F[?4QQ"F!($`;MJ83>U3_9C-?$MQ:Q09P]%!S_PM\LP5
M"<(5:1Z),LU)&,(.*_O(.VH6!9L0GL7A7#3(6CU_<KUI-0Q":6O6\T-,X@D-
M79*6X#&?J!1*>"MU[H\[0;4_ZKGSG03=86Y0;$8$9N`H0C-1'T*\07/9)`6G
M7MC0VX==`L9GV*;J$7,S5;]UP>\]G0HKN<P^(_G1KV7.2"<]A,XP+J+.S8.N
MOU<S9WB!L'/U1_D[>KDPP6:+J[AEP8RVDJ=VL(DGN2M^F)4O[4A?+2\LLU*H
M\%&GJX_:H-I[6CW_7J'MV.%G,&-,&DQ8]62Z)62+1YYW1.K,[\+8#*,@J0H?
M88%7G1&Z>9$S=27UJG;P=6GA='(^:5M*TQ1A)5A\;\M!@FYY>DTZ=`<B=$T8
M-E-$;XH^X;)_I#>O>"XSRNF&-RX<N>R1-O:X46HC\:60PZ.*B7@T8-YW1EDJ
M(6\'!E<#0F#EMJ)B,^"4DE,CJ&@&/<(VM`:B<>3;$W"':J#KAFECGX[HX/<?
MO,8@H?1'"U[VR5$NATP4SX'J\2P'4H@6N&7N#Z7+O89N7:J`N_]QC^BV&2<W
MP#QD*MM#WXJC6HQK!+CBA!.8N[VR9S6B/V@6W<_^E6+3J:'""AGS,F`8SYIN
M6T&`>[^&4IHL<Z[HP*J>H.G&VTJ!7P=[[\0T4'$VO-$5*R_5X;,<?<DS;OC0
M2(E3ONA#2NG0UV%IK?X=V0H]3WT[0USGE`SK`<,U//49;NS2+#5PSJMNB?B:
MX8V:-4\DBE.!';SV&:S=.A`W0IA:$K2T]=BU8D5U.U>=B5V\/^$,@;)!D%-B
M9*IT9:Y<`7HC8.9N$.4N;`E\&M/UH`)S%S5"30H.1QCS&!R'LN!A.POCZ`\#
M!#WD4?%7`PTE;#'BMEAB[JPD$[$[J4K*P@2.=^((*:57P9?`/E_=N]J?[`!5
M61EH$`8:H<!WK7QNCT3YA^9O0_PI9(8_<3K_T-NX.=T#]93`,04Q1Q$`&!S-
M`=CQQ]P*MLC+F^$XJ*A&(@V2>)+N^3Z([803$XEH6<4.HS#<4U4B%B(#\@G'
M\*YU3JISYV6"&U[E>1%2!T'=Z`3IX_'R#54JY?OU>MF'-!#L<:<2VL"\4<^O
MSVI;%-'D*N!!K[H*QZWS>CSW6*GOIM/R^4_=7Q(20<EJTZVS&N]@/I81#P36
M#&;I73]?`Z8.0M\L6!B184F/];CQ%V8;[3DVO0SDMKP`&"@!$D:]YC\HXQ3`
M+JQXM/D"Q5`E*$,*5$I59G%=(MMJ2.%B;1S8**`,`C!DJ:4221;V?(+0M%5B
MGF:SE?O'(\0PY,YB7"DX<J0\=A&AJ2*[;/B6M'_DW]LI8F20<3_#LMQ)3G@7
MW0`5:<4:-=N))[:7A?#3',7*(Z4V,EA\Z?.49(*$!4UX6X3A'_ZF4@>C0N],
M2TEB8?(`([']B'H3:3?".G9PPH[\^6FTJ+,(J`'=]BF"JI6[]L<T$7`&XV8]
M\TPRB(F?"GM)I[`NA5"6"+<A5J61..'4SB(PUXF:K12IZ:VFKS=W]W4H&?!R
M>G;%HR^&4?%<HYFO&I]#98ZZ0E[GCR;<&*G:ROT:8=P)A)TZ1+J4)GU.%K=R
M9U]%08-SH]SRA>GBE?-/T_QV,56OP&?I][D4MM+95PJ'4V(B3<9Y*#(/]OFG
MV1>HZ69:OB![N9+F0JA-6,(6OXKM`W+%#AQ3]A"Q<32T,(9MK3V=/^DG8!`C
M(<VO_ISZ]$6RE-#\Q&-.`A?%M++AT<AS`TW$F[@'U'!6O<B89_64DX)MY>YZ
MDU$Z\:KM-]%3&@889SKWA4D2G7!E%^\5EXB?,.XP"1A>2&,SIJ8RB@P:,[>;
M^Z$RAS(.&&.$:P&,IP7!'ITD)8O@2SI.'1Y+-<UB5^2O&^IJ8EIZ@]\>_HT,
MU22)N3H+G@E^+^P0G@B0R*^\TG0)?&"OD?IQ6"=>'#K?RLY"<IU6[K-?(S^+
M-Y4;&I2%SJG$X1(P8L`Y:]'S%L2]6I<EB+(`F_8;/X(3AL-R,;#G,KTYH;N9
M[0.J`8O?R.I6^YH6QZ]L1_CE_%MWP6M0KQ/9K8S^PBN`D\N?^-8M;=T.E>V'
MUQW1X#3=\E-06]REQ@>C$"W\X$W=K2]SW&^RC_MTSR.G"-OXZ$WTA$3@$L$H
M<4;Q8"<=57P)?R&B<@TBY8P:@%\1?'$$%2;;(VR.C9&!HRK7X/LH)JB9CPAP
M>Q=QXQ"3_#B_&2<'W1V@28)ZX(7<0YRIQ<.:,6[,ZSSA47[?1@)@;>5O>2]*
MBE#JNT`=]6H'Q:<B5Q4VPE/=QS"MX?BL-@,W\N]9L7)@XPT/G7/INC9:5INV
MVOK8#-'*W;@4GS[NC8W#1JKZ#<7ES0:N;``2H$JX*;L[=^.)[<P7PT:\[2=2
MBN/1NXOF39O3NRZQ4!?`EM[),C4DL25,!KB-:IXK\([)9"B<C+PQ/'XF0LY6
M/4(^/*"TT_(-UI_\\F;#-JL[@AQGVD&.5\PMR/'X3W^O00Z\8-6A8)^'K?PO
M-A`=%:7-=B"B3#R)O\3^!K8#G'@;']=]/VAO!`D/$S%YHBACLINH^30`#Y5@
M(,$H&*N)66V,(`ELD.7(XI3;6?_U5HOMA)N9F+.2*E21PX$%!"ZH;@OK9EH9
MRU9<2V7?"-D>2+L%/^C=0$=CW*G#AGWO9TA*<ZB-,7>HE%T*1EGQ.`H(3HDI
M>+8)F!CM#P.I/'NA+P4**OD5;/#N3WN]C?&``%FL9(;J"D/*NQJ*`>%OQP`I
MGZ<*DXFG7.&EY`JO\W?=`\>=/.%:O*DY>L.F*9G<!&9WD^LD01&+KBWG>*,+
M(B)D==3*O>F_L@V2PH'%P#Z"S"IMFKA!)-9(>)1.8Q8"MC(8?8A)HRB`R7:C
MMBD5+=&].Z4T_0U".47S#W[_?5Z;8<,">5W!B%<3R$A9-G:C*^"6U@@*.0S;
M1A#FLY5__T8#Q_K^GE0+D9IWBF.Q".;85"C%M%'^T<NH.ZN&!B^(!@13I-<B
MN0;SF%AOI`RB2D5@.U"K'9-@2&0Z]\QUZK-B5T%BH5[QN,O**;*M9*!;D$_'
M2=(G(&YD*7.5F<UV2I3[Y)Z2#[;6S&@:^TNA![7@`A.X#ZQ]86\".0XT#]AT
M-L"+BXN)L6K44AJ+B2JGN0-%&J8$[X]@C&(A4*:@,XMI+-_#/FFW,4YN7,A[
M+.$=1N1[%(CWS4XP5B][$V_Y<=DE5<DX6@QE8T-I2<:*CWB'FNVF!T6/5,$"
MPT.KRZY`15UU&"Q%IN:ZY]'S]ZQ<M6(+^.V/OK;=M:>&*N-A1^]>B;51O1-]
M-[PU;O=/]_S;G;O=:F?[2/[J?VDS+"O"9P<J!M77G^S>@/IW191[W;]T[SJ!
M2YAZ?=X-?XT_7%':[JGGF4@")JQV7_F&*[N/H29XE2+7?O),CR&,NL6C,U.:
M09?$`U'A!4FPBL\^)B)L;F).5K"YGJM/@KDP#<\CG+9%NBT`L?<>?5H(%+&A
M!WT!H1U3;7OXBFAR-!5,+"*<584>@["6F2_$<L>C!;_\8\6=HSB%89&?O40^
M5YZ.HJN5._53.*`%'D8U:T&-=LN>$>Q\./4OV@J+$X99=I:7R:7`3@V)60]W
M>8.ADYD.U(0L8(P*V"QH8YKU8E0Y@=VRY9[A@F:OO+.Z"RT?,M0]./4D*W#Q
M53<FI=92W0PGG*20XW(GO*H#.:ZKME"DNA0X(C7&\E&%H(4@CN/"C`NF8\?D
M2;7RM]Y+EW`Y()Q)$`$!&=*P(LCFA1YKS26?#B7Q+[YJTX@0*0#FGQ/JB27!
MA:M[\.5/KB?B<Q@;*:7HQAT:?ZKLNI56WOE/]6&[.C[L!ODPC^SSA`)=+"!Q
M#S+&](`?C#DX0R75I*2"KAP61V99Q[@)B.9XWYC)@"R!3;CK/]>D4C\<W7%K
M&'&#?4K6M+:/W-HX3@H=.!WM8D!!A.DN>AAK\\M*T:;7JY4[YJ[4DN%WH!SV
M2C%;QWK250RFOY4[^>M<@49!L6/N$N1`1X/J%7'*W;B7C2NGEEK:W'LOQ9B#
M0(:A1VNK="OA6N$84A]O-(_;KLE;0^U>EAS11'IEX"]C'IEZ^;]>4];V!3A/
MHH6J5U+#5M-@7"N;$DYHN'7_U@]3R+(.ILO)4DW/$QE)2=,XQ9DR02GN("P!
MBA7N4K'"C,5@@\6DCHPZGBNYGXF"]`OJEV>4?ZA\58JH@LT`-B"L5*)!?)-P
M$J_=Z89D3H04:B\R30YXLZ-F*=3>L38*3/`9CZZ!O=OZ)#?@)1Q[H.@`8R7[
M4G\2%RL(JZH@BW*?.`COT*4BE#2T)+0`>%(MAHL2)$:+LZ*@FP5<P@((9!N8
M-6DT[^$3VL/@_KSI^]=N]QQ&1=.L83.;5UVQ^M+UFS>];=.6Y2O7;(S;!Y"$
MUO#=U#+J1GS8A6.EF<;P-CU?)YS0/I>J#5*_))Y&`Q10D6@DK;S>9=83US(`
M!Y@\,`%8FT//6G^=(Y6-L$0P^*#A`B.;`J\Y]XSS^9KAK?KQA4+A+69LM`*B
M_!\,MGO!IB*%RU"N.`%+A_IPD'?\^_?3#SKU5/55J=^^V,\"*R/*Q4_//IN;
M'_P,3-R@?O/!00JC8#^'/9_;MG7SM,^R/>TCY^9I__1;+T'EZW+$(P07;94J
M\?K)7Z:3V`.;ZN"M2=6=E,*&4W>F8%QSGSZ1C8)/'Z*J@I3+4F94[XS/DFI-
MG:52`8[DEX]&UXJN575X]*7&93<`81@+>^)>#!.XTSU_>XC&SL5S3)"Y);?L
M@)A.Q!EF6402QJ^Z61<%PV(77+F!TW-%%'/@[("<2M#*UT%DJ5AOY;Y[&E6L
M$VLTWWW0X1<QV2H[!RI0KF(&^)J(!GL+&I!X/_Y1:0.K"1DT#-NS!!^;-K2$
M&II1J%WM?V"DH49[^V;E5:I$\^KKK0(H\$P[VX94K%,F2WO&_!5L@30PLTX>
M9JK2("N6377353.%]N(^"C2.&`QEQGPF[@A&MI(^SLQHJJP<!L%1-`HQ)C_`
MRDX!$&-9R9*IZ)Q7?Y#<#R*@)H]'NP-G/X7'^K`3%3A$>TVYU5-_1K'<HZB:
M[JG_3;MC;TK3*8%1\.`Q.U-)%T_*87!I)\!-^;&;B7C"KQL9U+VAV;)^MFQA
M\'\##HQ`HQB&B`7=@[<'<R>H4Z,*\+=7P[>5P'@A.`JK)90%I"[$Q"[GJ0]&
M8\>_'3^;&YHZ/MNJN0T;S4--)X*[TY6[05N5!G`Q(^(FJE81\UTW\<UP#D1=
M*W\W2<NB6T(&W_Y8_F(%M+A@U10UXFC.SKH::M2K.3Q9=OD=43Q6ZF!D[!FY
M8H.Y<;NS\\`W[KF<*G*O,)\I47)U:YUJTOR*RHFIMF]L;B_$#$34G4X1K\XT
MV%GM(5)W;*\%9?<$HIM,%'9)O+`(UCQLV&;("<!4Z2[UB(P%W6=[ES7;IE`6
MF_]EFO&$$L,PNT!P*YCULAVFL@=M*1VT-Z,\1C\>'G%684@=J]Y55<>K*+4\
M,'%!,2PTJZ,%>'S<9@Q]$CI%06@VM6(ZTY\Y)(4^$R4#*3+=\]4G.K$-TG!`
MG33-_&&,$]0[4ZC[/L(N]/SP0S.%<I6:>`L,-P7_J+K5=A_5D#"204)=7TJ-
MI,XLNMU[?FY:[[D9#&S1O_OH9DG_VLZN7%8HU@0GU<(<HKR]5R+:WIEUSH2[
MV;W"0.RT0^JPISPA@0@X=$,`<A]=22&_"WT%OM!05:!X,T(.=S:@]>R*K#.N
M`8-E@++%'&5`M["N/.K9-=I6#%*P<Y:]]T*/RFP=P7RT93B5=%.7\:*=T?S3
M5QJ#N=<J?:5MSU$PF>4^R4BEE9*MP=.H1?"A)^V]TSK50I'4^?P9K+.5Z]NP
MT;D':XR!S[M=CB73<KFJ^:?)FN5RO$:NAS,\0?K3=0JG2M]HUWO@0KE%)^G4
M5,)YZ'8'4H&[@[2;U,FCVL71;\R`S54O.%ZAZC7PU`TC%]S@6*TYJ%8Q+(B-
M3#$`A[&H),L)RJ44LS#F':=BD*I,":V0@/*\<OY@!_SRS)$H]Z<UM%2F<W]Z
M#87&_'+"]3B)CTY?$*!)QHSKLII8Y/!GUZ,=9HH<KG]7O=E(*`S,=I!B9==8
M^FC39PNGLY@(#+'488J?;9OBKYR;*?[KX9<`"F+%5#3XG^O7A*W\O8.;A?-[
MN8MM@?&;;YI^$*;S35,WOVK3-WF=5W(&NY6_]FZ3*[AV6UOC6:KJ3@P0!\A2
M2Z&F@[^\W!?+C=/8:`>:X*3"&#")4&-K8U@E_[T_,*&\5(1O!^6O$.A$<'_!
M5"3.:V:ZETJ(,6(M$=(/#GKZ=:^F0$=5=*_GV0:&DYDPBBB/]?#HN+DL,%6^
M!^F%89:X+&D'`_]A,+/APL52L261S1(6]7-1L+HL6QPZ"2+Q#C:ZW)V$6*-`
MC$N21T%"^R#LHW$"=ZQ)<00J^NHED8`?64_(5N-Z?RKF1S(4=6)(H5ID%+!W
MME&U7>C60O=$,-ON//R):Y@?I`R3_J,L<A1_((6J\95-+F*V](B.<'LUS?'0
M'RU8?0E&1P*O*"=<TQ\0HR&H%)"@"RZ#:=6\$$6KZAHK1G:Z)5U]3:_2:UP#
M/_$E&FES"9'%A+C_1V\T@#JTN?(7=:FR4=$=\D%4G%KQ-Q/=GE+Z*AS%CP`?
M[$]NOHBBK;C/P=L:RJM&$>*6%<>EHAP6W4'0+XU[R&/IRW741W+@I())Z(0D
M*\'^/JZY67SM%509O.J'Z[`!+P)/>Y,Z=U,WO_+!7UC^]&V3.KA]F]N60BCU
M>1UMC-V1.<UNHW>G6BMF>3,E[+%N6R,R#0'644O"C6T\C&(G207A\^.O54C=
M3@7;E^VX,\VU>0G%8>EH/AFD-@/7,J#E":5BBJO8%:%WQC/RB-YLWONZ-TAF
MY@7MKPM_Q,FWCWPVD-H3,IKLEQKG=Z)<HW;<*O08KX'51&X])&=9QZIQJ_9\
M=+F@!U=4'8F3PFU+]WHR<B-'HBC[`.KR]`K:AJEW40G56->087K:6HYWO)I+
M*"5ETFQ(?94O7'JDS;%^55(<O0ST"!OZ_1_HZ#<EAR*",14G'\P>_JB1[Z4]
M@O+@^%0VIOAY!K1*R!]T93#5SP8,Y2TM#>+\)FY%XR.NE_50*0_55SO'S6TT
M%GQV30IX031Q4D&E-+I6J"/+])-78]R^XH?<,6$=<671GAOE%X--'9?A1Q`=
M>;B4M67W8F@YK$^N:HNMJLE*<"I5CYF<12PFV/Z"2:5M_V4;=%I`LCJ1@KO\
MHWMH>^ACE;A*<'DU"DAC^27JSPDD'ZMQ@`B6SU,J7"&U\Z/;9;>B,=IIKU-M
M?XUX[$U`@62WYK$D]X$?:_JK3($2=G=T0^5C&7;9L1F9D-KJ'E(8D[ML,@ZZ
M.AGVB\*[MA%*H]QE/P]]+8D8`%5F]@:L7\.JG3]BU<2I%*:NZ9++57DE<G7X
M2/%IDDI&6/*C]A"6'9$,P98&=?+&\S:;*GW2@]B$H&H_$P?K_.FY&$W$>"&>
MJW$W<0\KXER1-9Q)Y%A5%1E5L914Q>H;[@F(U]A6%G>FE$7^JU>J_9?_RO-T
M,L;&*D24&[@F3J<88*R)L)%D:QGD0S`5O_7(9J,N=9Z.:@'A*C#;KYQ'F;8W
M_SU\=\4K6XH>BYD,^X*DM6E])?`G#-M=%&K(IAE90S;2<\KT'TC%RM*:+J3V
M%)?Z?/J501MP8HZ&]C"\Y*@27:F-N_E8-???6,<F<_7!=6:7P&@A%PQ[10
M.%^B8MG*\5*-7=@.Q^RTE4F[+TU12"!"U0!U8&0TM#%(K"-N57P-3]VNC,(4
M]^FL-*0&Y\IB+"5ZT@P@NA=.YS:5L:;+Y[T<TKZM$K@>_!=;VNS.X1^8(P]/
M!9S)35\A4XGZ;RBP0@X'[1$X$F-8.X0'WB!I84S%>!6(!^ON0[-<>F?R=[T&
MH_[-&NH%TKP6&:>*06NCD*P,4CDN2%H?Y\H&I2YREGVLW^ANK$<]_C5<C\HA
METRF%.G5$8H%3OS#KU9E%THI3N<W?AUF13?;+:)>XIG-J]=%^=<_C:WX_0FM
M-`E^;4MUA*JF<W?_GQTQRA!5/=4E7-7PE7Q(I*",9IFR&48N,L\6)RF\6C)3
MGV""M41WB3C<X*68X)CAB8B6+2JT;EVPY]B^\E%S<I7G'[3G]UX@NJ;6ZKGN
M&$K7UDK]4<^]UX'QA6T?9*9E_+183#^GDO94")C>XV(:RD)H4YYU!@EMV+AJ
M"YDM6Z4"#Y"97DCXG+>L#L$VB];,9O&.PGPC'B@8I*?<KLOH<]%P.VW]<12+
M!87D77!G6_;?-1]1CA<[;6QYLJ]%R2<!K4O("EI$P91W_4R1X8%5\>3T"MG=
M\%I8NQ,KY01CXGFG&X3LQ9A_KEM5T.+\`C5ITMY!Q1'8SU?R=09*/O@`JI=F
M&NQGB=/<F4E6Y;]X/$4R+0FJ6+%)<<-2BTK3+60,0$L3@PY_0LR6FB(9O-UC
M'R'S`>8C&XE7X56.I;?R#R4[B.I-N[ID&5@PT[8`QK[[:,$Q/T8X5JSBH5``
ME4&I"&&:J[K"EYL.H!3F_/>WZA:KS;LT]N(2I455U0#6:1Y\'&'/@=U?`V'U
MNL=&*LS'PVLS6O&H_E%H`7"^Z1Z,J*(U:`<@\HO^CL(^`1HS.T81Q`I_ATW"
M/B/7"D%DB=WP(O5U-I7EWQ0^9K#ZL<6"!R-]3PV?\'+)D6KCJ[FNN@%UO'SL
M4EHEVK=<D=<[HPG$ZI6X+;A)O#8(8O&I#\[4RXZZHJPH),;"LKX8M)R[I-VG
M"J)'$WH1TR%8(6=&JMW09$OE$5<PD2E8`.N8)5"E>S8:)$>C_SL:>BD-IG?M
MN$-M`,+D2.B%\,)"L$K1W89?M9B6DX:`N=XQ&\WYB]#VQ-"8R`^:?%:3X[5!
MDN:/F9*"J!#5VYIMZ2I<KX%7P-]+WF%%C+XCN9-7]0Y0BB9BB?@1#<<.^6FZ
M]4EYRY%FZLYT,+%/6+-E0-5/S68&?A/6OZZIE2O"#ZKY/RE;`J+,U?7`^YGD
M+F3OUOS-B?I=3?)R)"/_YV/H4[A1'=TXN\C2Q_GL_D$Z:6S@0ZB.D-&A51"E
MZ'!]9TEU@-!"^%P:(9*[2148,',JEM>QYY?)GJ?I0O,+5Z8[<V^N?S=KL?[/
MI<K3V>/B4F2-DDA9&MX*_".G'9#6S3"E::^3H:C`+16F-HT=C=GM*/?G47:U
MA(]]$",^1U\W4FOEKOO_&=^3%#&5&AB<$M?$9"S!CN<3/UV;Q[*7\$Q,YS[Q
M&WS-F.TPYEJV+3&2+.S()F-414Y:W_L"VMC<*3Y.]23:"$DT=7&,U,5H81MO
MB\^-T'4IR@1X*BQXNC?%T(FCVM%4(5;QACI9N!?S_SOP./!E4R=3/G:,&@B^
M=@[3GP]'!WUYOBD.5F5P%236S?0D6O61Y+C3*'6*[8E%90$Q,)E;*W_P\>Y.
M;!]$)7)NE'?>R[7DW))%`6XD)-^P-LHO_#E3JB+>A8X\E=PZ5J5(O22[(_G3
M'^&"(&X`QD06\6#I6GBNWFSEW_P;XT10`Y4[YHEI;-JMG9A8`3#`KDM^8?7*
M3:KOCQ9.?D'8T4NP_4M2G=%`3!RK3D@_D[+P'%ZBYU`_L5MGFFO%,4;+*>J!
MB)0D$*+[&QB"5`[P'9(/9[W?RAU^*5MD#-LSP?-.IJU7A(EUPK!9K1MZE0X"
MX</?J`BEJ`]&T4_4,]@^:`0C/$^)D)9BJXCTZZ]2IS;*_7C&DUP^[4WD#8*C
M#U:=2UE=DEFE$F5&1D>12];4AEDNG^EJJXHRSF^L2?XB'WW&80.K6B[NC-O;
MPT(\LW/R&OPWQP09:9.H?SAZI4;=?<7D-='\X;M!:"ST7GEI8)FR-/OX7U[5
M-;5>K=S'?^74;-Z>%'F,EM/-FH<&7&52Z4#<F.=&N:]\`]\(:[FX@!9;Y>WJ
MM=Q?XPJ1J:V_%WNFCGFY5Y6<@B-T/F05"PMVX.KA4N58H==H:B(=IIMVB."B
M"$**&B_+(+RX(E9-CM+,Z@"):&8]3,$(!E6C4*CI4:Y@57FG][ATR/8>CYZ;
M]WCT,R]!T>,**GI<]<,LW&<F)Z,5WHA>\U;^TE]W8U$@X:1#O]+-J1J&I40=
M^;CIW$O+\%B-2BSPJ&KR!N-D^J,AK"5#/5,PO]-%ZGEFOF49X55B%^E6#1(@
M1C2+#!%9ID%UA3_!;D2'[;C@R%&J)DPY"]3@$J%\YEY@M2\3.3)<T\<NDR/&
MS2*R2[(45\J/@2U,R57%+1'E?KF7<V]6FSP-FPJVUOR$L[[@"2.JB]R>;8%?
M_3K5S<QX!?JQ8.F^<P-^H,*'H'XSB8?BI'1;9=&#O4OZ.#'$J7*^4#5UICF%
MCIRGC39<^=ZE?2B6,9;?(&L4%`]E2N")6+=)!3U&?_&;Z#K)11+9-Y:SRH]U
MIS-J$(`(H5)0]B\%6+5R*EKR.G^C\`+D[QW<J`";;+0J3I^!\U,7NA=O9SS&
M1;@AII\]6E%YOY0?;B%&6&NO%PAK],^?3\HAG=N&#;#\[OO&]RU^\.KH_GDO
M`YGP,N:?;'CG/(SMJ!??-;)^]W`T[\9?H7E<=1%^@$I8_,07Q"?X?ZK#GZQB
M>*_<J)M&UBCWQE^W.9Z?OWJ>"G!CY\XX:@NSY10H+--SILTM*I3+1`:U*P&/
M*Y2<6L,ME-QA+$H9<+"Y=;MNYX&_A^-ADZMRNO\=87N=8J$YD;Y`_(G5<,Q=
M:MXE*-(+[!&5WB./W6VP04AMR58K+V&+2':'+`4"*@U)!?I!I809$+50%V'`
M5!AGN%M(;9/A65,_"B$2:P")P!3?@6)CW$1'0`P8*`?%K:=B:V/'V$"C%+ZE
MW1V$29@EZX+1P*"*_2P\[AOOV!HS,-1^1BKZE8JKX7+FR/J9(9F4A].*5]'&
M;C:<<5-L)9RE75\B"XZ;7SG8E:!KP9TWM$>1ZW`Z?]0S2/@%%FTU,5Q?8`*M
M_"=\BZ3;%)1\2[D-XI;@QPWX9962W.Q>T7V69"%5[W`\%.]9><-#YUR^!I.O
MG)+9S^27MGL[L#0-JW@&U/6#,)A;&1CJ/B,&[CGO/+@?N&<D5ZN\@$]NY<\X
MXL"?K6"ET=`[XCDZ\:E>=\$;PI0>\2LS8X>4R;LEPRI"J:0T)XA8X=TVV73^
M>X$ZA*W\]QY#R`)8XHS%G;154!Z+<<Z9=3XET(C,%X.:_Z(0O>S8C?1!('$U
MD&'WK\CX#1VV6HK'_E5SL]5.'GP)JN)@[0>OBE;`]].*^<B2E-90(G`H!1JW
MQQU")J5L#B;K74)<.M<"\,)JXTHL-@P[&ES#HE!HI$<%\?6:U<+4[;HYWP4A
MT/"<6BO_"V>C0[3GURCT@4ZIL87T]H58#"98RZH<+5X!)CBQ,5<\QPO1E7S9
M^I^NIP143*8+.$GC,O+4G18^!8/N4*$]\3A[@2J;NU22CER$3ZJ4)RQ@JG-R
M_IU@%,P=G*_E+J+51XN/&UOK!)5XN1L$D]%Y3UU[N4=VH!<O#["L(#KCA>>%
MSV\%7.>%L-%0[',%D%]U:*.M"K'ZO_#4^T8J\`$7NX<&[F1TUG%77TPMUL%8
MO+;F$-Q:U/>._]@`9PETR3JGN):0TO1X&SW=D;_.!Y\]&K[O"3WE,<QWTK@F
M.F7]T(KQP./?;:I[L*Q!=.)3[UD%3@@5,[F85J8IQ+0-&[2(OJ$?LV$<E%*=
M-B9=ABY-Q0^BI7=]?$LE\";BRST8(QJ^:?V&Q&E6XLNG4<]'\Z;.OKKA1.<]
M]R]JG1)<)!B6Y]_X"/M;@94$+.>1]AL)ZY0ECDX[Z=WKW4J(N*BN2]\0+;GV
M51=A)24(C>5@8,-*G7;<^')LO%D!KX_M%7>H`:L>5R^O:(Y58-I[K[Z%5F%E
ML\9A7'C`T!>>7X=1*\>E/.!J_")8EB8\,GK]"\^NPJ]>G8`K"W=@[']<#[\<
M@V@!O>Z%,!D5-^I[_;.\P/&%X/E1;7ATVK\NO=#U@S$7=CO"#\%TE]SHV)U/
M\!:)P88`&]$>M#'N<PC^(C^H1?W?'%PQ#ML+%"SLQAI^Q:D?7\EQ\Q+\"BWS
M>G1:\=VR%=>Z2*I((-8R)!T:OS8!'T"1*_05UGK5:.EWUFZD+P]*R5J0C?%X
MU/^=]1O]47`9UGK!Q+A3C7J/*X]4W)W)6G]"C[>*BU'&Y=O7(3M'&)UPV[N7
M^Z,Q[$[8@='P;==>XM:XR'9=$UZI!EMQ\=20O.3&<=<IZ0'7.<$$8<IZ-0K[
M1,/KEXS42H&[@W<K1LI@6#AST;$7'KW2;XZ)(&CB&!WB6K.]/C=O_L#_F_^N
M#W_QN'-1)N=^U/-'?_Z1^0_NO1W,YE=U-:*[,KOO.^7Z@>>.FG<(_`+_L[!8
M+8;%)4/[3G[N1O]\_>N#*_Z8'U;@]R?1[Q?)[P_"W\-O3ZR>]/F-^NJ#<&3X
M[0G\VWW+4K\]_IW?W'@FC;!(_W;IOM>GGJ?&?=VQ/S_Q<GO<T9WPV]?2"(>5
MRZD17O/=GYRWT[ZVT8!KC_4_<]W?ZXG(%ZO!.?M>_9MYBX=35WIPY1%7W'W9
MH?J]8'8"&/3PE8_\K#'O%1?^%?V'?GG6OL-.W?O&!\S]B/->:^Q[^0DG]N]*
MS<$DC'K(H;>,GF__MHK/6KCVF:LF]6]IV*%]!ST6W[)QWD)<!7G5LYZ?-W_9
/!WJ^R__WWV%\J*E\-0$`
`
end
SHAR_EOF
echo 'gunzipping file tds.dvi' &&
gzip -d < _shargzi.tmp > 'tds.dvi' && rm -f _shargzi.tmp &&
$shar_touch -am 1027142695 'tds.dvi' &&
chmod 0666 'tds.dvi' ||
echo 'restore of tds.dvi failed'
shar_count="`wc -c < 'tds.dvi'`"
test 79228 -eq "$shar_count" ||
echo "tds.dvi: original size 79228, current size $shar_count"
fi
exit 0
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 Oct 1995 13:52:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 27 Oct 1995 14:51:10 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510271851.AA06632@terminus.cs.umb.edu>
To: opbibtex@labrea.Stanford.EDU
CC: beebe@science.utah.edu, twg-tds@shsu.edu
Subject: Re: texmf/bibtex substructure
Since I've seen no major objections, I've introduced the usual package
subdirectories into the current tds draft (see next msg. Oren and
Nelson, you can ftp it from ftp.cs.umb.edu:/private/tex/tds if you want).
Meanwhile, some responses to Oren's mail:
(1) The apalike.{bst,doc,sty,tex} files point up some of the difficulties:
apalike.bst---the bibliography style file
apalike.doc---the documentation file for apalike.sty
apalike.sty---apalike.doc with comments removed
apalike.tex---roughly, an apalike.sty equivalent, for use with btxmac
Unfortunately, they will get spread out:
texmf/bibtex/bst/base/apalike.bst
texmf/doc/bibtex/base/apalike.doc
texmf/tex/macros/latex/misc/apalike.sty (else latex/bibtex?)
texmf/tex/macros/plain/misc/apalike.tex (else generic/misc?)
if forced to pick one
place or the other, I'd probably pick bib/base, [for xampl.bib]
OK, that's where I suggested it go in the tds.
sure where, and the person who wrote bibshare should probably add some
That was me, based on conversations with Nelson.
comments saying for whom the advice is intended, and add their name.
I don't think the bibshare document should be distributed in its current
form. Sebastian, can you take care of removing it from CTAN?
Address entries must always include the country
Hmm, I don't remember that part. Maybe someone else changed it.
================================================================================
From owner-twg-tds@shsu.edu Fri, 27 Oct 1995 14:52:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 27 Oct 1995 19:15:45 +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: <951027191545.22c06b27@vms.rhbnc.ac.uk>
Subject: RE: tds 0.102
>> I'd like to include the location of Ulrik's and Phil's email archives,
ftp://vms.rhbnc.ac.uk/archives/
filenames are of the form "twg-tds.MMM-YY", where MMM is month and YY is year.
If the TWG-TDS is unable to reach agreement before Jan 1 2000, I will rename
all files to be of the form "twg-tds.MMM-YYYY" :-)
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Sat, 28 Oct 1995 15:48:00 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sat, 28 Oct 1995 13:47:45 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510282047.NAA18967@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: path-searching again
> This improves the maintainability of the font tree,
> but, unless all the programs that search this tree employ some form of
> caching, there are serious performance concerns. For example, in order
> to find \path|cmr10.tfm|, {\TeX} would potentially have to search
> ^^^
> through all the directories that contain \path|pk| files
> ^^
> in all modes and at all resolutions.
>
> I don't understand this. Is this a mix-up or something?
No, but implementing texmf/fonts/supplier/typeface/type/... would be a mix-up
for the above-mentioned reason. The problem is: how does TeX know that the
dvi file isn't located in some weird place like
texmf/fonts/foo/bar/pk/dpi300/tfm/cmr10.tfm ?
Was this ever fully answered? I am rushing through back mail and
it may be redundant to comment at this time. But---
With a rationally constructed texmf.cnf, or its equivalent
in another environment, a tfm file placed in
texmf/fonts/foo/bar/pk/dpi300/tfm/cmr10.tfm
would simply not be found, and why should it?
I had this experience recently because I had left the latex
files for the TDS in the doc tree, where they could not be
seen. I was annoyed, but not at the failure of TeX to find
files I had effectively hidden from 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 Mon, 30 Oct 1995 18:27:19 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Sun, 29 Oct 1995 18:56:00 -0800 (PST)
Message-ID: <199510300256.SAA22471@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: path-searching again
On Sat Oct 28 13:56:43 1995, mackay@cs.washington.edu (Pierre MacKay) wrote:
> > This improves the maintainability of the font tree,
> > but, unless all the programs that search this tree employ some form of
> > caching, there are serious performance concerns. For example, in order
> > to find \path|cmr10.tfm|, {\TeX} would potentially have to search
> > ^^^
> > through all the directories that contain \path|pk| files
> > ^^
> > in all modes and at all resolutions.
> >
> > I don't understand this. Is this a mix-up or something?
>
> No, but implementing texmf/fonts/supplier/typeface/type/... would be a
> mix-up for the above-mentioned reason. The problem is: how does TeX
> know that the dvi [I meant tfm] file isn't located in some weird place like
>
> texmf/fonts/foo/bar/pk/dpi300/tfm/cmr10.tfm ?
>
>
> Was this ever fully answered?
I believe that I fully answered the first question. I intended the
second question to be rhetorical.
> I am rushing through back mail and
> it may be redundant to comment at this time. But---
>
> With a rationally constructed texmf.cnf, or its equivalent
> in another environment, a tfm file placed in
>
> texmf/fonts/foo/bar/pk/dpi300/tfm/cmr10.tfm
>
> would simply not be found, and why should it?
How would you "rationally" set up a texmf.cnf without creating all the
problems that recursive searches were intended to avoid? The most
straightforward path in texmf.cnf would be
texmf/fonts//tfm
and that most certainly would have to find the above .tfm file.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Mon, 30 Oct 1995 20:01:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 30 Oct 95 09:53:42 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9510300953.AA03912@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: path-searching again
> With a rationally constructed texmf.cnf, or its equivalent
> in another environment, a tfm file placed in
> texmf/fonts/foo/bar/pk/dpi300/tfm/cmr10.tfm
With the adopted fonts/type structure this is true, but with the
originally proposed fonts/supplier structure, and an input path of
texmf/fonts//tfm
then such a file *would* be found by any normal setup. As far as I can
see the only way to stop it being found would be to a) use the !!
technique so that only the database is searched, not the disk, and b)
do not use ls -R at the top level to create the ls-R file, but rather
selectively produce the file by just adding whatever lines you *want*
to be in the database.
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 30 Oct 1995 20:01:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 30 Oct 95 11:14:38 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9510301114.AA04085@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: comments on v0.102
Only really `editorial' comments for Karl this time,
Compliments to Joachim on the class file, looks much nicer than
article class:-) I did wonder whether it would be more consistent to
use sans serif rather than bold in the table of contents lines, and
similarly the title, but I'm ony a TeX hacker: don't take my word on
document design... Anyway I assume the tugboat version will reset
everything in normal tugboat style?
Section 2.4, Page 6
> \item A completely separate tree, following a \abbr{TDS} structure
> itself; for example, \path|/usr/local/oratex| and
> \path|/usr/local/texmf|.
I think the the traditional unix `local' is rather a distraction here,
and may really confuse non-unix readers. Is it clear that
/usr/local/texmf is given as an example of the *non*-local tree...
Also, especially now Norm's O'Reilly address is not on the document
people may be confused as to what `oratex' is supposed to mean.
How about
\item A completely separate tree, following a \abbr{TDS} structure
itself; for example, an installation at O'Reilly and Associates may
install a `local' TDS tree under \path|/opt/oratex| and a `standard'
TDS tree under \path|/opt/texmf|.
> \item their standard location in the main \abbr{TDS} tree (if it can be
> made globally read/write); or
>
> \item ... in their main \abbr{TDS} tree ...
>
> \item or ....
The use of `or' is inconsistant, at the end of the first item, and the
start of all the rest, also `in their' should be `in the' or `in its'
Something like
\begin{itemize-squeeze}
\item their standard location in the main \abbr{TDS} tree (if it can be
made globally read/write);
\item or in an alternative location in the main \abbr{TDS} tree (for
example, under \path|texmf/fonts/tmp|);
\item or in a second complete \abbr{TDS} tree (as outlined above);
\item or in any other convenient directory (perhaps somewhere under
\path|/var|, for example \path|/var/spool/fonts|).
\end{itemize-squeeze}
Section 4 page 14
> . . <package>/ name of a package (e.g., \path|graphics|, \path|nfss|)
. . <package>/ name of a package (e.g., \path|graphics|, \path|psnfss|)
^^
Section B.2 page 17
> Different implementations have elected to use different syntaxes for
syntaxes ? or syntax ? not sure, I'd probably have said syntax.
> \item[\application{em\TeX{}}:]
> \path|t:\directory!!|; \path|t:\directory!| for a single level of searching.
> \item[\application{Kpathsea}:]
> \path|texmf/subdir//|
...
Half the examples here use `subdir' and half use `directory' As I think
the same concept is meant in both cases, probably best to use the same
word for all the \item's perhaps `subdir' as that would fit the dvips
environment variable name.
Section B.3.2 page 18
> (Email \path|tex-k@cs.umb.edu| ....
Useful info but I'm not really sure it belongs here, we don't give
contact addresses for any other implementation.
> See \path|prep.ai.mit.edu:/pub/gnu/standards.*|
Perhaps rephrase that without an explicit filename at that point, and
add prep to the list of reference sites at the end?
Section C.2.3 page 20
> Although we are making an implicit assumption that \MF{} is the only
> program producing mode-dependent bitmaps, if this becomes false we can
> add an abbreviation for the program to mode names, as in \path|mfcx|
> vs.\ \path|xyzcx| for a hypothetical program \application{Xyz}. Or we
> can at that time add an additional program name level uniformly to the
> tree; for our present purposes, it seems more important to concisely
> represent the current situation than to take account of hypothetical
> possibilities that may never be realized.
Seem to have a sentence starting with Or, perhaps:
We are making an implicit assumption that \MF{} is the only
program producing mode-dependent bitmaps. If this becomes false we can
add an abbreviation for the program to mode names, as in \path|mfcx|
vs.\ \path|xyzcx| for a hypothetical program \application{Xyz} or we
can at that time add an additional program name level uniformly to the
tree. For our present purposes, it seems more important to concisely
represent the current situation than to take account of hypothetical
possibilities that may never be realized.
================================================================================
From owner-twg-tds@shsu.edu Mon, 30 Oct 1995 20:15:05 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 30 Oct 1995 17:13:22 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510310113.RAA23217@june.cs.washington.edu>
To: vojta@math.berkeley.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: path-searching again
I'll try it. I'll put a tfm in that position, and my expectation
is that the worst I will get is a single path through pk.
This is assuming, of course that ls-R is properly refreshed, but
with a font repertory of 150 faces or so, I have to assume that.
Any directory hierarchy with a lot of terminal diredtories
will thrash in the absence of an up-to-date
ls-R file.
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 Oct 1995 05:49:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 Oct 95 11:48:17 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9510311148.AA06036@r8h.cs.man.ac.uk>
To: mackay@cs.washington.edu (Pierre MacKay)
CC: TWG-TDS@SHSU.edu
Subject: Re: path-searching again
Pierre> I'll try it. I'll put a tfm in that position, and my
Pierre> expectation is that the worst I will get is a single path
Pierre> through pk.
But that is exactly what was at the crux of the months of discussion
we had over fonts/type vs fonts/source. Although efficiency is an
issue on some systems, Karl pointed out 1000 times that given a decent
caching algorithm there was no real efficiency concern here. My
objection was always that fonts/source did not allow you to *specify*
where TeX or anything else should look for tfm files.
texmf/fonts//tfm still specifies a search over all of texmf/fonts.
Irrespective of efficiency, it seems a natural wish to be able to
specify that the tfm input path should be over directories containing
tfm files, texmf/fonts/tfm// seems to be the only way of doing this
with full recursive directory searching. Otherwise you would have to
need one-level wild cards and make use of the particular arrangement
of the TDS tree, as in
texmf/?/?/tfm
(or however many levels deep it should be:-) Such a method would
again cut out the pk and source directories, but at the price of a
much more rigid structure.
David
Why am I being sucked into another fonts/source discussion!
================================================================================
From owner-twg-tds@shsu.edu Tue, 31 Oct 1995 11:54:26 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 31 Oct 1995 09:22:54 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510311722.JAA15800@june.cs.washington.edu>
To: carlisle@cs.man.ac.uk
CC: TWG-TDS@SHSU.edu
Subject: Re: path-searching again
Let me reassure you, I am slowly working everything into /fonts/tfm
format. There is no resistance there. I don't like it even now, and
for whatever reason, it soaks up more inodes than the other way round.
fonts/tfm has won, but I have yet to detect the slightest improvement
in searching efficiency as a result. If ls-R is not up-to-date, I
get a lot of thrashing, and if it is, I get as near immediate
font selection as I could ask, given the breadth of my font library.
But publicly, the majority has spoken, and I follow the example of
Rene Levesque rather than Jacques Parizeau. I do not intend to drag
us into another root-canal session.
--
%=======================================================================%
| 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, 31 Oct 1995 17:00:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 31 Oct 1995 17:53:59 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199510312253.AA22301@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: path-searching again
Why am I being sucked into another fonts/source discussion!
Exactly :-).
I have yet to hear any convincing technical argument for fonts/filetype.
But it's definitely a moot point. The (other) implementors have
spoken. Let's move on.
From owner-twg-tds@shsu.edu Wed, 01 Nov 1995 15: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: <199511012139.WAA18720@spice.iti.informatik.th-darmstadt.de>
Subject: Re: TWG-TDS e-mail archive
To: TWG-TDS@SHSU.edu
Date: Wed, 1 Nov 1995 22:39:02 +0100 (MEZ)
Content-Type: text
[Trying to catch up with discussion & draft.]
Phil wrote:
>
> At Karl's suggestion I have put up my e-mail archives
> of TWG-TDS correspondence; they can be found at
>
> ftp://vms.rhbnc.ac.uk/archives/twg-tds.<mon>-<yy>
Thanks a lot, that's a good service.
Unfortunately, I can't really utilize it for automatic transferal to
CTAN. (That's what I would like to do.) Anybody keeps such an
archive, too -- on a Unix system, accessible via anonymous ftp?
Or anybody out there with enough energy and time to fix mirror to
handle VMS file systems correctly? 0.5 :-)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Wed, 01 Nov 1995 16:02:17 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511012151.WAA15147@spice.iti.informatik.th-darmstadt.de>
Subject: Opening a can of worms
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Wed, 1 Nov 1995 22:51:52 +0100 (MEZ)
Content-Type: text
Hi, don't throw stones -- but...
Reading the draft after some weeks anew, I realized that the section
on file names is not my image of our discussion. In particular, it
concerns file name length. (Everything below is IMO, but not IMHO.)
As long as one maintains a TeX system that runs on a real operating
system, one must not be hindered to install files with their real
names. I.e., if there is the file cwebparts.sty, one should not
require that this file is stored as cwebpart.sty or under any other
name. It might be necessary, and we must hint to that portability
problem -- especially for those institutions who want to use an
installation on a crippled platform, or want to create a CD-ROM. But
we should not require it.
I'm fine with the requirement for short directory names. (Well, not
fine -- I'm never fine with 8 chars restriction -- but you'll
understand. :)
Hope to get some feedback on this,
Joachim
PS: Shouldn't it read `must not' instead of `may not' in the first
two items in section 2.2.2?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Nov 1995 05:16:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Nov 1995 10:59:08 GMT
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511021059.KAA22498@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Opening a can of worms
References: <199511012151.WAA15147@spice.iti.informatik.th-darmstadt.de>
> As long as one maintains a TeX system that runs on a real operating
> system, one must not be hindered to install files with their real
> names. I.e., if there is the file cwebparts.sty, one should not
i dont agree. i think those of us who use real OSes should conform to
the standards of the handicapped
> require that this file is stored as cwebpart.sty or under any other
> name. It might be necessary, and we must hint to that portability
we should very strongly discourage cwebparts.sty from existing under
that name!
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Nov 1995 06:18:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Nov 1995 07:18:14 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511021218.AA26709@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: karl gone
I'll be away until Tuesday. I plan to release another TDS
draft a couple days after I get back.
Happy reading!
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Nov 1995 07:20:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Nov 1995 14:17:47 +0100
Message-ID: <9511021317.AA03401@macbeth.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: mail archives
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
Since I have been busy with `real work' I haven't caught up yet,
but I've seen some enquiries about mail archives, so I've decided
to bring my archives in shape and make it available.
Since we don't run an anoynmous FTP server here, I can only offer
access via WWW, but that should be better than nothing, I hope.
The address is:
http://www.thphy.uni-duesseldorf.de/~vieth/subjects/tex/projects/tds-mail/
This archive includes the following files:
tds9405.txt.gz ... tds9502.txt.gz (copies from niord.shsu.edu)
tds9503-arch.gz (my best attempt at an archive for March 1995
combined from various downloading attempts
before I got added to the mailing list)
tds9503-mail.gz .. tds9510-mail.gz (my own mail archives)
Due to mail problems I sometimes got duplicates or delayed messages
out of sequence. I'm not completely sure whether I have managed to
sort this out in the archive files in all cases, but that's life!
Cheers,
Ulrik.
P.S. I'm not quite sure about putting this WWW address in the draft
and ultimately having it published in TUGboat. I'm afraid that
our server administrator might not like it.
================================================================================
From owner-twg-tds@shsu.edu Thu, 02 Nov 1995 17:19: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: <199511022314.AAA20916@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Opening a can of worms
To: TWG-TDS@SHSU.edu
Date: Fri, 3 Nov 1995 00:14:08 +0100 (MEZ)
Content-Type: text
sebastian wrote:
>
> > As long as one maintains a TeX system that runs on a real operating
> > system, one must not be hindered to install files with their real
> > names. I.e., if there is the file cwebparts.sty, one should not
> i dont agree. i think those of us who use real OSes should conform to
> the standards of the handicapped
And what do you do with documents that say
\usepackage{fancyheadings}
? Ignore the error message that a file fancyheadings.sty could not be
found, since it's called fancyhea.sty on your TDS-compliant
installation?
> > require that this file is stored as cwebpart.sty or under any other
> > name. It might be necessary, and we must hint to that portability
> we should very strongly discourage cwebparts.sty from existing under
> that name!
Will you discard all macro files that don't conform to 8.3 from CTAN?
(Some of them might have been written by 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 Thu, 02 Nov 1995 23:20:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Nov 1995 23:24:08 -0500
From: Paul Abrahams <abrahams@equinox.shaysnet.com>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511030424.XAA28295@equinox.shaysnet.com>
To: twg-tds@shsu.edu
Subject: TWG-TDS 0.101: the texmf root
I'm concerned that the treatment of the texmf root as given in the TDS
conflicts with the Linux Filesystem Standard. In that standard, the
files belonging to texmf appear in two places in the directory tree, one
for read-only data and one for modifiable data. I certainly don't
suggest that the TDS provide for precisely that possibility, but the
treatment of texmf should be generalized so that the Linux arrangement
is valid.
I'd suggest that the material on page 6 might be something like this:
The roots of the TDS should be a set of one or more directories
containing only TeX-related materials. We recommend that each such
directory have the filename "texmf" if possible.
If there is more than one texmf directory, the directories should be
treated for search purposes as though they were logically merged. That
is to say, a search through all the texmf directories should yield the
same result as if their contents were all stored in a single texmf
directory.
Paul Abrahams
Reply-To: abrahams@acm.org
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Nov 1995 03:08:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Nov 1995 10:07:04 +0100
Message-ID: <9511030907.AA04003@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: Opening a can of worms
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
Joachim wrote:
> And what do you do with documents that say
>
> \usepackage{fancyheadings}
What about: wait until Piet van Oostrum has finished his promised update
and then say
\usepackage{fancyhdr} % read: fancyheader shortened to 8 characters
(He mentioned this during the LaTeX tutorial at EuroTeX'95.)
All this 8+3 discussion reminds me of the late stages of LaTeX 2.09
where internal documentstyle option such as \ds@titlepage had to be
introduced to load external files with 8+3 names such as titlepag.tex.
Please don't start this mess again. Simply stick to 8+3 characters
whereever possible and be portable.
Cheers, Ulrik.
(who hates having to rename his Unix files when transferring them
via DOS floppies)
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Nov 1995 03:22:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Nov 1995 09:18:31 GMT
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511030918.JAA24030@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Opening a can of worms
References: <199511022314.AAA20916@spock.iti.informatik.th-darmstadt.de>
> And what do you do with documents that say
>
> \usepackage{fancyheadings}
>
> ? Ignore the error message that a file fancyheadings.sty could not be
> found, since it's called fancyhea.sty on your TDS-compliant
> installation?
i mail Piet and say he must change his name *soon*. i dont believe
example liks this are that common
> Will you discard all macro files that don't conform to 8.3 from CTAN?
yes, i might well consider weeding them out, and moving them to a
special area marked as "non-TDS-compliant, you might have problems"
> (Some of them might have been written by me. :-)
gasp
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Nov 1995 04:05:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Nov 95 10:01:19 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9511031001.AA15355@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Opening a can of worms
J> Will you discard all macro files that don't conform to 8.3 from CTAN?
S> yes, i might well consider weeding them out, and moving them to a
S> special area marked as "non-TDS-compliant, you might have problems"
Hmm you might have to weed out some of the standard LaTeX tools
packages as well. Which probably means weeding out all of them as they
are supposed to be distributed together.
The TDS document already explicitly suggests that some sites may want
to stay with long pk font names, as long as the implementation
supports both long and short forms, and I think that that is the best
that can be done in this area.
When we started packaging up the old LaTeX2.09 styles for the first
LaTeX2e release, I considered renaming all the styles to 8+3 names. In
fact I did do this, and changed all the internal documentation and
cross references to match. However in the end we decided that of two
bad possiblities, this was the worse, and so reverted the changes.
Essentially the problem is that distributing the thing under two names
is just too error prone, and changing the name breaks all existing
documents, and makes all the published documentation wrong. So just
decided to live with the names we've got but use 8+3 for any new
packages.
As far as I know all PC TeX's will map fancyheadings.sty (or
longtable.sty) down to some 8+3 name or other and so the long name
does not cause a problem for portable documents. It does make moving
the style file from a 8+3 system to a longname system slightly harder
but... Conversely if you change the name of a package you break many
documents. As presumably there are many more documents than there are
these troublesome packages this seemed to be a much worse alternative.
David
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Nov 1995 06:51:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Nov 1995 12:20:23 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: <951103122023.236058d5@vms.rhbnc.ac.uk>
Subject: 8+3
One of the major problems with long filename references on 8+3 systems
is that there are at least three different algorithms for mapping from
>8.>3 to 8+3: the simplest just truncates after the first 8 and the
first 3; the second takes the first five and the last three of the
pre-period part (I don't know what it does with the post period part);
unfortunately PC-NFS does neither of these, and generates a temporary
unique name of the form <first-5>^xy, where "xy" are hex digits. Thus
any dcoument which references a filename longer than 8+3 is inherently
unportable :-( ** Phil.
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Nov 1995 09:19:28 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511031518.QAA30611@spelunke.iti.informatik.th-darmstadt.de>
Subject: Re: Opening a can of worms
To: TWG-TDS@SHSU.edu
Date: Fri, 3 Nov 1995 16:18:00 +0100 (MEZ)
Content-Type: text
Ulrik wrote:
>
> > And what do you do with documents that say
> >
> > \usepackage{fancyheadings}
>
> What about: wait until Piet van Oostrum has finished his promised update
> and then say
>
> \usepackage{fancyhdr} % read: fancyheader shortened to 8 characters
Sorry, but that is not an option. (1) fancyhdr is an other package
than fancyheadings. (2) It would mean that I have to change legacy
documents which exist in the thousands. My users would grill me (and
they would be completely right with that wish).
> Please don't start this mess again. Simply stick to 8+3 characters
> whereever possible and be portable.
Tell that wish the developers. We are *NOT* the developer's community
here, and we must not make such requirements. TDS is concerned with
installation of _existing_ packages, not of some nebulous amount of
new ones. We don't plan a new TeX system, we should concentrate on a
structure that can be employed by existing systems _now_.
Cheers,
Joachim
PS:
> Cheers, Ulrik.
>
> (who hates having to rename his Unix files when transferring them
> via DOS floppies)
I would recommend zip or tar. :-) It has other advantages in addition.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Fri, 03 Nov 1995 09:22: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: <199511031522.QAA30663@spelunke.iti.informatik.th-darmstadt.de>
Subject: Re: Opening a can of worms
To: TWG-TDS@SHSU.edu
Date: Fri, 3 Nov 1995 16:22:04 +0100 (MEZ)
Content-Type: text
sebastian wrote:
>
> > And what do you do with documents that say
> >
> > \usepackage{fancyheadings}
> i mail Piet and say he must change his name *soon*.
Sorry, but that's not relevant, IMO. There are old documents that
cannot be changed.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 06 Nov 1995 03:46:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 6 Nov 1995 10:44:02 +0100
Message-ID: <9511060944.AA05527@macbeth.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: minor editorial comments
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
I've had another reading of 0.102 this weekend (after having skipped
0.101 due to workload). Today, there are really only minor comments.
\item \path|generic|, for input files that are useful across a wide
range of formats. Generally, this means any format that uses the
category codes of Plain \TeX{} and does not rely on any particular
format (e.g., \path|null.tex|, \path|paths.sty|). This is in contrast
^^^^^^^^^^^^^^^
This should be \path|path.sty| without s. (I wonder how long this error
has been around without anyone noticing.)
\item \path|public|, for freely redistributable fonts where the supplier
neither (1)~requested their own directory (as with, e.g., \path|ams|),
nor (2)~made a great number of fonts (e.g., \path|adobe|). It does not
contain all freely distributable fonts, nor are all files therein
legally public domain.
I liked the previous wording better. This almost sounds as if none of
the files in public were legally public domain. I think it shold be
made clearer that they are _not necessarily_ public domain, but they
may well be in some cases.
Two naming strategies are commonly used to identify the resolution of
bitmap font files. On systems that allow long filenames (and in the
original \MF{} program itself), the the resolution is included in the
^^^^^^^
Anyone knows a good spell checker which would catch somthing like that?
\item[\replaceable{mode}] is a name which identifies the device type
(examples: \path|cx|, \path|gsftopk|, \path|ljfour|). Usually, this is
the name of the \MF{} mode used to build the \path|PK| file.
It might not be a good idea to use |gsftopk| as an example for mode
before it is explained (in the next paragraph) that program names
are used as such. Simply |cx| and |ljfour| should be enough here.
\item \path|base|, for the standard additional \MF{} macro files as
^^^^^^^^^^^^^^^^^^^
described in \citetitle{The \MF{}book}, such as \path|plain.mf| and
\path|expr.mf|.
``standard addtional'' may sound like a contradiction since ``additional''
might imply ``non-standard''. I suggest dropping ``additional'' here.
\path|texmf/bibtex/bib/|\replaceable{package}\path|/|
\path|texmf/bibtex/bst/|\replaceable{package}\path|/|
There should be a line break between these two items.
The \abbr{TDS} specifies that these additional documentation files shall
be stored in a structure that parallels to some extent the
\path|fonts| and \path|macros| directories, as follows:
^^^^^^^^^^^^^
What \path|macros| directory? We don't have one anymore for quite a
long time now. Should that be simply ``and \TeX{} macros directories''
(without using \path)?
(the summary figure)
mft/ \application{MFT} inputs (e.g., \path|plain.mft|)
^^^^^^^^^^^^^^^^^
I think the traditional way for denoting MFT is uppercase typewriter type
just like INITEX, etc. (see mft.web). Of course, that would be inconsistent
with other instances of applications, but well, that's the tradition.
tex/ \TeX{} input files
. <format>/ name of a format (e.g., \path|plain|)
. . base/ base distribution for format (e.g., \path|plain.tex|)
. . misc/ single-file packages (e.g., \path|webmac.tex|)
^^^^^^^^^^^^^^^^
Might there be a better example for tex/<format>/misc? I would have
put webmac.tex into tex/plain/base, since it's distributed together
with Plain in Knuth's tex95.tar.gz/dist/lib.
. . <package>/ name of a package (e.g., \path|graphics|, \path|nfss|)
^^^^^^^^^^^
What |nfss| package? |psnfss| or |mfnfss| might be a good examples,
but simply |nfss| doesn't exist.
(the doc figure)
<format>/ name of a format
. base/ for the base format
. misc/ for single-file package documentation
. <package>/ for \emphasis{package} (\path|amslatex|, etc.)
^^^^^^^^^^^^^^^
This is a bad example since |amslatex| is special case which goes
under |ams| as shown a few lines above in the figure. In principle,
there should be plenty of packages to choose for an example here,
however, since |latex| is listed explicitely further down, this
should better be a non-LaTeX package example.
(web2c-7.0 structure)
\begin{description}
\item{executables in} \replaceable{prefix}\path|/bin|
\item{man pages in} \replaceable{prefix}\path|/man|
\item{info files in} \replaceable{prefix}\path|/info|
\item{\path|libkpathsea.*| in} \replaceable{prefix}\path|/lib|
\item{\abbr{TDS} root is} \replaceable{prefix}\path|/share/texmf|
\end{description}
Wouldn't it be clearer to transform this into a tdsSummary envrionment:
<prefix>/ installation root (e.g. \path|/usr/local|)
. bin/ executables
. man/ man pages
. info/ info files
. lib/ libraries (\path|libkpathsea.*|)
. share/
. . texmf/ TDS root
This improves the maintainability of the font tree, since all files
comprising a given typeface are in one place, but unless all the
programs that search this tree employ some form of caching, there are
serious performance concerns. For example, in order to find a
\path|TFM| file, the simplest implementation would require \TeX{} to
^^^^^^^^^
lowercasifiy |TFM| for consistency, after you've already done this to |pk|
That's it for today. We're getting closer, it appears.
Cheers, Ulrik.
P.S. Why does it always take so long to write up this feedback after
marking it on paper?
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 Nov 1995 11:51:11 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Tue, 7 Nov 1995 09:51:00 -0800 (PST)
Message-ID: <199511071751.JAA03895@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: clarification
The current draft says:
If documents could portably specify recursive searching directly in
filenames, restrictions on uniqueness of filenames could be relaxed
considerably ...
This makes it sound like one wants to turn the recursive searching on or off.
I think it would be clearer to write:
If documents could restrict subdirectory searching to a subdirectory
via some portable syntax in file names, then restrictions on uniqueness
of filenames could be relaxed considerably ...
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Nov 1995 04:03:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Nov 1995 09:58:51 GMT
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511080958.JAA26847@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Opening a can of worms
References: <199511031522.QAA30663@spelunke.iti.informatik.th-darmstadt.de>
> > > \usepackage{fancyheadings}
> > i mail Piet and say he must change his name *soon*.
>
> Sorry, but that's not relevant, IMO. There are old documents that
> cannot be changed.
i distinguish between a normal running system, with TDS, and a special
system to deal with legacy documents, which would access a tree of
links.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 Nov 1995 16:47:04 CDT
Sender: owner-twg-tds@SHSU.edu
X-MX-Warning: Warning -- Invalid "From" header.
From: Martin Hagstr\vm <martinh@math.kth.se>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9511082247.AA13973@newton.math.kth.se>
Subject: What is the thought behind texmf/web2c/xxxx.fmt?
To: twg-tds@shsu.edu
Date: Wed, 8 Nov 1995 23:47:00 +0100 (MET)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Busy installing teTeX while looking at another installation at the
department above I like to know way there is no specific directory to
place the actual formats files in. My collegue at computerscience put
them into a texmf/ini but in the teTeX distribution they stay in the
web2c directory. Wouldn't it be more logic with ini, or formats or..?
Happy for an answer,
Sincerely,
Martin Hagstrom
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Nov 1995 03:01:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Nov 1995 09:54:11 +0100
Message-ID: <9511090854.AA11718@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: martinh@math.kth.se
Subject: Re: What is the thought behind texmf/web2c/xxxx.fmt?
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
Martin Hagstr\vm writes:
> Busy installing teTeX while looking at another installation at the
> department above I like to know way there is no specific directory to
> place the actual formats files in. My collegue at computerscience put
> them into a texmf/ini but in the teTeX distribution they stay in the
> web2c directory. Wouldn't it be more logic with ini, or formats or..?
Hmmm, maybe we need a TDS FAQ, but AFAIK this will be explained better
in the next version. To answer your question: The TDS tree is basically
intended for implementation-independent files. Format files, however,
are are not implementation-independent unlike .tex or .mf sources, etc.
They cannot be shared between say emTeX or teTeX whereas other files
can; in fact, they cannont even be shared between different versions
of big and small emTeX, but that's a different problem.
For this reason, format files fall under the case ``implementations
may choose to store other files in the TDS tree in an implementation-
specific subtree'', which means somewhere below "web2c" or "vms_tex"
or whatever else. "texmf/ini" is just an old convention that will
be discontinued.
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Nov 1995 17:05:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Nov 1995 18:05:35 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511092305.AA01832@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: comments on v0.102
> (Email \path|tex-k@cs.umb.edu| ....
Useful info but I'm not really sure it belongs here, we don't give
contact addresses for any other implementation.
If Christian would like to give a contact address, I'll include it.
I think it's useful to give an address, especially since we're making a
point of saying this information may be out-of-date, etc.
Can we get Eberhard, Berthold, whoever else to supply similar appendices?
Perhaps I should write to tex-implementors.
Does anyone else on this list now maintain an implementation that should
get its own appendix section?
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Nov 1995 17:06:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Nov 1995 18:05:35 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511092305.AA01840@terminus.cs.umb.edu>
To: abrahams@equinox.shaysnet.com
CC: twg-tds@shsu.edu
Subject: Re: TWG-TDS 0.101: the texmf root
If there is more than one texmf directory, the directories should be
treated for search purposes as though they were logically merged. That
We can't require this in the TDS. Being able to search one tree is hard
enough; logically merging trees is something beyond all current (and
future, as far as I know) implementations. It may make sense, but it's
not practical.
Compatibility with LFSS is achieved simply by putting the writable
directories in /var and using a symlink. Or perhaps the whole tree
should be in /var, but that's not up to us.
I've talked with Daniel Quinlan about this (thanks for pointing out the
LFSS stuff and his address to me, Paul), and I think we're all on the
same wavelength. The next LFSS draft may clarify this a bit from their
point of view.
The current draft talks about read-only vs. writable directories at more
length than the public draft. I'll add some more explicit discussion of
this proposal.
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Nov 1995 17:06:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Nov 1995 18:06:26 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511092306.AA02046@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: clarification
This makes it sound like one wants to turn the recursive searching on or off.
I think it would be clearer to write:
Thanks, Paul. I put in your text.
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Nov 1995 17:06:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Nov 1995 18:06:30 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511092306.AA02074@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: minor editorial comments
It might not be a good idea to use |gsftopk| as an example for mode
before it is explained (in the next paragraph) that program names
are used as such. Simply |cx| and |ljfour| should be enough here.
I disagree. I intentionally added |gsftopk| to point out that it was not
just device names, putting people on their guard that all may not be
what they think.
I think the traditional way for denoting MFT is uppercase typewriter type
just like INITEX, etc. (see mft.web). Of course, that would be inconsistent
INITEX isn't an application that users run in the same sense as MFT, so
the inconsistency seems less glaring there.
No one uses italics to refer to program names, anyway. I never liked
that. Would anyone mind if we just drop the typographic distinction and
used roman?
Might there be a better example for tex/<format>/misc? I would have
put webmac.tex into tex/plain/base, since it's distributed together
with Plain in Knuth's tex95.tar.gz/dist/lib.
I was under the impression that the base/ directory was for those files
which were part of the basic format. webmac.tex has nothing to do with
the Plain format.
Other things in dist/lib don't go in tex/plain/base, either -- null.tex
(surely the prototypical generic/misc file?), story.tex,
testfont.tex. Or do you want to argue that all those things should go in
tex/plain/base, and waits.mf, manfnt.mf, io.mf, expr.mf, [rz]test.mf,
etc., go in mf/plain/base as well?
P.S. Why does it always take so long to write up this feedback after
marking it on paper?
I too found that really annoying (when sending feedback to Norm).
One reason I was happy to take over editorial chores :-).
Maybe I should find some fax software (anyone of any?) and you could fax
your pages to me ... though that might cost $.
P.S. I'm not quite sure about putting this WWW address in the draft
and ultimately having it published in TUGboat. I'm afraid that
our server administrator might not like it.
I've left it out. Let me know if I can put it in.
Also, you need a link for the presumably-extant tds9511 file.
Thanks for all the other comments, I applied them.
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Nov 1995 17:06:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Nov 1995 18:06:27 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511092306.AA02054@terminus.cs.umb.edu>
To: twg-tds-request@shsu.edu, bed_gdg@shsu.edu, norm@ora.com, postmaster@shsu.edu
CC: twg-tds@shsu.edu
Subject: tds (un)subscription, archives
Help.
Is anyone still maintaining the TDS mailing list at shsu.edu?
If so, there are two problems:
1) the anonymous ftp archives on shsu.edu in [twg-tds] are
read-protected starting last month, i.e., the twg-tds.95-10 and
.95-11 files.
2) I'd like to have twg-tds-archive@cs.umb.edu subscribed.
If no one is listening any longer, I'd like to move the list to my host.
Date: Tue, 10 May 1994 08:30:48 CST
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
In a following post to Norm, I will provide instructions for
maintenance.
Unfortunately this was never posted to the list (that I can see).
This list represents the TWG and hence is not open to world
subscription; it will require explicit addition by either Norm or me.
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Nov 1995 17:06:46 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Nov 1995 18:06:31 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511092306.AA02083@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: Opening a can of worms
PS: Shouldn't it read `must not' instead of `may not' in the first
two items in section 2.2.2?
The two items in question are:
{\abbr{ISO}-9660} imposes the following limitations:
\item File and directory names, not including any directory path or
extension part, may not exceed eight characters.
\item Filenames may have a single extension. Extensions may not exceed
three characters. Directory names may not have an extension.
In this case, I find `may not' preferable to `must not' or `shall not'
for some reason. I know it's ambiguous, though. I'll change it if others
prefer, I don't feel that strongly.
================================================================================
From owner-twg-tds@shsu.edu Thu, 09 Nov 1995 17:06:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 9 Nov 1995 18:06:29 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511092306.AA02066@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: minor editorial comments
[the the]
Anyone knows a good spell checker which would catch somthing like that?
Nelson Beebe just mentioned his dw (doubled-word) program in another context:
Date: Wed, 1 Nov 1995 15:33:33 -0700 (MST)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: mackay@cs.washington.edu
Cc: beebe@math.utah.edu, Sebastian Rahtz <s.rahtz@elsevier.co.uk>,
karl@cs.umb.edu, m.GOOSSENS@cern.ch, monohon@tug.org,
norm@jasper.ora.com, schrod@iti.informatik.th-darmstadt.de
Subject: Re: goodies for TUG Unix CD
Sebastian Rahtz writes:
>> dt2dv dv2dt lacheck ps2pk t1ascii t1binary unpost
>> which i'd hate to be without on a daily basis.
To those, I would add my own
dw
chkdelim
The first checks for doubled words (which it found in both the TeX and
LaTeX books before anyone else uncovered them), and the second checks
for delimiter balance problems (braces, brackets, parens, dollar
signs).
The first is available from ftp.math.utah.edu:/pub/misc/dw.shar; I've
not packaged chkdelim yet for distribution, but could easily do so if
you'd like to try it out. It is a member of a suite of utilities that
I wrote to demonstrate the use of UNIX lex/GNU flex in a course that I
taught. I've found chkdelim enormously useful for C, C++, awk,
BibTeX, TeX, ...
========================================================================
Nelson H. F. Beebe Tel: +1 801 581 5254
Center for Scientific Computing FAX: +1 801 581 4148
Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu
University of Utah URL: http://www.math.utah.edu/~beebe
Salt Lake City, UT 84112, USA
========================================================================
Date: Wed, 1 Nov 1995 19:29:31 -0700 (MST)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: mackay@cs.washington.edu, s.rahtz@elsevier.co.uk, karl@cs.umb.edu,
m.GOOSSENS@cern.ch, monohon@tug.org, norm@jasper.ora.com,
schrod@iti.informatik.th-darmstadt.de
Cc: beebe@math.utah.edu
Subject: chkdelim, dw, et al
At Karl Berry's request, I've put together a distribution containing
chkdelim, dw, and some other programs. These all hang together in the
sense of having been presented that way in a course that I teach, and
can be built from a single top-level make. You can find them on
ftp://ftp.math.utah.edu/pub/misc/lex-tools.{trz,tar-lst}. (.trz == .tar.Z).
I've supplied full source code for bootstrapping on non-UNIX systems, and
both raw and PostScript versions of UNIX manual pages for them. I've written
a new top-level README file that describes the collection in more detail,
and suggests what you might want to use it for.
Most of my Makefiles for TeX documents contain steps to run spell, ispell,
and dw, and I routinely use lacheck, chkdelim, and tex-pretty (ask about
the latter if you are interested -- it is not in the ftp tree yet) on
source code for finding problems, and cleaning up the appearance.
Karl has an excellent idea for a extension of chkdelim: checking for
balanced quotes, both in the TeX sense, and in the UNIX shell sense.
For now, it is left as an exercise for the reader, but maybe I'll
get time to do it myself one day. In the meantime, enjoy....
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Nov 1995 03:48:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Nov 1995 10:46:11 +0100
Message-ID: <9511100946.AA13037@macbeth.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: texmf/web2c for formats (missing in 0.102 appendix)
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
Following the question about format files I answered yesterday,
I realized that the appendix about web2c-7.0 doesn't mention
where it puts the format files. It just mentions |/share/texmf|
as the TDS root, but not |/share/texmf/web2c| below it. I think
this really *needs* to be added to avoid more future questions.
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Nov 1995 04:15:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Nov 1995 10:43:13 +0100
Message-ID: <9511100943.AA13034@macbeth.uni-duesseldorf.de>
To: twg-tds-request@shsu.edu, bed_gdg@shsu.edu, norm@ora.com, postmaster@shsu.edu, twg-tds@shsu.edu
Subject: Re: tds (un)subscription, archives
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
Karl Berry (kb@cs.umb.edu) wrote:
> 2) I'd like to have twg-tds-archive@cs.umb.edu subscribed.
While we are at it, I'd like to have my subscribtion address changed
from
vieth@xerxes.thphy.uni-duesseldorf.de
to
vieth@thphy.uni-duesseldorf.de
We are expecting to get a new server machine soon and the explicit
address to the old machine might not work much longer.
Thanks,
Ulrik Vieth.
================================================================================
From owner-twg-tds@shsu.edu Fri, 10 Nov 1995 08:39:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 10 Nov 1995 14:33:04 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: <951110143304.25a00900@vms.rhbnc.ac.uk>
Subject: Re: Opening a can of worms
> The two items in question are:
> {\abbr{ISO}-9660} imposes the following limitations:
> \item File and directory names, not including any directory path or
> extension part, may not exceed eight characters.
> \item Filenames may have a single extension. Extensions may not exceed
> three characters. Directory names may not have an extension.
> In this case, I find `may not' preferable to `must not' or `shall not'
> for some reason. I know it's ambiguous, though. I'll change it if others
> prefer, I don't feel that strongly.
I would support the use of `may not', since it carries with it the
added value `in a conformant implementation' implicitly. ** Phil.
================================================================================
From owner-twg-tds@shsu.edu Sat, 11 Nov 1995 12:11:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 11 Nov 1995 13:11:14 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511111811.AA28886@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: hypertext specials
Should we put hypertext specials into tds.dvi?
Is there any downside?
Unrelated query: Does anyone have a real reference to ISO 9660 we can
include? Are there other references we should include?
================================================================================
From owner-twg-tds@shsu.edu Sat, 11 Nov 1995 12:11:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 11 Nov 1995 13:11:15 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511111811.AA28894@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
CC: abrahams@acm.org
Subject: tds version 0.103 available
I've put tds version 0.103 on ftp.cs.umb.edu:/private/tex/tds.tar.gz, etc.
DVI file below.
The most significant change is that I moved all the ISO-9660 filename
stuff to an appendix, since it's clear we can't require it in TDS trees;
all the names we specify are ISO-9660 compatible, but we can't change
fancyheadings.sty etc.
Here are my thoughts on a schedule:
11nov (sat) -- today
15nov (wed) -- tds 0.104 released as a public draft to the net
17nov (fri) -- draft sent to TUGboat incorporating any quickly found changes,
else will simply be 0.104.
Sebastian (or someone), I hope you can get the draft on to CTAN quickly.
I don't know how to make that happen. I will just put it on my machine
and announce that location.
barbara, is this ok for TUGboat? Can you pass this on to whoever will be
working on this issue? As far as formatting, I think it would be pretty
painful to put in the usual double-column format because of all the long
filenames, but that's up to you folks, of course. I hope the source will
be amenable to whatever you want to do with it.
karl
#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.1).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1995-11-11 11:54 EST by <karl@fosse>.
# Source directory was `/u/w/tds'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode name
# ------ ---------- ------------------------------------------
# 77708 -rw-rw-rw- tds.dvi
#
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
shar_touch=touch
else
shar_touch=:
echo
echo 'WARNING: not restoring timestamps. Consider getting and'
echo "installing GNU \`touch', distributed in GNU File Utilities..."
echo
fi
rm -f 1231235999 $$.touch
#
# ============= tds.dvi ==============
if test -f 'tds.dvi' && test X"$1" != X"-c"; then
echo 'x - skipping tds.dvi (file already exists)'
else
echo 'x - extracting tds.dvi (gzipped)'
sed 's/^X//' << 'SHAR_EOF' | uudecode &&
begin 600 _shargzi.tmp
M'XL(`.#4I#`"`^Q<#7`<Y7D^WYUM8FSC`&'"CP&+:2W#2>@D&RR;DL@R-AHL
MVU@GV0W.#*O;[^X6[^T>^^U*.EKJH:69\*-#RX=O-A9$9N(`YJ_E:%.'WU`L
MF_^F=*`_F6G<PB1@IM,ARK0.Q:CO^WZ[=WN2F)(V$)CJ!@_2[>[WO>_[O/_[
M?OK/Z)P_N?-'YZR-P"?VSMGGI]B.\TW'+CCV^<GV]E7-R23\MR:97-5Z&]PQ
M)_()/I/PV1<M1B+#^TY\+Q+9%_T:_OC1XDATV#6N?G#BE/5_]V]VY,L;'Z5_
M<]-Y*WGI$QWEN9?:ZS6+I6W3*HH>VW+2MF,QD3$MD1IV3USSG;'8P:8K2NZ\
MM=D=8H.F,UX:.P-6OC/RU--NG_O1]_N8Q373<&&AEN9D2UMI;-GF]F'\N.M:
M'IM8LN.AJT^.+`0"\1]MV_IDJG=C.7;L@>WNY-P^T]JE&5FQT3*=@C`-H>"^
M'RUPQZ)[>F'?N+MLAYB)PL;4]I&'K8U-J?4]*TKX&3O[S>>!K!^^]ZO-YIZ'
MK0'!\J)_I*?$+-PKF4P(%"W<%IE#U)UV8LG$X@N/_MZ3D05`&?Z;EU>,C&'_
M<#>LYB:.WC=QYHG(\C6UR^F\K25;#J5R&B_'Q,\U#L2JUNCDC<N5C"UXP6->
M6EN8]A0;!-)<V@\<#^,ZH0=,0R_24ZY\JKET8,GFU</N5X_NGYA_U?O7%JN[
MD:A:*O+9:\[BA;T;ES)<GE87>67DX%M%T>\Q8;$,LRRF"ML4"A=VCHF=$V>9
M?W';D<B78"'\%X?%VL=3V_<^TTX2<V-G'2"T*@T"D-X)ESRZ4&EP8]><B>CS
MG&G9"3>V\S;XY3J'VZ5[B4RX%V\KQWI[!W/,H.W2IK'WX%LV&[*!KET>XT*S
M15IGBB4&<UK:RQ&FO9>/19>?`YC&WAK:(=0JIKR**0@HSQ3#`['<1YMUFH4]
MP*:E97/")M3FG6-]M_+W:4`(?@$:)A8M:TCL#6/$B\F6@XL0PB4//E0!S%<F
MD-CV5:`-*#(D>#HYO1ST6&IAL/E6X(E9>8VC?I=CZGJ0K\,9K):+I,V"5W0G
M+WPP(11#Q8NJ!GQH_8[-8`=@1#5'-BY-.WD&[)`Y`5]%47"L`GQO<B8.#6IV
M#HS>C=V[/V^601]40%<0O&Z\\?X*+.S+W+^S'',>S#`24XY9K'\OLI.U4&!,
M!:AN?+9@F=Z`IJ(NY!1;$F*8MI9F0BG@Q@`)@`-6INN`6D%CO-F-OS[>9>.B
MM:=W*MS?6N,2:DF!8$,%BW$.MP!'6KZ@:_#C(&"D6$"'L`4)I2I!4`'.\'G.
M#%5<[S".W'%\F#O9;/"KY(3E%4U')9XX^Z?'+ANJLSL[V7+8'LPVV2K_.L]Q
MIYFICJC`,OTH5)*HK>C"7\&G_2K%TG'S=6`>17&Q2+:M$IU,JJHEKM1`!MM,
M184K6_5B'MC+)41WAVAI;;ND!;[L[>EH%MN1'R8&/::GS3SS!9<G6'G`IS32
MWMX:YK@'BE3Q!MS)ZX\`64J_SLB_H1J,=Z;<R34/=6P6E1Q0+AH[)#J&J@V)
M]2*GH&N!;0HZLWT#9T::K6@&-W<N>=]WKMV?+)5NQ_`0C7RRSX6A\("V-/9A
M1H7_W1GYP=?OJ:@6>"/D`:Q;#(R@YJ/:"^G3P9B`S;%X)'I+))+)S-D?B:#+
M]8/,B;?1T:$+6_K'KVV[)+(XDR%OC\;(DZTO=)J&S0R;EPZ<>?.N87GGN6?]
MHJ$O#''_4++EQ63)77[T^UW&R*/MMF6.7'U$!<\`9`S?.6?+/WP`=.P_Y>;K
M8`6XJ0(ALN1>?O1`*D<:9IDHWPR9-[HH=UYE!]P9W?UA!:16GG_D*_(W^$7,
M_O0;^FG8/;7OQP#+O1*39',K00*`@TN`"`P>`0W<G?-^?_6962@^9^#=)TWR
MQ58ROHW,8):B@\5EGWMS917:2JMO;CU./WBJ:O1VR;DK5AI<1@X2.3?:\!^S
M4']J<-4`:?5M;1O&'`CQ1A:]('H_VV+,G3?\U"P,GP.0V@BD3908*#I:BZ*J
MFO2*L6>_/8O1;QVM52&T5A):ZQW(:Z'.8@C70IT92IYQ-W+\F[-H?=;(!+&I
MC6(3),T+'C(+33H;@`R1@3F]D0HB$90R$+-6G'+DDEK,:O-C5K>2MDQ`\%M_
M.XO@%U`/+JTBVN8'O0U8E9D&Y!PV'[DN.XOJ%QK?U2%\9;S<;!I-&8DO-7G.
M.WZ7>7FM6M3-K)EL>:G[BM3(D7,Z-HR4VK=L3KFQTNH*>&N(JY/Y68WXOR.S
MJ.]ODBTA:&1P#*2^=>3ZPUMZ0.K#[\Z6V5\`]%81>NO<R=T?3<S[1[%O6V0^
MF-)\OSE\Z6-=<*FMM3*M,^K.^_G:66OZXF">#&%^B4QGJUU)]*>ROQQ[];E9
M4#\78`49[DK*<'N<?%ZQBI#)_G[C\61K+95=Z:>R,X!)=3_4_(++A]UH]Q_-
M@OOK@Q%JA740&+T&+XQ<?03?NC$5:XV"QM)49C2]]-5DK>U9Z?#!V0J8F):-
MK?ZZTG'N^QVS@'RV8*ZL@;E.OE3`EREH-H^V!S[PC93&N4.`GGE/;S+4[%SG
M`]JAFH7`Q,+O%J*E\=FDYS/!L=:=6>?7?MVF12]\3`,<7ETO6M0WHO_UM5FC
M^]^(699@5PPI:#$H:2TPG2#B-'%Z6XG3"-1MAI+KP`O_GX4MA7A)S>=T2I_#
MR^!D;'Q9+Q31C['$QE?/@WL>;5=$\6OH>/[IAF2MOU'I#'>LZ-U*,!PQ,F3.
MJO-O'^-:KZ)S>B^J'K"=<V<!^[Q"U_;QE5$(0G?^78_,8OB;D7Y[S3FN)^>X
MC>F*+?/JZH`+IF*)9P^WME1OOH+N[33E2`C.5YD6WG7EXYOP+CD.0Q^:B:FT
MEN2')F-BGVPP9E[7ISH90WR\`'Z]>=X'70;.M:B=_EQ+:>R,)WKH^O3&2SG6
M-T(CACCY9^XY^-:@8%;&T1-NK.^GB]B01E5&WX@MB@6/<8@L]`ZX;X07N<WR
M.*JF5D?>3(<KALIQ0`9N-B&>"\4R'4.EG':0ZA9=;7;CSE"7[4\NTO17.?:+
M'[`A"/)YIA<E*;+`P;DW83DXS&6(`<VR'47'V49=%R9L82E(CI"T\&9W7M>Q
M+083CI&!YQT#D!=<4YE@)T/NYL]KF9ERS+ASFB"6<T'L:KIFTZ"8QH/Q-B:'
M!@T3%C.R0-1.'!7T[`8QZ"E>$8?)-`,GPW2AV<#=T[MQ5(OFJRS&'1WT#Z?A
M\CB4Y1/!-9O1,%=.@<T&D`E5.QG5T[.#Q>`IFG?+LF`.[,"2]9/^*!BD3*>]
M6K`T+,5IWF^OG/>C^H$&`[VJRR%63*$RG@;=]C!+@`T,5;'4&6849QZ#Q?E7
M23J(=C2^[N8\O>U*E.,W_MCOH7.:4O1`7IZ)0O."C&Y/-:/3#)7Y(V@XM>--
MV]W#UGJS.[\]U<%!MGD%,QG/S'@%2TDW^1386EH!E'!FDX8CW?CBYY'IT=B[
MC]2&XV!Y1>>FYX\`<F\0^"YRSS8]S4B;<D(2%(@1Q0"4C?O@SS-3!4^!%($H
MJ00!D(&,@.@+C"Z['%][*0+?CX.T0`0(7<L:<FQ6&L`NFL\#7<F;GLHLHZ:]
MN(`A"HH%##JZ8@%C]I\3FBF:#Z2BPT#F_<UI;%".-I=C-[7(Z>;&U':0S,85
M;NRFW\'"A>D:&Q"H;3>U:*0+8*5H6F"7D"7V&MI08C1V^_+Q[IZF]5MZ*@FQ
M'6`R8:]!+L8WI^"+\2T]%[=6$A[DB^-XA[\]S:3>JXWW=?=4JC.,.9-FB*7M
M*&I>,W!D54&'2L:L,O)N.IDON8I^5!>1P=X2WD!SCU9:4W01*%`5>-(B[M?)
MTU5W$(<M%:RFI1$$6EXW01F?>&CZ!*6&TZT&#J4B<$2/:7W,$*_O^>IX$\BL
M0*LF'O!AWP/ZI!<L!L`24']Z;*8Y97^N%_G[0RDBJVACB0F2,?-U@YJ.81"`
M/B$XD!UX)K)*85I5[417!O55_*3S0(?!0=[ZNUTX/NVA#^6FR#&],`.+#LTI
M+Y2.6[-\/^?[<E]?89>L8F@WT!@PB)#NH;E<?Q<MF.XU3!LT[/&].3^^@#9:
M"4\9C>U[UL9("U"O<>>>=#=<\@SL?7&0E%[T%,X!(V\7.-Y!\(99%A@H>%)1
M]-!0.'ZE@&E+*YANNH$@B.9F=^Z;W^D"___*AB((QG2`)8H62A[</LZ1:X`\
MS<[Z?9B"968MA9@5($`$%GP2,NL/S(+T(50>BZ8!-_#T^)"_92W=H.K6$'73
MM\VEL:7QG_ACJN?30&MP?,$?:'V91D_;]I]/SO[8`^'1TXEE^0N>WA99,-%6
MG4?GR997P$N7QDZ_Y2,_UL-S\3.^.6UD-7[&1149$<`^,-[=P.BBCZ><_)_)
MOIHLF4P);F9L@A+$-PI;%)2TV$43R.!I/;1\#ZX$L]U!-$,QH'&`*'#`W1^H
MYI!A%-$EY@$1D*"&64,!]D%1@PEK>0^^50P&R85>-_?=@<9;CG[W](46MT56
M5T#6"3?ZUT]JOH9SAM;AQW#1"?9CL1PSN#;@S637'5;:R]&US<SV!CUTU8W5
M&>K*"C=ZS\^4X!XN($E:J`>>N%$!2HXG<!+=7D$NO!J)4?Z@(@M>`^N6W\AQ
M>7FF0>%@E?%M3P!8(D"JNJ<;/?Z5`"H:@\^@$<K>$^4,M>']L`.ADPBX@R]Z
MB2B*'N0>2*_+*$??NS>CI/'X163<]O?G8549C;[W+3P@4*/(JZ#%@*^^WI'.
M$[`#/$'[%VG^2A#\BAZ8%CEC@$`PG;-!F409)("`Y*H7Q@0!O,:F_Y)5KC4:
MFWBJCB$W?G:O-'H_2X+@CADIVA.Y``K0F(W:'L4\#[REZ-<@\$X)VYYC:/;:
M6BI3CFUY#[71C5T]1T9'<.AR=$ZA8P*<92V6Q4P2]Q"-;``/;!@(B`8QFKY=
M$?AHWPN#/7B!/5!HP65`*6"5('82[X`^[:,7::Y?PWB%F51"A.:-PI[B99I]
M!I\`I<H`,RA:A"P>,(TM>=C/__:&BDY@[]SLSL,75QID_)?Y2$"3\%\A4(CQ
M3$,^P]>ZL>5W8"1CLDE'BQRVV5`^<S&D?#:O@.9^X^U4#5%Y/@&U![,*U(KP
M@#9>DS8`0E$9GCZ0.H'^'0]W")KSQ4=#K;^0OL;>6#+ET(O/VR\G=X;->13-
MN4%DY8PQ:"@>]^'3HKD7A'*PEU].0DZH.RJV=&/'[YDR]#&R^BW(@@ZO[^N"
M.G()U&J:7Z$%:(*60D(*8)'I,3O=G"`3QQ--'Y-%^)$%*@;.]$PM0P%?__;1
M08Q.D)WO#&M20V`_]:=^,-N$10!5!\^F`*O`!,33D7\&?63DAP*_31I<.T*D
M)J:Z:)#E#<]06L?7Y16-+%Q!*Q)T5@1M!S!_^8Z4[\8.`9-N/'-611D6FX;'
M3DRL&G8_S&0>ZX""-?+J+3.\YY^S^\/6X;$YNR<G%IR\K__R\-F,O)9L^<L&
M/!2WIKD29IRH\H]X4:T*5@Y)#05D[A1`-8,$T<_H_#%EI5Y0:1T2BD#0,EO%
MN\`:"**,J>LF/#V(CA4VH/`$$!5@8U1E#[P^+(,FMP;[!K3,H8*%9ZI,D844
M,`^T;[S_]<I6"2UY87PS1WIN8XTL'19#SPR801&3YLW3N@MMX>9"_),U%U:D
M/]WF`C%[&'0<+0H>N'+?795-\C<R>3R4QYTTB"^'JG(XH_DNA<*75\=X\.N@
MA0M4?_4/*<JM#N8.D6`99`)I`4DUMB$B/[KFH`:;?^/;SU:VT16&WY?CCRR=
M2@`\7Z##C^E=H$#RR4K"G1M;#)X'4<P4*7Y*I?!CM9'E\I:I)/NMBN31^WS0
M9$9'K06%/'X_E*?@PG8)AG7ZV`6KC_H-F59JR/C''4IC9SQ_>Y"<26?)&;5H
M@N(<2R=.)1!\!RX"BR3T*T`>)-]9.AT71&=1P;<B&!Z^?,@/#ZU^RHC')WI*
M?A#9\["%)RB./<"9(JPT\@DQX^Z")*1;09.!`+1LQW0G%4X@L)PR09$AZ$%4
M,SPG+T.M+.+J7(QF!)$P',?<^+7<#_"AD'+1,THUBSJ<VM!=CD?/J02K*%/7
M*5(:@]7S-(</]Q=`.C)*_T_."'T_6:1T(X![O*E[JPZ^;FJ(D!45W>-3B>Y]
MA1N__HAFR)26NAW3*`VGJA+M@_\"J)I@1.A1:JT=JD%SV!H!4:+7Q5(4DUF4
MJ_*Q!2BX^-5'9<JB:HO35'Q@D\?&TZ1&D'T/0OI;CE=.)[%0M4,-.^IPX;6Z
M7`75_TN=]#7=;S"9*)!:"J?@J80QG<A5X.I@V)G4LH!0-'GO74RQ7GVEMB8'
M'=:Q98A+J@PK6B@)D%&@!,BJY4W8/<N;Z'95*-Q^<I$\/DIE*^B%Z5A20LRR
M\)1H)N@14&%B4H_`$GG4V/J%L3'G5V+(6T[!'<+*0T4@&AE'!X9>+!2=H:J#
M)8&SCFX;8_5E5XVGMH\\T[[1C5UV127#``6F2#=4EP76L2TU.\B^ZC7&C6OF
M.B!%5IAI,QN4V$K0P&1#>'!`@]2[''W]7!W".;DRL(F0M1%LM!F]KD:"$#DO
M1(5C2`,&*OJQ-Q#?L"`E7R+"/]6\@1FRDQM6D*#S4XYIOZ)N1UZ1JJ3Q7*@/
M"HO]V>,=Y!]E9@PEM6QF8#$`TC,;`KJI/J/6:!WY/J504*FUH[8%Q<Z1U\Q+
MIU7?<H;T`%A)VVA&NFED$X*4QUID>C*F`Z133LIR8([.RW(\=1LTXH+Z$C0M
M,1K_JY.T3#E>N&JJ@%%*-2@$\@,J[_D2P`U!_U"#@P:OM)@ZK?"YQ*3-9Y&0
M`L>`*4QTSS:T"ILB&IX-UO&'Z1MX`U7VTM@@%[*)&D\>3LG&3`AT!5+Q/&NB
M=D4>(T&ME1=_]0_(EIH@[A@@%;(12Y$%V-R+;@XJ'[*/H#7G^3TYB6-PMEO*
ML]H=#[+Y3#'4'PG)LAS?\@;5([ZF8C?-<C!,Y[&OJFS84NV2BN",>'`=4[.%
M62>@,UZR-3M@&<M4S:HU9+"^T5!RHQAY0TV,A`<*2(6BSL@:O'['@D2AJ@J\
M'+W_'<5OYR?<Z$N>C,)D^J/1^Y^J`!E80`2'XF6_+N@WH)>DF.U5?)K\VZ8-
M/?`9.R]!>@NW0451CJIW8]XK7Y-(66.W!!^E-@%H)$ZM>%-F5O;*F170C&6W
M=I-CA,L:E!]^&SUZUW/38,U[M3_*D%=V(2/EV*E+80/YQ@';-TQB[`4(`U_3
M.(#"Z+P[9BRKJ-PX=:EL-*+0H(`!BZR65+5Y&_2;LEFL!&V]X.]58'?I>[?6
M9PGPLV/YPM>+009%CC(L'"WH>0#9M04HQNFF9]+?#<E4.ZJ*48Z^W5N-%B#+
M34L;MU`"(!M6L-2,`T.^\$'*'_Q[J*BN4NFQ)MML`L/#<T=@Z_(I+U?+.Z2K
M+<=/>YEBH+3GZE]3@)1DWB,7^DUX9J0A/E(4K0**#7C`J6:B,U'ID9-N5,*-
MS&G#:4&`MX*>DK5"_NT)D"RYZ+IJ]L5'J>L8>W&D0DT))KM?57V!2%B4^C]$
MJP07D)!`..AX0@1"`/G9H7X_2$[A=4HI"%Q3@1)BG!(L*W!O],(/W%0CMJK^
MN[@O`9"C+O--ICL'&`$!=Q$5!0]F8*8GDX0$$D4F%XPA!SDX)"HUW=4SQ71W
MM5W=20;7U54$Y8@I"]IR9A7R\+%RN*N-!SX1]1E&O!?=Q<5U(0@>H*L+0045
M\[[K?U1U3Q+6Q??>JIF9[G_]ZW]\Y^_[?9O$&E^>6]"3,JPY[K+1![M:ZF`?
M_[BJ@[7,:7KEKWRQYE,:(1%WS7QE=TN9`92$,VN?YPP:V'XDUI&^9?KH:QG^
M&V/F(.)G?7;_4,4D_-2[JY@:1J9+VR.8T;<F@E%28)2.<C1]B)[!)1S8:9T<
M=>,F;&VW.G&O.US@DWI@&C_XD!P\DK'P=!66;`2T5._JI>M%'B&'`DWP%\V!
MJWZL`D.BP>B3LGAFDAB[JN(A3IQ"N(-/KEVO%.@]&U:@=&]57+$$:V-!;PSO
M%"N?(\97C_.X$7'9J<84'2SY(YA8BS&V$[FQB3^1'(S!M8Q&8R>(IS8O;;6[
M[(MLEWW6H;GL9WSY>6?*V,0Q2B7?,WVO))OU54>7*#JH(_VIL^`SWXZDES"/
M!I9>7\&%BXEYVPF*UF:=V2J3Q.Z!A-GAEM&Y-^E]>N;'E\W3&:ME8>:^?X2'
M4)!0]#KHA[N>FNIO!+7^D@\;T0_GM>9BU,W\+OE3?\D;9O41PNA3_2"FY`A@
MC!J73MQHTAV^EW<#BP<)[VE7XZ=TSOCH1RV,NH&!!3+&#T#ZDS!"60R>.QQL
M)\#(3YCM.@J47\U](2P6QQ0QAF[2#(E+'>.5#L@>4R8L21VYZ<U,?B-F[RH1
M6P#PU>GSC=U6A/**A_`F7F]NX@2JTC!3O`]_'ZFRJ;@%RUJ\C\IQIBV]Z8W(
MH:6`90@3LEB8.J!%UBWF@"6)`_$^*70!2H+%-#FM%'L%+S>1@0`;#?4D+%6%
MW#V5YTX;DRG)NY`D[[DH>:FX_?&/Z^+VM.`]ZTB6M&<=ULH[%58S$\KTU-:.
M<F#!%-^5=#C1D63UY$1;0?O#\R+UL)/@S%_ZR57BW+'S8QE'VO%N9EJOIPOE
MY/-^K4"FN2]Y5(HO5E+11)"?[WLGPE9X3(*6:(<*#74/\_1;*Z`6I,#_)*69
M*Y@Y.'*BC@>6G5<ZAWF2L\J-M1;ZP(EG_/2X09_`-7WMOYGHALP-SZGR561N
MS:Z?_FBKGANKK_24MA/-E9+O\($"63D,%B@HX2%+KO/HN!-6O%HYP"JAE`[F
MWK]$>\R1C@/<OT3D0-F%2<'CP%O$JYW:WH#SZ-;3M%R@,%LXZZG2<K0]1QU.
M:JAX`VXL2AN*1RY#&Y62:N)2(LY'.<DN'',?Y>4NAABD<IL<5;XV?,5+WC.0
M0Q$_L/?FP<FNBVHJ\X\._T4M'3>@:AP,B[-MC(%Q=C$LJC.ZJ\O"KD]$B41.
MUS6S;4G:*`_#J^(+P2-;3MW*XFR[GE5//1H7"W"M$P04[!Q%TZ]>)_L*]F^Y
M']1]\ICD)1;HEPB[ZK=IN=CLJC^*8K<`-@>+]9,)/<$>O5/%J">8-_"";`CW
M3G;MOM>>/3EJ,+L[1_=P.CZ<\>2_87@W[ASUE?="/Z-K'7Z+<@:>6PMG'G/M
MG5[4LCT!V/]\@ZC'Y"F)M(!$:]&Y/G[!9EVGL>X\<.O`#*:\<$()R+/Q?7&9
M^(6C%H-+D`Q-,[7168:/JK-\P>NT+161%1797R:-[!2<*IY3VP.6:&;F@L^"
MR;)+A>-+3F6D`4N2*\!*M\2;@8>A:LZ^Y++E#@.%TB$X>-"49$""7+XXHB;N
M1NJWB7!&+IQ]]Y(ME;)/?L6\U,SDD3B_9M>'UDG&-/5$L8]KR-)645N0")FD
MHV4+JIM'Q:8G[%R0R&PJJ512.V$F)Q'"/&AV';BF225$(BTG#HD<<W;L!6,Y
M8)'CK[6_`T*\V57UE-WA,!Y/S<$2-:@UQ^%0>#0UR52J6?0VNSZZP,V-Y,#<
MV;`&!X1E)ZLK("(Z7)*IM<Z8N]F]<,,:9?.P#N:7\D:\"@W'<=X]*[=YU2"<
M\;T3,6/[MJ\-BC0GC`3%]&E+$Y.0=>;TOB!BE(`Z<>^-=QXI=[NEY9^&%-K&
MI>P@[:;)68`M4R3R1J="KE#9`;=LI.0/TVI@7@AC,#V8IF][GL-!]Q)H6WA'
M":W($A_PD;8($>R;G<SNKY>KK6D>*8D:G]%IC,*RAX8KYC?J)4Z4DG1G%3'=
M&W#"Y34U5JW*&O#H`!O[L9MMQ5&G&I`R8<=)9MZ_S:FAQ=<_VPXFT*_[@ZKO
ME_KEP'.FOD<=T74<&4=KPR_Q$2>@AD0'+>FK/'I282F3;!&99!:#S>,?5V6(
MEDFVDK$:!-/)?+!.QTH=8!U;YV/H[H!+QW%Q`IYD/EA0:K?GU4K0QBVX;KRR
M`0[8J&@WC;(2H@G]ME1`[=W\[`G%S&F>+J%XBBQPK-5:CB+BW6"1Q[\=^!:<
M@,!2:.3H`"<(`@^.K$+WSL.0UM_.`C/8DY@I.C\>VQU>W4H[4$[];0U),X39
M7]Q_CA]OC\GK@`>_;[Z)'KSC]RIV&'2(OJH0.>HV`K9J)4X*;)<H,'='WJU*
M#COMQ)YF.[&S#\V)'0J>Y[QSZNZLPR/6[*H-=<1_6DD<0I/!D5*I#EID-(EA
MPUT'-WL$8VZP,[6@KD-NJ9`8/$1$A,D`P\_-S(['"!8E?X3_[A>'I]4[F?D[
M0GJAZ2K/([1ZT?IT"TSKJ^[P<FZN5P&:"*?=_D:"-U3*"T__^"3!QB,,4Q#L
M:3@:)U0D'NI8SM';OM8ML:QX86X@5E9-P+&/8J.&DB?7(_[P`+('F]365X^I
MP*7YQ"LEH\ES8.SVA&"W:;IT73A<)W$2^K*5AG>L\*:^9;0E??)*H*G8$W[S
MXV":F"6*6B9I0.K6CUA:6L8:/.V2(X/&$7G*=EQ]Q29RI=7=F%`A=>.FP?-`
MOJ$$`;=E,O/1;GFU)"@=7RL.JM?;`2!\UB??;$61XFV>$V\'*Z@:N;68E6\0
MP]_9Y%&O5]/E/I23Z:1`USH5VM6N/UY11!^,-Q6E4"R[G-C<N)M,@V;FB*$I
M(F_.5<=:X+T[@=YEQ+S%9OL7P/\/LYO[!I4)UH;+QQ/%X+FZ.@8X&(8Y&^"'
MXF\#Z["Q#>7&B/8':21ZQ*3-2G8YYX3);&"T=JSB(UJW")<"#*_"N!*$]`@P
M"*H<D/621I5RKR1X6%"*)S+XFI(WI@+]<%0(7=<PWGS%2+Z.5@S+E<S7CO>+
M87;GDC;2G_W/MFQX`2K\JACNG"'WZF6G&BD[K8?/7$?I(W`'>"I6HCSY1`I1
M-_N-$U@$@(E,#_&LV>,O5*!1!V/88!B5E6^/+C;G,T%E,V@/EQ:1K@V$UJSE
MC:JIC4<5B8[;9.8]M^?QK"'8("@1[W5)[2LJ4]YK\M+BJ6JCDJ_GRD4,)GU@
M^128R$ZE1#]3O4?@Q[#Y8?:/WV;7)2ZZ;BF6]`&^987AC44PE2E9I`T/55A#
MV%;1HZ24R84"<<KOIHP\#B;XB45-8&T6$M9F<_BG[R]B^C:W%&;OZ!>)L6OR
M+A0:"0P.>#^'+;;=/[:NR,(6YU]%\CV1>I+$!+,EG+'S]$O]6@HU>6#0!NSO
MM9<.AMG#YJ)9E4SLH%U6]NIL;3<J"+Z`PY5`@JH;ABG0D=%FE_.0(0MP=K>X
M#@O!@&`:H_^/!G9[!(Q#'Y)M1#NFZ)L87*I8)Q:IJ"P;\BYGO31/\9QF]LO7
M61$72FBJJ'S`AAVGK54TBR\Q"W+:3ML.!VO:X)Q5NLT465`.ZN]NE*1`^P*C
MN0A2^IJ6JS0'&6OL:7B,K#%X1K1#T:BF3+<)2YJX=_L$_!HI5J,IFQ;/)H&%
MZ=#APB21`APDEW0=B#F+>EYHI:?]JFW@*M.9/0^0>0:&B`L(DFSAC3>V"-,,
M%E?;^K#D4ADNL`IZ<N;[)'U@A#-?.:%&D*JNO@2RR_K^`OO[9;?NX!@PQ-J]
MH1JBNV(8UGJBZ9C4[$$7I@>M^D%JT#9JL`[#++*'&?:&>7E67/(A-<B!0^)M
M[WJ:/5[!SR?7&C.@*5`R&Q[6"(OM$1B\9,VH:]V%_#N*+)W`\%K&$P0Z7&@#
MTQ5Z6+Z5]&[#KG<_L><"=WA!/NQZZ(B6?$897+Z4HXC>X;_V;\>/MWHHZGI(
M2-YHJE!'*TU-0+M?(X@"2HV.)VB'.*$P!UF`9O:!7[;H38DLG\JOBKY(!L'[
MHFI'#2[2T`*&T'T@63DMN'I9..OOEWC*]./84C,S^SX<4"&Q!+1!40[R#VUG
M$';C@LEVS.)?O7>JBEC!'!FJ=E9[&&/:8*Z27)/G)I8"?/;L/W]=H#3-[.4_
M85$N,LJ)M@JP#=;@)!7*`(G!D20];ZH71049XY*!1M8Q3I)E3;8W>R-T1"3K
M8O8$W16:?O^P$V"*#:P9!#*Q8(3/63*B/=6YV/82YQR:EWCAZ7\!=/*=HWN4
M#I,B^QE[\H07]A^Y@J_JL;_N8)5VR[YB;N^\ZZ;<,AY5D.TGWC<EEP+C?_AE
M,3P".::(:21'':.X?<9#%+NPF?WZ_RZX+@:Z@P9'M*P(A(W+B/Q.F9F4YIG[
MG<]28QR5X:GHPZ"/-]R5PF3V74_0;SGXX<(3U*.BNG)ELM_\@4YHHY\#!G.)
M3;YN/",YC!^U>LB^+[ME\(3C0@-L')7&A(=URP4HENNMGN:L6=\>\<F<`]O@
M;8_C71*U2)C`-F*7[0C#:(M:Y\+#WI/;Q"@,Y3\IY,GRW$([@R&08Q"$T^PZ
M1^:"-*8\@=;7YV-]Y;_H?&1_406;QP/G$"$(;?,CV2B2Q>:FL1R#8J>=5!K4
M>*!44MC,WC#'.GMS9ITZ52[66[V3V2>"J0)&;$%@AG/7_<>09)1B99:V>F.M
M<-6_44^V$,96B)3"DW2.94Z@GV?')^.R`^X<%TP%>%2<@/&+6+7(Q9:(E,`:
M-3O^MU!0YDQX;.=@TYCL9N;A#Q@`=<08%(&E8N"9Q$T;$)9<^VSV([KT2C$,
MI*#9[+WSMB12N:KN5,="DM4>E_`73^8JC&3%5P?#G:0OG&-$:6+`+G"+#;0L
MI[;BK6CUT<U.3B#7(_:=)7)3Z:JI_D[9JJE^;26D/@_G=&AR/ZC+YJR!=SGJ
MW<E=LD[1W%->SC<3)-BLCU\U!>>,#@R=&Z]2]/&?2AN'A\\^9_DXC@=G<A=%
M10BG*B<G-8%F]AU?:26R+[!)7_L1!X$LA!M']6F/2Q[X,^P@6TGA!$J9A)D`
M)53,Q`53F!92T]VHX(E$JIJ9XS[,0='CKFHYDI\+DD746DY&EMA&3>=IL!X6
M\F*AM@UPCCB\$F9>_24NNJ=54SG$5;2V/<VN=_ZUP5?S08:'R=`EJ7`'.^R6
M)R2QS1@ZA6A2![<!"W)(TE\>+\>XZ]=6;K`N(/Y=-L)=O:QZ2P*D6C@`RO^D
MI]\AIZID"+P2YH&Q3-N)AC$5_.UE3@&1(@IY/$TP-K!`O7A2L"1@$0)T/4L0
MU!S"/,"#M\>80.(.6#AL.7),[!/$2#-[Y@?:WI5<2(53X-G#R=SQ(,6*8!'0
MZ91IEMG.$X</<S<FMZ["%<-!'EQG5<GHU6@N%,ODL1/G<,L6]L8X_8M&76"R
MQ@P[3RUIU**8E8I"+5%1J+/!4-1!Y'#6$5\FC?39'99V86`QUW"`"(I(_.+$
M2)]2.0F>,+7I1BS@J^'X%9!;.3%O7O_!*;)P@_HXBH+LR-ZS58*#.X[5J69E
MR6XNGJ2[.*Y.+LT$9A%($7/='6'$$\6;`GD>QK<N?$=[58W!$Y+3)*9SS>4Z
M<#'#K=,JZQYFWWZF*CSDFN,8CDY09W@-2!9Y+&68,WN^C1X$!Z+-DG':!J-G
MTTVK6QP/,&@224)M-8,]&&;VWDIB0BULW0WJJ(USE!W8LH6S`Y:/8*H\VS9=
MH&WL<M<Z9(M)A6VRT*D+<@O-(;P>\QQPWK]_)!&S7/$YHE<8C_5%^/Z17CTF
MP&,-Y2["'>E.HOE7CZEBG2+,J7,:&UD?"ZU+Q4(-9*[>KXZK`5",(TB-#X=?
M@[5#:.B+]ZQ/Q^T5'D:7%YDZE7B4!1>%C934U>%Y3!1D3_XOOV))T5PX^[$/
M7X"`+D9)W#FHMW3MSO"PO[YZ4ZNO'?,VF=WZH02FA&PKI2UCI4-C*;`?,)>3
MMC<1HA%([X1^B5U4;-.+SF#>0>EQ2'/"8TWP]SI%2<TAS=DF09O%@,&1&W^#
M=D'7+_U.@<<4PB)M,61?OQE/.#AAVS&?///2J6%GV"V13%CWSP;C\LO-*8R+
M$7'&7FB;74A0W&D%'CN@D]G%EY.T.^PR'!A_F01A8)67P]$%.=:Q!D-*'%'3
M4(79OCE30^N&-J^Z,&IMET,+ST);C1)-G_@'$6+L<\RZ[*ZT@S^9^>H7E.NM
M0`V'%A-)D!;PF2IAE$1Y3C`/P9M0P7^CIM3G<,,KD7.!T`DWT*9R;!O*-!ZM
M3JNMRK!M:4?'J_#RF(_L>1<YOR=</4HER/!;]FFJ1*X$_F!,LBR6KY""@,U_
MZ^6;*2=#Q<MX7ZN"5J&U)D$ZS'Q6^#A>\99$2*51H18+=-,YQT]?M,+L6H@H
M[9H.."RQ`PYS#RW@4'S+\YZ63BRV5T93!!=[W2Y:[',?I%]9OF%O;.5%5U7R
M3C5H<&!U0PR^VR;*($;H<5(0L/(;%>7GT)"$%^!A#`5QZI.9-]Q2H3`]ANP;
MH"O0H\,4):?K0,ZS9T>+'3NF&D@2.UO)ESP)+OV*_>V45[AE2)8E&XS)NF;F
M57=QGDZE8D9*Z!,195*#Q#/6Y\!+[D"CUI>X$V^L1TDBYPV#8>95_U1VL5@/
M[-LRHZQ'B1I)'D4KU\R^_!FQ($FRZG`&_J&S,2%6'1UR355G&'RZAVBAW!K,
MN0AZ<<.)=._A;^Y:9PPIB>3YIKZ73C$]?ARINX3'+L"VK`E*G59NY\>.&O#^
M&[I=&*_:(B&=-/[N]O'+7D#6XFDO(OGYKZ](E[HJ_RJ@JU<T!=54NS3WB=<,
MU8DF)^""#(31E5#\P-Y6P*;!DGH,PNZ\19V^Y`/ZYS%WKTIM1@GL!/K6H"$J
MRGT9@LU[^[.*]D9RN=J5E5E2:$<:&)NYTCHATT7%![=I![$UC:?=GEXQBO"E
MFYFUC^/W*`/&^47)P&`*2HM3;?1,BG&><G`SZXL8$,$J5)B6_G2,GCHI+]@J
M?YU1('TR!5$D7?==9'F1S:Y/7C0B%F\R'"O.N?I?MM%CM(H[?`B?VZ]>U?I"
M;N<-+WO,US$:+EA:O>OV&N5V;CAV^'L<I1$J669/NF3O<X[,=(5[[,A,/$X;
MI!@3Z.]%M,TCA;.E7^$&JL\480LD0*)C-`AUU);SV:M99[+BL')L&MI,4>N"
M6W>\DMG-"K%`\)W)*4X!&^,'&U@?KQ*QQ*3$6]KPP%/RJ0BG"1*5@C*[C04&
M?T(KQYA?K[_W.RW#?,.JDA:2?#%<""X4I-1A9/N+<4=O,?D`[2]VN/Y.L6R$
MRV#!5Z@UAN>47;!%\D%'ZV"D:+ZH-+#ZGF`9;,!*XKO5,?/=JJ*]((/F8-]4
M*1#U;8%+F"S6="G"7N+"X-*9F&NM`ZE;Z?B@NKTPG5!5]@I-/U_8"7?`&LAL
M[0#O;$`.#R6A6#!TGLXV:[6%Q%3-(5#"<3!H9F]^/Y'X@'+Z_?WB!K.6247-
MK(0R(@;J'+\1_D&5+=,ACV[8;>)A<41H&->:D1D&.@/2LN`5%/K3EZ[D/3G[
M_"=O"[SAN@=>3>['SXYQ!%,I16("W1)AP'DMV_-8"B<8#BT>B*YG3T3O"Z.3
MU<9PR<N3_[%V#MR8$`9F%^2GOS/W1HMZEQ?6PCAV0/@?X`KA0\.N/9LH#7OC
MT7P=!6UM%X.H[/M@&2\+:)6UF%=#PP85^B;2[)Z+IU.IE@Y.'Q\:G#MZ`C!I
M(ZO^I^("'4:2%05M]NZM9)V.7XQLF[#?(.?5*U(46QU*T<UD[<A2PIGB\&;W
M0`\5UKL!A78Q1"8OQ-5-S:[!'UH!`8=+]F&+=^P34#NN.=6;U?"SW0MZ&`#N
M1"/H&]G4,EJ$ZK@LC"*'!@_(BY\:JLO#)934[+KV/+P!>5^!/0A^"8H!&]A'
M\MYM;PU/@+$_L[&"H.<:-V"7F!LL!'*4&5Y*>2".@`!Y`J?1"D<%OTS^>H<]
M0'2YWDL+^]]G8/<6C6Z0)J)KHZA(*B32:*2NM%9:=_--I)4>N)@TH]33.I9^
M0BT<$?7EN'TM9XU_?RI/XO/W6Z?<1LFM4?K`@QN$:S[KV0?P4L*X'(%_X(Q#
MO90=YFF'!SHL6KX,4F5KJUO,2RT:8*N>O5B5HBPYS1S;@CM/<MA[%`@.EB#W
M!30J-C?W+[M+5*LX!W`CEO_N_,@O-<KP1KDOK.I0VGNZ[7X>=FCNY[;O_F7=
M3TKH-+L^_WC'I7I@!B\5YE[,2EFBC4)-AQ;@$-G6%J)!!X@2K?]30HS*E_VR
MU/%6\C6LN4@$M-.V'>C\?G[K_GRYGZ&Q\#MQ7;`<P/XP:O9^$B3]C;I?]1SX
M;KV6JQ85M828R2"B+KE;%WUH84C6+'F:$^HFT15CRP3LW5L5(>R>U4*%!J*I
M]8BR1]9\5:WJM_O('JD'86;!0RUD(<`G#E8)>8=,L4A$\%*5>]WW:B9^-:QY
M2/SZ703Y#NP,EU1^O)H<54J:L35FYV=MRS_S?Z^PS#5%E1(1\:E%I8,HX#QS
M<5DI?:K4IT0R@W>3H$Q$W3'+VCRWL%0,?5`;S:Y_H`"?63@4205WFX>&`<'A
MPZYOG$6\V#T"L9`0OJAE+(R-L42;@VC+PJZ'*Z@_J/!<(Y&5:\[OITX3O[PI
MYFMF#[]*$ZUIM.V2'QB>W,,O;FE')U!ZB"Z+X6J7V:-GPRB@;II^T`-+AC?-
ME]=7KI0=%_/$TU\A1V6J[,,W<XB$)#:*P:K@[>D8T(+HO!_R0."#&`&=O#$?
M_D2UQD\G<C;%XT,E^F4N]P+[!9&/UIJIO.>M7X5/+9P_?W+FK?]8J'ITTA?/
MGQ_#OWOHSX@I4A17%!Z0-S1C-3-;-U""SU*:NFP6_^A$=M6#P,E5"<P5GU_G
M"_$UERD0B)O@7_#\MQP9>$B-IGANY.%,Q79`OFZ/?2TBE=;96!UCJ".K73VR
MX>Q2`T]<G,WLXG]`G8TUH)B3=4<4!10?(1461;B+(ACL<"H-3#Q6\><Y+_[B
M^HHZ)*S=FUV_?9AS?:)`B<Y*L;0B_+RB75XI]BNUHRO[][22'*/AC*^]'+?P
ML'N2$U-+",^]ZR8;$(<?4]2PROSZ]YQ4'<`1P<(#V+`S'[;IF10,L.`SS8NN
M1TJ^1*\\5=G:A*6MN5:5E15C8`I=VP-":[SM\$93<$AA7OVF+D+MXG+.Q#0S
MIW_05%2=?K5B"5#2+[7.-B7,8&X`%^_,381\%GR_X@XM42@]"C!_57;UJ]6$
M`E2\H`FV[K9YCHA9NHSIHB.N1=+0Z.I8Q#$1<-D[ZKWJ&`8LRC[:5H7G%M:`
MY8)?5BH"FB+P25I3CA3_!X>WK-:R']*(VF!=_I.SR&"]\8N.(HH1X:^5B117
M&Y%+2L>V7><VI_*4WK[C0U,C01$T^Q@A7BXM@OM)YNNF/VT)&CK+K2U6#N"(
MC+#99SJ%))3$4E>>LS>4SMBPAB)7RJM71D0V]W;M5=90?-<XSRDZFK&L&M7+
M7%06K-0JQL&<D`Z&AS"N9L26=_$;=3!E2,_00F'Y,D<ZDTO.7G$B\L>9VP3S
MO;Y:U6`!KZ5:5BLJ,)7::<Q)'O9,RX#70;0\<5]G):UB,79@X*Q9<I/19YUU
M)_VPX`P2-ALF+\$?6R=S:HXA=P6_KGP/5G:378]]&B09"B)P//<O)=LBJGH[
MX&(1XA&[D_#?,<SP,ZE<T;4,S&&O/H\57N`EE<`%PFXD7A`WI,BJS+`(;D6@
MUK^H5!&S.)<*C,-%94K5Z2@.$\Z=B-H._2QB_'J"!H3R)B-<$1=O5\>,L"AO
M<43IC\#G[.V(A$.>-QG,[[QDGBAC'F;^[E=MA_Q#*UN@MNNC\,;(5<J9CTI$
M#2"(&63X9[2F\LX>G+?\2^7V6+-H&W?R3RV"C0CRCL]J1`$J$;NP'Y/'6VQ2
M7%L2E)E^\0724D$]%]3^G/VI@T7^>Z2+\!N,G2[6&JJ,)'+*A-'&)A>]DYF_
MWIYJ3(&,0G/V&RJKF]NJYOQ:,)EYZ:_(PX5=0OA$";]=BN?']ZS<=?<9R!3^
MTH=:*GT<HRJ)K080\<H>/#]\_6.N^Q-4!A?9J3R"9:\2HW6Q<=EEE(J8W9K_
MF:6M!:^)NKEI181X,=!*Q`(XT&,E..#@A3.S/[S3:REM.)2N]0DFNYZ^BL"@
M<.TCK(Z,W1UUI"Z$OV$F$=\0G#XO'[,ZBP.<:1G!\"]XB<82H_J,E?HD[$1"
MR7.L<;B&J1L=U67V.L.?1$]1FE03OAHSPBVT^^AGV#[ZX8?FH[]WW?/?CHO\
ML@7DEYT/8S@EKR"5-2K*#M[94?>?9,K1NO8^J/ADN_9^N:4O@.E%%<EY#D;1
MIM*V"N;&%"LJ:`NG(`C*N(Z9,;A4;_P-9A_*/E@M8%_L0`FBL\I$8X,=+'ZR
MD;BMT!L)U`DB7TL$MF&%+9C:?HLU%V0X<48DV7/#[+EO&XPQ0(TZV^I?A/%J
M\+EF'J4K69N9!S_78G"@=!$R)BA*>JNTD9LG;<1JQ&A@?@CN2K6.'LYI;Q^8
M#TL!RZ9J=^UN#UNV+'C[0N5R!(E*Z6A!;I'F?PFL(E.]R+`B8I]BZ?018R]B
M#X%T?#.S\HMT!;D4#KE=N%@3KL@Y1QJC<^7GD9\'+@J%7T7$!-IP""PNP,BM
M,`#`I-!-H;\59&]F/O5>0VXUB@6VQ.2T/<8@KOC*8!R=\EI8'@)\<04C+P)(
MP'M#"N@8&<I`<GL1-9\?9WI0)=&XM@Y/MEEZ>J\];U@/>#"SP:+A.+XTG'/G
M?SB<FW7;@@O"(2)-L@)3=$&FEN&M)0*;_SM;VU9T"M-:)_O[Q_A,.8VZ+Q%[
M;#.G""%9?P@M:P*O,/=S#PP5N9T)URG+8Z6[5S/SF0E&G3F*3DKFBQE1*M!!
MT<$E.E$W1>&<NBEY[>GD\NNX#QR<;]]F]Q/B&3:[?GQV:F55+34<&0(J-&KF
M/,$17U,>HMHA<-^>>6/[DN/>%Q3IGT`XF?I"$WH3=Y&9:EY`'\+<`GNF'MN^
M"F([6`>\YN(FPFFYX?CR5IVN9I:W=5PP6$=&D7VO>?HZ_TQJB42QKI(_X@_,
M_V?<W"]\81`LZ^W;:7=SO_PFX:N,)%WK(TGN+_[49GZ\^F&[C)M:V4@*TF[T
M1-:<R=[J/Q'U/(5/P`"$E2)V:4X-6<<1TP$UL+S]1J!ST9,@9LZQC0Q1YN[V
MR"J1M"M)P'TFO%0NWB0\3M/GZ9<FBPU4:<CT!0;380DI`9_R@9R.'E"*.B])
MKC-5+E8I@Y<L<CT4I'3;E%)P:;MH7]"#8>8KQY%HO^WJ!&(/ISUA3_O12LNJ
M17$4<2$M)N<,,+&1O>F#^UY+!T\%6>?BP0M*`_/O@Q%C-=Z>82XE\L=X"D*W
MI0KQR)T4!#!>&7+AW1W5&A;.=^*!^._C@-M&8E20&NC@VQ<H[`V1SW9"WZ3W
M5R0!;G'B$C,OD+JB&\(9[WO?^DV;S<U,U^YV7?9=2AT/_A*<7X^`'7U@>BFZ
M-45;ILD">:O067ZC/UJ)SO&'AV-%7CT^,U$1&:VIQ(WZZ,F!7H"6HL?]AD5?
M2XLZQ/$GNYTFU_`)G9BX*0G4WKZ3K^E[^EA]2.;DR_D@/S#_>QL,F*]E08?$
MW%-70AU.NXB9;K^4;@9:;EH!-%UB]@TZB/)=?`M=I&VQ9A^BI,#"L?^&I.AZ
M]J^GEQ3ZK4[[?4L0(IHB+KOYS8-1';_/40:LAR?AA[1?[-=67)9]<*^.^.*P
M[GA"9K'*SC`V4GD55%'"55I@WU!.HD9^-N,+N51`LEW)<A]N/\"<F[Q8.`]P
M?33_7X.Z>_Y%1-ED9OE3),K.W-HFRA+KNOT-EB@C9*FF^A.14Z7"P*+]T["_
M`V]M-<&(F+W_(J;XPS^`P?/4OR2+SRUT]02AJY_Y*6)]UVY@<'4DL.JH[)8C
M9;[&0F^K"Q[AZH*=4.#.#3AMS-.*4/O_(0KM6_<<16''I^`=A0N*2/8M?83$
M/*G+`JU9:EV;F</4O3:[Z@/I.67?]),6W^)H',=1UH<->7<,MQNC^/Q'0+B`
M#/S(UQPK=Q=QB19WOR*H`W\$S9BVL+.U;VC%;5><6*GYJ8HP7<4J2\M!3<J/
M$$Y!4W`P_;)JS)'RW7^R]Z:!^;;S_H)#<]ZO>_+Y=]Y!G9U&ZFQYN-^+]YTZ
M%2P."7^._YF%B=?3[T<"B2.W?A,C=X>'-W3=>BM&[CYX]84[;SCFZW>QH#HP
MTX02W%KL3R.V/W;DHP_:DIM+?/%_II/=J;2W^L+TPGZWQ:,,I@M\P2[L$?*Z
M@_!F%!PX9NA*=D_E8(!6C\;66<)S"B;QW(?6[9IPZ*"NA]X]O8[*'ON%=AUU
MD,<D\<VY</8_/:-K8++'7G5`X.9T$E]EP,4[T($1]D!X1/83.>>C"#]X#[BD
M&]]X:0<V2=$<ZAHFU,8A;A;;&JI5<-"K0-^@3,CBHYWL59H%9Y+K-)$_"Z]V
M`*%]\`U[;O+[AI?][6I]PQ<SD25QBS<TAX!U?=F5?,OL-+`^[RN*[43[%;OA
M(`VU-,S\]I5$$(,]CAI.*>B=[/K`.Q1A)^MO$:;4CX?/RDC#*U`WR=X7(\HU
MS%[RH:'*9.;$>]1J]N)XJ$/B=$]UIN[RZY24H/;(V#>5]"[RTW%K=KMC;VSY
M0?)X12H&/BQYJB+.Z[H[[+3\5BIKCD?]A_LYY/7#'[5,HQ83R0Q<&]EM-ZRW
M.!<ZU4$Y!@;.?;%NENY0F#AV2ZKA!VT,A;')PZ<@!.4T(TW>F.!^[N6*:;K1
M:8A1P<^CW,RCSX=1+RQW#6?\^!TH.7,Y2PIU^$2S:]]'6SI<I[*8$DA$UB@O
MW_'H\$*!>/`4"Y"+4XN\^K(P<^S\9&?6.3T=:O],(KK,I-Z<RE<$`+TZR2>_
M%ZH`UA7X=UW%(Q@*!$*A<-)D9]W(D8+?T32SNY^3G2REPYX!`"9H^2X@-%LS
M^XOW*L3)-$L,GV`N7F*MG99(LS><==Z+DET:I*".NLVQ:)=`(_Q:DC#)=O&.
MXB3IA`X69@G5QP\I=6I!1R$G^X]\0.>_C&W&K[#D+J$#E.S?:[?,F9<GIGJN
MQ[:JI'7"UCX8\@9O])FQW2LC!<BF?#1*[E'AY"`FH"0J+MQ4](.CGPFW:@*C
M%LZ\[@:5\DV]"?:0-^(:?<H^*S[9:[?EO&=U^*>G'QT$1^Z\ULEPX58Z&($%
M9[[B!B=+JT649SL8W-_Q:?6RI67N.6?SVG.1@LDFW^J\X,Q^$6;V?IY<K#W_
M9JHM80.M,ATMBBBDG`MG??F\[B'\O5"K[_U\R1M#[MYT4[N]GR=@OM6=B666
M2<SC55;982H<ZU7$"YHW[^1`R")R/?^C6E8W/;GJ+&0P2QE@:0JN%,%P7T+)
MQ,RYPKT;,*6*5C\)")LSD!I%W"R=OB>L3M],T]/U[*<D/+TY'$HR%/59O(--
M^=QT!;$>NAYT,11-9+*"2V:`\;B'_AUWG,E?Y8[':3(FW2J]_^"L'"G2M6S7
M.^XY?RVHNX?N;.&5X*XO_'BRZQ"3*>ID6SGHIVN3%)CEEW00->V5'\I5ZZ2%
MN9*F=S(3'([]JCGDWALGPE+\*VJ9RWU-;Y:^DO0F3`^GRU8CS71%'3RFMW0L
M3@^P[X50K(V_7R,577J0.J2+<@,BNH-&&8-P7-?<YBP.V,[BO$-S%C_V3\^_
MLWCO(N(>W8231Z+1<8MF=)",?BZQ<>L*=TBJ41%?FKN(2FSISAL(3&VQ%_;O
MA.F^]^O?/8@[F=R[G9S>O39\U24?P7$.<1`\I]HWV(E"*.S;VYSBLD,9`7](
MZ$`;A6>\AA[S=33J]=?9'N^#279X&,T6_-1#?^5$*]__SHR-:X/E*?DR>YB'
M-'GU;'FN$$2:#R?/.7@<5F273GJ"H-T,PN@[-4R*C%-Q(ND%:RL;G-)?E1)=
MTW_<O/68]8YM^#`S@OFJM("1>+A";N/%M7&*40O=+AGZ]$L^T`$LJ(96C5'H
M2J@TF$;9ZXE*,0./N'SO^SI7DTPSK)D^X?35H/FR&G#M)7\WU8Y53*X\CF8#
M3@_XSM.S$9IQ.]_=-GK"7E)2%@0W$H9"\RC-!:?&[I3Q25"QIL6$OG7/\<)@
M!LA\>YI+0IF5E).NAC&))/LD=XI.==K8=!)2#<K9Q^3Z4)HCM3X=DR\4"TGF
M7/Z,!:H>P@*%[0OTYZ^&>:H$I\V#$QTB$CDE:U$Z9Y6L-2WJ$?>L7;TYS-ZR
MC]>0O._T,:FW$C>C`PWC`2Z&'2/5T7!A!$Q<#"%--),4]EDULGR9-`97HRJT
M0X?!F/O3L.6946UU?%`-;/8Q2?XWC0`D)H3$ZMEJZ.#'CZNJVT?)6>]P`(5V
MH+L*"P(.6GH@;B"F1E+NB,V,S1G46@<^39QL&\NA#/QG2P'5H:I%$J%2#`+[
M*DK-NR7E38\+Y>9<+^2#=JS,LBZ8+4>/D"37X85D?AT])8M?Y]"VHM.L&*W2
M@;(P,O1NX%58:OW/7$BA@]K9;HPOL(WQ%QZ:,=[ZT5\@<[-("$K3<5WJV8M1
M(C*]=MU>0SO]Z.L^>%`[/66@)YGAP-QK+=UYRY%O'!(!`?*IW[:]X6=ES85;
M;WR/^C%7=-Z&`0GP"ATXH40KOEM_@\2.^0;]F/A&4$I](_%Y"B#+9R_UQ]U:
M30LP[5'@1P]B7;>I/OS.<'T'/#I'I.HRIKR?^C3^B&=+OF#50&:BGQV@!M(\
MSB\51MQ:60;(^[6QJE.MV4HD+4_I;1('>KHHH)$1BF\Q)>53[ZMXWCM6OK:I
M=_L;4H6NHH3F=J=ZVJ5]Z8/J?_40W%_[$T9+27Q1?9:Y(I,J5#YB:79\#3@J
MX(_)]_@'.4?\P\4#?:>_67\<5@V#PFJC#RV8F)JEEUXVME5)]ED\RP?-_=B;
M!S++'$<\24Y%'H(_Z)L#<\`XC'I^.GAI1LS7]0`MXO+15,J@ZN]9L3G<O_2V
MP751J^S5:M*?T9H/W%OYLAT!#>2D3N$*XG6J,_$/QS[U&F'$4WT;PYU4-#\O
MX7$2+Y!\Y.QU6PC'9T*6C-(D4)0=YE1]`?0HMLAI6=$@F_G(5M.I:U*J5]SM
MP2D<G)PZ1220]3*D>$4MJ\VH%>ESAV`=TJP.U3B<L.PY11DN:8?.CA..7BX.
M^_Z8(DA%Q*O\'0]CW["+O:I`(;5MD.5?T#!5.&QJ!*=2]$;:OF'6&?YE'HK!
M^3V#>&O.ANL#4F*H4I?%*#3RK,&BGX$YU7:C6KUQ\@E@K<D3R&ZKR!7.\T^@
MRT_\UM,2NAK<&<Y?\[HMV$ROL()[C6#;G*J'U;L[;WCQESZ20`:P0I3"23#R
M:L07EFXTETP98MU*A5X`_S9=\K!3`UQZZ%%O3S4L=W>X>2'O4)N^-,RN?Y/J
ME%3W8[]#U_+(I99OU&A(\2<[*H9N4\[#8KWY?6`$-#,7/\KY&%4A"O_.A=GW
MU@?#S,4_EC::G(FAUC9F8E3<%"AXN=U*.')*=7_$Q;R:8M.7EEZP0597WF'B
MFN6$)XR._,AENU49Q4J,8:*8'^A)+8K;)AHEI[OR;JF.8`T:%L)?OS&=WB9L
ME]WBE*`**$>6AK.?^`IV\LH3[>D\ZM(LG1"1\PV1=N15-?(&`L:Q8S3EFEU_
M>XVI"ZP%4MNKUX=Z1<<T=$$*9$=\:E%0P*]2Y?JH4RLCN?:[%:!>OJ!:[%`Q
MOU/2("G2*=)R@]:R05I/3=AT*.\$3UIH&[E'')J1>[?WO/-_P$XNM.](=OB;
MJ3O2WG9!YP_G49GE[&ONT/THO)JTC.H-LS=W<W+>;F%6<HO"L^R:1A=VM(H7
MN6/2Q$J%MB6GEF-RZA9%'0(OM4B]U`95T-+L^J]2YX;MW"HF2<"K"B7!VI(&
M[DAPF9W`L`Z3&BFPI)0JJ$H`U1M/=3]74[6CMPND"P4=2ZD42O>K'T3?X[0K
M;]]P_>TUD#,D"Z;ICTJR[9$;&23QR-^DB]';4[P@:HETB':XDJA+(EX-ZH"5
MG;.0*1(4[BDP'5&E0JR9?6D_(6P[2V.%XZ14#S)!^@GN>"[-RX6SO[I9$1^2
M94Q<%>X\JB"&D^8COF7[J$_-OU1]A-_,/GA.V1FC&GHGDD`4"?*#]*;'I*1U
M57N;L\ZZ?-3T2L5B)QQ;^O!&FK]*<5",ZS(:O88:F#8$UW%X#AS_"DEM%BKW
M#&U:W^H[8_'B^5'9=>N!8*L0XRBRE]H;J#YJ16[SV9X3I>TAH@`_+I"NX-S6
M;OUH77<NW+B>B$NJ4G+RV+>05H@..P,QQ)&A%/B*E7T;P9Y<O[85")K=:AN6
M1EQT['Z([EDS>]T,HF0WI+W$TS"9?>16/)46^I3/I?D@M8"@5*B4C-)QZ8U%
M,\*WY7)A#T8VU5R/P=L66K5CUKYE>8Z?>XGPANO>N0+KTL_-A;,^=.PJ7;C*
MV5*</#\8EH(H_ZU'XA=6>KI;IW2H%Z2,(2J'(=1#*];C.DU8.DGN.A(7T[7G
M0D-97*Q[<+O#;.V:%A5>F5E%4X.MMT^]"=W2^?"/,]!V^^@7<3R*.P3@#6-C
MY!-_<R[B=-7:UI!4M9D=.P7L%AH%-3:\.-%YY,(Y=ZSJWJS.F.*]L7IJEKT=
M;J&/B%E%:.@>F@G>]\N_W];EQ6)8@:-^,"*IV/`O,O"L6I>>7_":N^XXE`9D
M,$2GS@$T>3;7N$P2L3N&.8%<-JK\-B3&'4$6+3#NCGF<:0(\-#PRQ_Q!\?<$
MR9)4]*GP%^;H$S<+EN1MO_[.1YQH/)B$;W.90X05#2>^$"O`*K%7I*)J'$9U
MGF`[18^$/0N1@!$FK`(6JX?.7;5N<.VJ7-3"_%-NU86;.X-R\!46_I":=I!Q
M,9E9^`A(H3*K<ZP_6TH-(["4&U\B'GC[P@5+%B\!<S.('56G[A94[3>\L*D(
M[]7$L(68(N>Q`J0';MG+^R6.?[9-&F:[;&":^:['+J'9MU:T8&@G1!%>/I+Y
M!=!SNY\R,HG4'S=11-!Z=]G'+G%NH<?NIQZX:JE%H5,Y,#8R9'+67=1*03A&
MV,[&:FDR-TI>P=8()/(\1@F:%F_G+N@_=V'_N8OZSSVM_]S%_><NZ3_W]/[5
MZ]?GE@]N7#8@GQT(CW_#$PN:A[_S]PNC1=%IT>)H272Z@M6+CV4]GMTM>AY1
M<O,%#I0Y*XN3FHAFALGOL#C14NPX:CY-G$^T$&>T*'S%.W]%4Q+-V&)&J5]^
M5NDRN$\@-4BN.V`'34C#6*600*Q9J\0:),P>O;,,9XIT1ZDZZB"#B9=/%@:8
MPN:2U$F2/".7N.:6D90`CBK63N()C/DLTPT-N#U%S?%*^!%DZ\!+&XA';/6'
M70Z.[I:?#273LN#IPB5K)!K#JG91>T88=>GQ:IL:?#;9]JSA2M@:5P`S>V4!
MNY)ACKQ&%/=<S@QBM":X*6IR@0P'=80PP@<1%ZR,D_9T4M>OOICT4,#-O7[(
ML+&!1,DL9S->ZIEY,B+ABS4!OM?<(E-GT!=4!QYT[:3_`$Q7%7DC@\F[W204
MB4:UFK$2[9L3C.&$GO[M:J2@*BG.[&L_KKH9:N.++`(RDBK$W.0$?H5L&E$=
MVD*MUQIT`[86:G"=O<I)22LPG9SJR._;P8M;9'MQ1QZ:%_?UOP!#Q#>7D[NP
MZP.#!4;]88I",-;?@I$M;T$U?WKDOE3+7:=@NDLQ4>XCG^9Z=ZO/9;GL%CPZ
M<36R,'>)A8GEX4\@R/U@:#>+*P+'YC"MW4:3ND=BFS2Q[LE<WN[5L9:`6G:6
MEAI/+R'[5Y1<IZ9R[P6X[!5\)O=+%)\BX$Y>,7E[&&/B5*=%P-^N4^@/?<3=
MZ!%6OH["1(D0ZF\'AS8>B]QQA<`'65)S8T=DOE?"22!/B^8>Z8U!,I5*?75B
MOZ4F.\$T^C=[]\RMR#.*4NFDR>S=;S4&!9AZ`7C$E&J"P=$*ZPUG';<;E.T+
M&\%H##Y(+.P1<+_FWOXHJ(68Y7@L`1G5G4^9.0FXL.52S*LABW_=K;*3R+04
M,=Y*Y?P@^R#2^=(UUW?XA1O*5/GPAW5R&FD@N(A.*;!;'X1=?UC2LKIY4:@9
M(2ME5Y'XMG\>A1,662IJ`\9;-K.?_'Q!FB`+:2%]==J8;Q3X1212<]`<GON>
M)X?`8D'+8-:<D+#_]%B/N5%@M3'TQQ:O:;PB$\C[C1IFTV?]D-!--3B%)6]8
MN7+4)33%SJ#0BES&P6$];*%G'1PX*&!FU/P*\TV@E7'!T&8BYO!*B@(E[]8P
M-,(TPLR\HMSYJHJC662%C6'$B)-`!C638DI.'O@XE296^[T>E$`S\[WO*+7"
M#,BU,JTU7=WQ@XS$L4",@6#CL:"*Y!-P9)X\E59]&CFBBJ^U/&EFKGR,#@Y<
MDJA133V3_`/JX0DC7[<3W6H_P/[QQ'*A2CU0WNA`!AYLM5J)KNF[#2L)D@2X
M_'%Z=LFC-X91\>*1\Z\NG@HMNM*!V!^.F=1!\>+X%2(;%BYA=<KE:>F#?'(S
M\^^_IJS0LC#[BF7)XHUGKP>%*6$L@@Y3A#KP2ZAEUX.E\>_?DB:75L[0!(+S
MU)8!1K$_H+D["-A=2W]<B5LN[^!&"NQ-24A?%S7`!6(;%.,L[/9*&_IB'5L-
MK_X)D0K)'2]@S!`O'(D^HNP<NG>45X';9BK+%3UAM\87ANV)@VD@"V$\XEE4
M.*0`FYE;WV#40;2*?!_XD.'ZF\Q\:9R$&GRR0PH"]X:?8*A*;WT#C<T\Y\JF
M,CTHF"4'.Y3OE@JD1!2=.Z-HT8C7!)E0G3@A)>!-VJX;WD>US*+WLU?/)X&$
MQN@NRQBU)#K/'OZ-7CO)2(XDP3/?U@#5,<8+`;+RF(M,4>-5>XT\CH(J-?NC
MBZT"9MA7L)GYS#<I6,ZGR0T,/U3[4N)P,1@9]7B\2<^;%75K+1,C/Q12V_P<
M(W8PK#:Q8WDG^SB!T,;Z!++/U8&FS8&[@4TGLF^9@&E0.3F9O4RYQSN`B\NO
M^)8M+5UQK@(Y]%@ZAD+C`G[*C;\`A<*E_WPC<N&<:Z_O;!V9>WZ]?<\GN[[_
MFE$P("(W)O<$7EB8H,%<<(91PL1>FGXMYC?L#;O^LQ^=&34`3Q%\&^RC0%9!
MT!@9(=-#'H_O1]E>:?HHGNP$>[*8II&[Q\@P=SNHD%JUY@7,@)(J?,`HE<UV
MD##KL_LV$AE^,WOC%:@`Q`7%&K9N[=_X5(>D<G]XJWLB,ER"T6FU.?,/)<.8
M<S==3-W'U,720S0SURW`IX]Z(Z-PD,H^/(1%"%N?<@!(DBNIINSBS'4GM5)O
M#`?QIL<%D.W5+)6KCAO;NA/GFM(1.!WN#A:F@<<A06KAA,>HXKG"41V/!]*P
MF@^&Q\]$QO^R1V4V!Y5V6K[98RCSCDI/+?.7-VS5"\!*#9K9IS90STM"*4D<
M"G^)19&L;)UH*U^-?3]I;01I"@\=/TDT'@H1`D:""PL'H$Z<R=Y(19YN+`UM
M/+'<8C*.7^U.19!5VVSFVG(4]P.NG"X7[V2\&.-.7$#U/&GP"V)EUD^Z-]`9
M''6J<#*N^#2)0TY,,FT@%?2QBRT2WE$DLDH>P+-->LGH5QA(H1DI2&@HQ`6B
M@B0UO4GOM#Y:(\(V"P^BJL6Q@6P%[QNGM4`\\Z)S+L#*'RU'PD!P"-?Z$[?#
MI2)_L$)L#9MVRLK&-0P`.7$MC]5GEHNXT86+&+#0;W;=^Z<TQX.TV&3N/R%Q
M]S@3BD=#D@9%JICFC[+E@Q$GMC]U7L%*%)CBUT(X<^[[[_08^X#$+35K0C(&
MT7A:1,ZZK-7ZOCK.FS"/U<R^?Z/A9']_5Z*66"TG)?-8A'&"+I#RI3![_WET
M5RIH*<+5TNV922[`"L76=)1!45)!*-0*Q\48E)C,/'&U>IW(562=*)<]+K=V
M\FQKQ(KC@WKQ.7'R8$=&_$NUF[)/6<^'F7^ZI^"#K3(UG&0E5:2!3?B`02_8
M"VQOKYQR6@>L/N\KPNM5"FA]8,(>I;QF872J<#NYO%8JI\7[(/;"J.9P7SW,
MO+.8PR((Y)]WZZ,4``SX],1\=C!4R41\OCD!^)IM09G3[*#,48<6E/G!L<]K
M4,8X"F]^K.B2,K0)]FP:4@$9L6QI4Z2=-)UHBC+86#@IC:H')73)$7!83(1%
M@:^Z[C_SGI6K5FP!M_G^E[<ZXADC+#IL]49[5B+ZO7NL9]=;HE;O9->O;]GC
MEMO+>+.7_D>+^>.Q"4A-!8)Z>N,]&U#)K@@S)_Q'Y^I?^,@%"(H/9^SZ+/YP
M86&;IYYG''E")%[TVHLZCX')_A7WLZYB/Z#9]?!BCSD6.X$'TJ69259LO+@E
MWI88JS7LZRSB[GKN2@^VU=-5D$"-27@>,=W.,_R&<&3N_YETB,;::K3Y5;I7
M>`9PBFA:-!2Q/69TR]+YBQI#I#O)@W[Z[3M4@IR<;8Z^_NY<>5T5;27G_Y1/
MXH`6O2D5)M0XGW3/(-:5GO*_6YI$/LPL7.*E@"]P7@-J'8RWL<Y]'KCCN0E9
MPQ@EL$W0EC1;QKR\P@IJ"V<P5#S0VB36I.5V"L*/%@X9Y!Y()Y)IN/^*/H)P
M4`GVEQ-?I>AM,R?^51N];4=]-<$;R*&;0!*P(,<Y9*UX*R6.S+2E.IY.'E,S
MN_L.^@C7?#`ZH48&,\(DAF,?/=6*2[X;:HRGOF%W2*/>2YQU0A(/$K"XNW//
M?W@=80]@;.R925_<KBE"BZY;:F:=/ZH7FVA[L5WR8A[9X3&%FB3/X*,K@RVP
M^_S:B(,K5%#UXBKLR3'T@/,(-E/GG2,&KC(`AW#BCT,)G(XDABL8\X)S2E:S
M-L_<RB@N"EVX0&4OF)(9>XKD/8QVZ6!]:K^:F>-N36P9O@?J"Z\0L06K%UT%
M6<!2>/6W.$](V>7C;A5Z8T?G6/.XY&[4S;:=4TEL;>:*]4Z@&4W1<U4:,5D+
M3HUY8$H]FH%5>V4852X*H&<LN3/PEQ&/+,WL9X>*D:-1-'71EN6+B+RH8?IQ
M*),6;FAP\8'M+POK4Z"/DZ&<7"<RT^*&<7Y3E2`"SR6@"P4#)U0P,&79V$Q[
MB2NCKN=*)G2F,'GVNW],&2E!'%#X&C4\.*'#9F5C6\K&NAF!#C4\_(6A"J60
M<8$H<D"AZX@J,GUETPLLF##S)62>GQ"<3*^DUP7#2U`%2P(+Q3F!9%V4$!':
MM"6[O1B)9]-#G?5D..-[)[:6@D'PAD>OW.8Y3,>JVYU.;5YUX>KUZS9O>NNF
M+<M7#FV,6@<1<M;PG90N:CY\V-DCA:GZTJVP?K!\)Y[86D:03_,;:H)M<"TE
MB2'2=NJC8SUK396I4$81]X!(:7K*NJL=20/SL/W]^AMD*^!GEIUV)G]FZ<7\
MH5PN]V8S,*KV,/NF_E8W6'.TN4QOC^^]8'X/CO#._WHT^9133E'OD_CM<WTG
M,!W"3/2SZ1=Q\UV?AB73[T;1#P1#Z&7<NA5;X;X\LTQ[5`O)HUJE$.V/?SQ9
MFHM%!IMV"K4*AIS!I;KR=@NC]ZF36'M^ZG"%T5,^2)';=J2<D`2%QC3X2[CQ
M][X8?23ZK"HY(+&E@QZ*AA0C0P_>@8Z\.]GUE<,U1S_>!KI;!;?H@#"+Q6/E
M&XON!T;DTPX'!HG.NF@#IY'R*`S`=0$9$Z/-KD.J4KS7S#QT*A7OU6JN@.;"
MV4>>PZWAV=1W)$"N''N<)K*ZWXAF%GX?_ZADIL6:`G*8K3ZB@4^:(PHM1=TN
M7.U-8#B@(N?%BHUVK;[&`G2#A]E>1ZW"?K)2VK_E5V`E7<<<M0ZLZ)A6VM$U
M:.U+IG*MDQD],F@:-7!C"6H%Q2R:0H*1&DV!>F`0'$6W.L`$`!BBV/5-'>'O
M(DQV8&=XQDNN)2.=Y.2^WN_Y7]M.+0D/4XR$9_R`O(7HN\J0/OT1O#Y'G'2A
M=:2'BLVNZA-.A4/_*!(FNZJ?:[6=5^'R(/8I?FS$SDC<P1,1S)!3P[/ZT1L$
MCV.N>\J.5]%3+P6YBRSN?R01ITB#<'GQJ>&>2>HF*8S1MG+PU@)H_H!9IVWJ
M+EU[@J0K.Z\-1U[Y=GQGYKIN>V>KWBA))N'N<.7;H`P*?;C'(55XE<O8AT:3
M'4QQED!]5OXNY2EX.]T"^!-!;R1_L2)17*QCZCAP-&='50TU[%4<7BF[RH!:
M/R.J!KR$"S>T5VFV!A;;;O:+#LW-_ODMSS/V`=]MF[/CX.]VS_E4,'6A+JC$
MS9!HM_IVE0H$_)(J:.\5.!)6`B5)3%2QEWT(*.,F?4G8Y"`OP@OR8(`[%1=S
M?O291,$4E>Z.U#KO\X2USZ8J"7FE9(/9CA>G!;X(AK@<PYU6MT>Z]POHWE^`
MJXS.-SQ@26Z^%?3K7E5VO)+2O'UC9^6#7*,\G(/G1RUN'41B,"]='PP:7R?(
M4Y<3FUL@4(.2?*729-<W'FQ+6?0E20?;!$+,[\9LA-U3N:KO(VU5UT\_,)4K
MEHEG)<?4E?"/LEMN]1#T@KF=!%4HLCHA*]!7ON=)7>?2SV7Z8*%_]2.;)2EK
M>ZCRL5R^(ASL%K,A9=.]@H?PI*FUSIB[V;W0</FU&)I*23SB/W;H"S500^C_
M"1HQ\!4=55W5V>"7L8U!!RS71)@2+S2*#%"T>E,:#D\LYPN[)H9;JD<E:)N%
M5YSM42&3(RS7ME:A`CHB@IFW(YRY:.6=GGJA;JNXB`X^![!DE7LD7914D[9!
MD:1'O-FJUTL\CFKUG+U_V[)Q:X1ND+G:\XA:3+V@)F$5%GH5-9`E$JQJ6T?_
M'?[)=?J)&E!5$\E3*?IMG#E3):)$H@_P]0<_"3_5C7\9(\O`=7*GV%7!P2CL
M6+^6`*)A:`PV$6%9Y3V-#*<SJJ=RX)ND.3GTG8GTA=%'6>H)85XW&S*MX6]/
M@2%:S3E>KNS5\?HO1>QG_TBET:^.4Y`3>YPB"`Y3;THN%+1K(6*%Q$=?Q3$5
MS`BMLQIE@V7Z<!3'7CH89@;/10MN,C.XD0)KX-XQGB;V,8U9JZ&I2I!K=:.#
M96'F[&?1/C48B%4;ZWY<;=1CBG>SB1A3!DL]F\KSV8NP7&J+^MRJG>,BN`3Z
M<\7.L/^/ZX:"9O:.?KJL<'V&L>*16C=NOW[R+IC\&RP4Z$K.*C>S5]YF\@]7
M;FUI#F_5;PE#NC6_C$E5<'CGWKO<%Q.24\MHD)I`HF)_,LE)NY7-C]]D8FZ)
M4!QUG<2OUZ3'`1BLB,^85R'`IT`31JA!F_0WX^BD7_4J7.MB$<U]\P<8^N6V
ME*C2]/`<0Y2<4#>[[(P,0@XX2:W57;"<!=4DL<<"@NZYQDI]3-?;"-9S'.3?
MS6S9N3N(L$]U:BA(1L;'(%C00^/4W)$&!0)(/'33E<"WJ\9D$'+Y)-5&8L,W
M=2I)@>XV#:T02$J(M,"M!.Y)NB,)HYJOZ;/P#!24*;B.RA\:<*-#;%1P+QJN
M,D4Q[HG;JGV$MOA_"4/!R3Y%:.)J/*S))'2LR-F`2=OZZ&37;YZR,DWDK-7\
M4NS4R>UKU[KLIL/%/.^/0\780'BC>A#3>\6J_BE.!:>LC)8J]_";V4_M=MJ"
ME]B_E!:!8NZ"XF43>@?N"*I=07[/FGN'76^%D2=N$5U!N`H??7C2/-TA^U^O
MR5O%?(AAV>$6=%$?GB+I=\=XG-B7N*G=3Y(L/VQ\_NOCU67KB-Z@>@6)5@I?
MRZB*J./N5USV/;1\5H$S?D2G3@"MM2#=/`HR_$M/R1_!.Y*H_<58XJ^6JZR`
MD7[[J!465A.K^@=1Q'BONC'YU$?\8K9"QGFH]Z!M:&:N?+V$%J+/,<N_W::M
M&SM;X.?:1HD*X]C6CRYTG_0+L](:["AJNG5X'E>M$=;"Y!\L5#>I&&IQRUSB
M].JF!:6L#.(WW!J&H"D!;\)!R@E*)PR7V)[,T8?FR3Q]U%\`Q;V"4-RK?KH6
M:3:PVE/+^W2YYTWC.@%RD]L2D)PZ6&VL)IU)Y8V\HWUU$(?'K8M-36JDR2FH
M'YS0<EK]_IC!@D=2-4U!SAC^5%0\^G+5$\<I(9>1G:$@S\%,1;5F=W3O1NS?
M"WM?HR1)(!@Z+HO@NZKA/9:B6QK.FO&^SJPGJ=5!H__LGW.R]N\_4Q,T$EGJ
M]J1&>4Z4/==1BA(]QJLCOLRM!ERZ:2OBKH\LEWX=)84L<A)DRPFDGY"2LVU"
M>2J0P(M*Z)`DYJ(@`I%&%6+O/U,;FWGG2QA-*\FU1ET0=[[<)K+<$&LLR;!N
MHDS&+,K[KVHCD2$_-H0Q^2:3RXD_ZCY.4O6,B1QZ*G.7\?-,AWOI8:91W(1U
MKG'''"F'D4A/[):TAETG^Z&28XH_YQ"/N+&7X+4K`K8&U<#I)Y7\ZJ@Z438]
M?"EF>$I^P"4XK*:ESQN[4<O"[,F@\Z,B_-@;9K/P4;;5.@/7Y<H^O*JEZD!5
MRSU<2E6#*3<22URW[3=)UVV_;8UZ,#9*MUCR(MG[[Z'CH:]5[*J<D)0+8V4'
M&G!CV.BWPD%2V#Y/Z32K(1*^=M$MZ59(=-:I%`.L_KIK1<](=^H>[6P&TV,-
M;8*!K&&Y4$<M1Y+LO.-3,B%QU+T*ZI%`ZB530'6K4L_FWP\SYST9^%H8,;>_
MK"S5YB&\[&_8-."D&S=?[)#U5QE(\J_Y2O%M$FPK;/FQ]Q"E-'7+A".="V>_
M_G6;344%V2%8,*+0P+&#-1GT7(RH8\S<Y\R6>T0>UXH\G^FMJ@3*:P6AO%;]
M=/6NVVO2[M"HC%L2*B/[C8O4^<M^_1FZ&2,CJ#0$@2_&D&ID:"V$W22ADJ(K
M!T?EG[^_6>A2I$*;,KJ$#H5/@8MVT0PR6R_X&KQWR2M:AA:B[@RAM%@*M+\2
M_R[PQ#K@.0)V$;AQI-6M1+>$)8JL1&`XJ>\"JB9RR=#H5>Y4C5.X-+2'X51'
M@;89N^XB,#)GA]9@!U!IG_Z]ZFI\F8KRO*E'[01;*9+.4;60JBR0>+T4RX3J
MT8:$M7U4))-2S\I'8`B%W&P+D;ATY\>4SDU4;W9@S4W3WDX:S0B_AR.:;.3C
M!9.9347$'/I\A`,ZKF7BY8;_8O`?>^SX!VY#S2P2F4U?)Q8)*I&B(!YYN70T
MX":,>%3$+&E<(M;%^)VQ+[!K@[L/K5<I;\K>^E+,=C4JJ`Y(X5I=YE4&1EU=
M-BY(T[@@8'U<*[O-2MX10]&H;`0FO_(X!B9S>"^52H<]RR,=(UST[QV5ML`G
MLQOO]2JF:',>6<]3FU>O);KTWIBVF82]1ONW17(F,[=]8GLD7A;%"#IX:'5?
MR818X**TQ)3%,[*0&]!S<LZKQ%,;UL1$^15[%8-1I$29=#+FYJ1U6EC#4VP;
M=$.59M?5QU$VO5(`[^B.J\&BP;(:LGU23G@D]I132KI?U*[(8RP39;BTW\N"
MF"0A'`NU00HQ0>`:D$)>4$8Y?^/J`*R=<&@Z&W(8W@;.3@%,O-=\3)<J9,*E
MK:0]Q<%(OH.2T,-#8UE4E_V]<B79#65;CKU'2FD*/71,=L4\<L;>\Y^J3S+H
MZ8<G5\C!@6DA;BI2XA[&Q*M$7Y`NA<:@<MVRZD/#$Z@(F]%V`J9@-6/!UWE-
M>>&#*#-:9B0[8-!PLCSDRZ^D:+0EF0)WI.:.,!4)'@O1$+IZCMLJT*I@'">F
MINPD_O#B@/-^_/=)&\-BI!BE=8B<$R+-[-WQ]EW*%YS@@E!R/G63%5NP(3M5
M..NXQ^#NXUGC"`_ASVA&)K8O5>PE_KBIK4IT)WKT8EV\MGE"4YP/**6DF0I`
M`LU]&9$[@QE=`2%PP@.#)>XBR1LS7/((("L,';C8]!V,BJ-Q9<>5LO.^2C&\
M&MH&VX>1(!9_A]7<.!2#??,.MYL$/9BGDM:&,J0;=4;V@A&--2P\&*E/JG6%
MR<5'JU.OUIH\97C?CZZG7:)#RU#([BG=8+9:BEK"3<I[@]0AG[QVJEITU">*
MJJ782%#4'P;MX0ZT>A00?CBFB9CBR!+Y!@(S1`NH@W-^NNV<'W-(OOG,[`^?
M?^><-/T"TO1K":[LJMHWB\_=Z/JV@NNDNA]UJ`Q$*">(P!S6D]T@[MM6]\LF
M%D6=%ZFE0V<E7QU[CGJ^C/&H6'XH5+T0UM#6^B#EL\?M%*P<\B=DA[8F@>1>
M'3_A(97#$7G,\6#35&0R.C!*4:0F=?8V;2S),3.]!HV'3'T=J#]`$M\N?F#%
M%E1E/[&F*2I^.*15'3HJ27-[W;R>TG(@;%V-:D]U[K+7N>PWJ<&!M9[6$DZ[
M$1'O0L*Z6HYL\3\ZCEZ%V0[0=;,AN#XN:><7TJ@(PP1(*%/AV)#`2=YA]&_!
M%U%/>^$S)$AT2X-@1[!R*H3:9N,NE)-/RX6V%^Z,="-.!Z=Z][">[?T_B2(+
M]K(8KJZ)TBD=R*>!?^2T$C9--DV(M:?)5+/@BLJ3=<\9A&^$F0^'Z=T"Z01>
MXE@_1GE>?/5@I9FY^I<I?Y-,!4+9&,I!BQ7*TCYX2_'554?CEIPEO!:3F7]X
M%J<9L1T6-/!?MB7&87/Z1CQ"M1!DEWA?0@.;*_E'"4>E;:38*;"*0NMMA$KU
MT<.Z6?(A>'4PKX1@!^EJQE'29.&4%2Y%=:0ZWUFX)76S\"QFWU7S.-A5\`+]
M?$K\CU`9S#?/J-/161K.OG>F@8XK$&7)0<\E69F:IN"A4:H4SQ.#CZA+I,D<
M]4EN9N>>X.[`(E+4=,O"K/-N+C:(=+`8N?'!GN4V1&BRFE!3P:TB&BM)9[?H
MNXR"X^)OS%)2GUG=M(B!O<WL!<\:]X%JZ-P13^QB762/;)_8NPMK!C0:')GN
M&DP?-F?\2RRF8"IY:A-%6'JD$2-P7.J9!/;@>!(]AVK)W2K-GB^!ZMTA&H):
M?TKD0Y?H<`L"N;U)6?F+14R[.<:+3>:VEX?5=(*@4:Z:+H'IEA_95^OVW%2]
MI9K#,3:%N3GY]O:I'ETNW7A%+-K,'/,OJF=YF+WXR2&!BH!I@*TOX;J#N:FM
M6:ZX*Q0H&S<\#$?$,\D%R\^CH!0^51ZJ*.8>6^*`%1F_#6V_<C&_(VIM"W+1
MU([QR_#?'/T;56U<,!W!D2HUZIX+QR\+9RZ]K=4;8[<J>TY"YE?WRM1M4K4#
M`RWYH?NM[I.)1HA:/#<J'AJ7I7&E_3A0-/>,-<I_1/@B(ZN1),$&;&9_O@U5
M*OH!\E`T#9N9XU[HE17MH32F)*N=R2Y!L^KA$B#$P*LW=%=(HK`E1@ND!R2J
M*SS(HW%R?51?3'5]1"JS"J8@!+/;4>33)'%*6&Z0BE8MI&A5FD]_NDS'H%[8
M9G;]'SKU-*.[KT.I4B^K2K*E.,!!DBCB*."B[)$*X63P1E!,`26BO*(_',!*
M<2<5BHRG+E+7$S,M>P,_(M:&+H^AFVD$GEQ.$1*Z6X5T,[.+_$%[S3IZF+"I
MXB?<;(J*0I1Z7&>MMCR6$\D@4?:6'#$9YI&V3_=!52X,G`Y*EZL>;V'FMWN9
MZ9,H"*33'`Z;"%M6?`MZ#[I2OIY:H>SJ$U2E.),*Z<?"]7SW!GQ!1;I!M8@2
M6:3D88?]%>W2/=##*1:&//`'E<1)]M,\>H8VA7#/NQ?TH-S#J'B=;#PD^,*<
M`SP14<"$QS**@6>B@;?S)$9N[%'=B;!C*\\ZL;(0U0=ETSJX-V?8[LVQA^;>
M'+O]+]!Y;N7.<.`$?Z,T!LO>T:^IOI#2;/'1)AI(?D]5Q+RW(QIAN'F`B7R/
M#IPL7R)"8+&$6$<3SL_'COSRW2JRE#ES)JF')`\1'-'EM]TYNJ_OKDO#S]M(
MY;IWQK]AC?0;;QU<MV=I...ZWZ-97':1?(*@27[L"UT8_!^Q18Z7,:97K%=-
M=768>?T?6BR2LY?.4,%LK.<:17V!ET)[)JHQA$J+VY86`;A3$4'M1<`3<P6G
M4G=S!7<IXHKZ'*R[WJ94&/X]&`T:#+CJ_'=LW>'D<XVQY`?$E5B-C+)45$Y=
M!LZR1U3*CR(*;IUM02J7MTK,B55&DCED+U`/@H`4H5\K%3#AH:[[.1@HI9BZ
M*V5DZK!T;,!+"8@?"?;I1[E6F5GV>!JJ[@<CR_@IHN@2+5*O"4])@?`BN&\D
MO*;T6EU<WS[25R\$;Z9XA/1(12!WKC8Z7,FK!9/%"OKAX[DZ(MA:'7-2@]):
MO5I2,7_RNW%K[QQM.VQ3,-(!QLG[I9*K>9>>8Q]UZ0=(CZ;C4T9;O5%W1@TH
M#QL`8(/$3E,XU(Z\V<>>:@UC"W`4]]CA%XSC<FR:^T[[[@7?TN']>+3X27U^
ML6^S>V%K^IS?EBVJ>CZ:']VS<M?=9V"+497"F?Z!V[SMB)M$T%F?^G0_#.66
M^N9W7@/#^YL]LW2`CC%<R!7.>G3'P=]4=:4!GW+V1^XCB9@]XA\3#`Y2L1'(
M<=15)<Q:K!L34M8IV590[/>;.U*Q#I^N+G`S,[P,.3C\8ICMN;"M4]_D"2T5
MT8?5O/JZ3B\E451LG=>O&^B!#(LO(Q$XK^0>Y#52+L<-)]6^*[H$EK;_DG`%
M/(!6Q,=6IDDM(BT@*!\9M48=8O^G'$N):+*1"6N9Q7R&>/-2)&80>P(,*%$D
M08)"0GK"1METAX4+5??`3,_<M'FC0XBHRQ1G1?L-W$)Z_VR$!TJ'$P50C%:`
M=9SWD.C+\0)BB+YXSSI*"45D^8`7,ZH&ABEIVX3HD*C`@UA*O9J:VOJ:-X*T
M.%S\06J.UZK&$I1J4YT:_)^C8Z;832KL>>3R-4ZM%"UW:[7Q\'6/7'F^1X:D
M%RVO888_/&W_,](/>P5\S@M*[DZ%LMX\ZI<=TM^K`BP\R3WROL$2O,(;W1?4
MW/%PR<LN?>,[P]_OW^_71J(U%<7?&^9.?V`#'%<0]6N=_!IB;=5#;O0T\&VM
M#PYUN/3.!_6R1[#F<?VR\#7KYJ-@B4&P1)O@?UBPA*_=_]L5HS6//[JIZL%V
MU_3`J\!_(/`1&',HF6A#I/TX6\W1]L@)CQZX:\,H*)-JS!^(QDM^+5QPZ__:
M4JJ!BWZ^!U\/EUZ_;D/D-$KQ^:2=PQD[3[^T[NA'\4;B3NB]A+_Q/AD?Y$`[
MM9)(^SRZ%H-!E?B.PE-?=?DZMQ1@>P+7I3<)!Z[\JW,0>@LW=SF8\;"=I[YL
M=#G6BZV`E\#RGYO5@&4ZMENVK&B,E&!ONB^]D;9J9:/"45AXP/PO/;,6(TZ.
M2SF\U9-X9&LC#7AD^(K]OUL%"Q"MCL$?A6]@<F%4#[\<`V`UFN[9L"XE-^QY
MQ>_X%$1G@^M&!03AJ;]:<+8+9\&%.X$$4F`P%]SP^!T/\CF*P`BH6SNV'&$Z
M/L?XS_%KE;#W._TK1N$,@DJ#(UO!MSCE?ZWDR'<!?H7V?S4\-7^YG-<U+G8N
MI[XR,B3MAU\9@Q>@J!,>A#5>.5SPKVLVTIO7"O$:D%+1:-C[K^LV^L/@F*SQ
M:F.C3CGL?EEQL.3NB-?X8^90,7AD5-Y]+;;6"\(3;[I\N3\<P?F%PQ@NO>G*
M<]T*0[+7-F!*%;@I)^^<OQX+DC?$H*4#$`ICUE9-Z+W?..HZA7#ARRY=Z]3&
MHDU>!3R/<.FZ@<%*H>9N9Z&"@2]X$MS5\/BS7[S2;XR("&D48,RTP[!@OG(8
MGIXQ\\3S9[[G@U]^V3+T"C(_[_J;#__]S+OV?@RLX6,[VL8=2_OVG3H5+`YG
MS(5?S%6_/'W?R=?T/7WLC,/A%_B?.?ER/L@/S-_WVJ>O\\_4OYY;\D?\H`2_
M?PW]?I[\?C;^'G[[ZO*KOKA1?WHVC@R_/9%_NV]AXK>O?/=W-BZF$>;IWR[8
M]XK$\]2X)QS_Y$GGV^,.[X#?OIQ&.*)83(SPTH<>?]T.^[/U.GSV>/_35W]-
M+T0V7ZZ=L>\ES\XX>6GBDQY\\J@+;SOO!7I>LY#D>L&^(U=^_S_K,UYT]C_2
M?^B72_8=<<K>UW_!?!];-%7J^UYXXDF]$XDU&(=1#W_!C<-GVK\MX[/FK'GB
IDG']6QIV_K[9#T0W;IPQ!W=!IKKDF1DS^Z[L>@C_W_\#&'O_U(PO`0#F
`
end
SHAR_EOF
echo 'gunzipping file tds.dvi' &&
gzip -d < _shargzi.tmp > 'tds.dvi' && rm -f _shargzi.tmp &&
$shar_touch -am 1111115295 'tds.dvi' &&
chmod 0666 'tds.dvi' ||
echo 'restore of tds.dvi failed'
shar_count="`wc -c < 'tds.dvi'`"
test 77708 -eq "$shar_count" ||
echo "tds.dvi: original size 77708, current size $shar_count"
fi
exit 0
================================================================================
From owner-twg-tds@shsu.edu Sat, 11 Nov 1995 13:08:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 11 Nov 95 20:04:09 WET
From: GOOSSENS@CERNVM.CERN.CH
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: hypertext specials
To: TWG-TDS@SHSU.edu
On Sat, 11 Nov 1995 13:11:14 -0500 K. Berry said:
>Should we put hypertext specials into tds.dvi?
>Is there any downside?
>
>
>Unrelated query: Does anyone have a real reference to ISO 9660 we can
>include? Are there other references we should include?
Just use WWW and point at the URL http://www.iso.ch/cate/cat.html
then type 9660, and take it from there (this is the official ISO server
in Geneva).
This is what you then get:
ISO 9660:1988
Information processing --
Volume and file structure of CD-ROM for information interchange
Edition: 1 (monolingual)
Number of pages: 31
Technical committee / subcommittee: JTC 1 / SC 15
ICS: 35.220.30
Descriptors: data processing, data storage devices, files,
information interchange, optical disks,
read-only memories, specifications
Greetings, Michel
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Nov 1995 03:09:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Nov 1995 09:05:09 GMT
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511130905.JAA13994@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: hypertext specials
References: <199511111811.AA28886@terminus.cs.umb.edu>
K. Berry writes:
> Should we put hypertext specials into tds.dvi?
which, the HyperTeX ones?
> Is there any downside?
sometimes. depends on the TDS macros, and which macro package you use
to interface to hypertex. in the worst case, you can get a different
behaviour when a \special occurs and when it doesnt. David can provide
chapter and verse on this, he had an example where a color special had
some side effect which Lamport was arguing about
s
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Nov 1995 04:18:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Nov 95 10:18:10 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9511131018.AA00968@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: hypertext specials
> Should we put hypertext specials into tds.dvi?
> which, the HyperTeX ones?
> Is there any downside?
> sometimes. depends on the TDS macros, and which macro package you use
> to interface to hypertex. in the worst case, you can get a different
> behaviour when a \special occurs and when it doesnt. David can provide
> chapter and verse on this, he had an example where a color special had
> some side effect which Lamport was arguing about
True, but probably hypertex specials are less troublesome than colour
ones in this regard as they are more likely to be in horizontal mode
(possibly:-)
Anyway for a particular document like this you can just look what
happens, if the spacing does not change, there is no need to worry
about it.
The main problem with adding such specials in a public document is
likely to be a flood of `reports' with problems with previewing the
thing. xdvi -hushspecials does not seem to be too well known....
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Nov 1995 05:09: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: <199511131108.MAA19387@spice.iti.informatik.th-darmstadt.de>
Subject: Re: tds version 0.103 available
To: TWG-TDS@SHSU.edu
Date: Mon, 13 Nov 1995 12:08:24 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> Sebastian (or someone), I hope you can get the draft on to CTAN quickly.
> I don't know how to make that happen.
As CTAN mirrors Darmstadt, it will appear there two days after you've
put it on ftp.cs.umb.edu. (The first night, it will be transferred to
DA; the 2nd to CTAN.) I can trigger a `by-hand-update' if that's not
quick enough.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Nov 1995 08:29:39 CDT
Sender: owner-twg-tds@SHSU.edu
From: Chee-Wai Yeung <cheewai@cs.ust.hk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511131428.WAA22890@cssu176.cs.ust.hk>
Subject: Some comments on TDS
To: twg-tds@shsu.edu
Date: Mon, 13 Nov 1995 22:28:21 +0800 (HKT)
CC: cheewai@cs.ust.hk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I am looking at the latest TDS draft. While I have structured my new setup
very closely resembles the TDS (basically using teTeX 0.33pl8 with some minor
adjustments), I have a concern about the usage of the *misc* directory for
single file packages. My concern lies in the fact that some of the single
file packages may *eventually* grow to become multiple files packages and may
also have the filenames changed for the newer versions. It is still possible
for tex maintainers to leave the older version of single files behind and just
put in newer versions of the package. It can result in tex still searches and
uses old versions (if misc comes before in the search path).
I agree that nesting a single file under a single directory will surely
increase the overall searching time/work/traffic, but to me putting everything
under a misc directory still defeats the idea of a directory structure that
eases maintenance.
One more thought about the draft. I don't think it is appropriate to specify a
reserved tmp directory under the tex hierarchy for dynamically-generated fonts.
I would suggest that this should be left for the TeX maintainer's own
discretion. Like in our env, the tex directory is not world writable and thus
auto-generated fonts will have to be placed somewhere else.
Please advise on my comments.
Thanks in advance,
Chee Wai
--
Chee-Wai Yeung
Assistant Computer Officer
Department of Computer Science
The Hong Kong University of Science and Technology
Clear Water Bay, Kowloon
Hong Kong
Voice: (852) 2358-7025
Fax: (852) 2358-1477
Email: cheewai@cs.ust.hk
PGP FingerPrint: 8E C3 DD 64 33 0A 7B 37
8B 89 82 77 92 2C 45 2F
Please comment.
Chee Wai
--
Chee-Wai Yeung
Assistant Computer Officer
Department of Computer Science
The Hong Kong University of Science and Technology
Clear Water Bay, Kowloon
Hong Kong
Voice: (852) 2358-7025
Fax: (852) 2358-1477
Email: cheewai@cs.ust.hk
PGP FingerPrint: 8E C3 DD 64 33 0A 7B 37
8B 89 82 77 92 2C 45 2F
--
Chee-Wai Yeung
Assistant Computer Officer
Department of Computer Science
The Hong Kong University of Science and Technology
Clear Water Bay, Kowloon
Hong Kong
Voice: (852) 2358-7025
Fax: (852) 2358-1477
Email: cheewai@cs.ust.hk
PGP FingerPrint: 8E C3 DD 64 33 0A 7B 37
8B 89 82 77 92 2C 45 2F
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Nov 1995 09:44:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Nov 1995 10:44:12 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511131544.AA01979@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu, cheewai@cs.ust.hk
Subject: Re: Some comments on TDS
under a misc directory still defeats the idea of a directory structure that
eases maintenance.
True, but I think we cannot mandate that everyone put every single file
in its own directory. If a particular TeX maintainer (you :-) or package
maintainer wishes to use a separate directory for each, that's perfectly
ok, and nothing in the TDS precludes this. I will add explicit text to
this effect.
One more thought about the draft. I don't think it is appropriate to specify a
reserved tmp directory under the tex hierarchy for dynamically-generated fonts.
Again, there's nothing that says you have to use tmp, or even that it
has to exist. It won't be in my next release, for example.
I am not opposed to removing it, but I see no harm in leaving it.
Thanks for your comments.
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Nov 1995 09:49:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Nov 1995 10:49:31 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511131549.AA02075@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: hypertext specials
The main problem with adding such specials in a public document is
likely to be a flood of `reports' with problems with previewing the
thing. xdvi -hushspecials does not seem to be too well known....
Well, that's the question. Is it worth putting in the specials for the
sake of those who will use them, vs. those who will complain about them.
I think I will try putting them in for the next draft, and see what the
reaction is.
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Nov 1995 09:50:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Nov 1995 10:50:33 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511131550.AA02105@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: tds version 0.103 available
As CTAN mirrors Darmstadt, it will appear there two days after you've
put it on ftp.cs.umb.edu. (The first night, it will be transferred to
DA; the 2nd to CTAN.) I can trigger a `by-hand-update' if that's not
quick enough.
The faster the better. People can get it from ftp.cs.umb.edu if they
need to get it earlier, I suppose. Thanks for the info.
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Nov 1995 09:52:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Nov 1995 10:51:41 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511131551.AA02110@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: hypertext specials
> Should we put hypertext specials into tds.dvi?
which, the HyperTeX ones?
Don't tell me there's more than one.
I thought there was only one set of specials.
(Zillions of macro packages, but only one special syntax.)
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 Nov 1995 10:52:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Nov 1995 16:47:40 GMT
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511131647.QAA25411@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: hypertext specials
References: <199511131551.AA02110@terminus.cs.umb.edu>
> Don't tell me there's more than one.
> I thought there was only one set of specials.
> (Zillions of macro packages, but only one special syntax.)
yes, but there may be different efefcts of the macro packages
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Nov 1995 04:11:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Nov 95 10:11:24 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9511141011.AA05867@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: tds version 0.103 available
* App. A.
Item 3, The Location of implementation-specific files....
I wonder if you should add an explicit
Note. This includes \TeX\ format (.fmt) files.
Or something...
* App. C.3
... have always been problematic and often ignored are placed...
^^^^
or
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 14 Nov 1995 08:44:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Nov 1995 09:44:33 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511141444.AA22031@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: tds version 0.103 available
Note. This includes \TeX\ format (.fmt) files.
Sure, sounds good. Thanks.
... have always been problematic and often ignored are placed...
Thanks.
================================================================================
From owner-twg-tds@shsu.edu Wed, 15 Nov 1995 19:35:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 15 Nov 1995 20:24:56 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511160124.AA24890@terminus.cs.umb.edu>
To: the-tex-community@cs.umb.edu
CC: twg-tds@shsu.edu
Subject: tex directory structure draft version 0.104 available
Draft revision 0.104 of the proposed standard TeX Directory Structure
(TDS) is available for public review. You can get it by anonymous ftp from
ftp.cs.umb.edu:/pub/tex/tds/tds.dvi (also tds.ps, etc.)
Also from:
ftp.th-darmstadt.de:/pub/tex/TDS/standard/
And shortly thereafter from any CTAN host in /tex-archive/tds/standard
-- ftp.dante.de, ftp.tex.ac.uk, ftp.shsu.edu, and their mirrors. finger
ctan at one of these hosts for a complete list of mirrors, etc.
The directory in darmstadt also has a subdirectory `papers' containing
other items that may be of interest.
We plan to fix any reported problems over the next few days, and then
submit this next week for the next issue of TUGboat.
Comments and suggestions are welcome. Please communicate them by email to
twg-tds@shsu.edu
or by paper mail to
Karl Berry / 135 Center Hill Road / Plymouth, MA 02360 / USA
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. It also suggests ways to
incorporate the rest of the TeX files into a single structure. 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.
-- the TUG Technical Working Group on a TeX Directory Structure (TWG-TDS)
Since the entire standard is only about 40K gzipped, I've attached it to
this message. (If you do not have GNU gzip/gunzip, you can get them from
prep.ai.mit.edu:/pub/gnu and mirrors, if you care.)
#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.1).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1995-11-15 20:06 EST by <karl@fosse>.
# Source directory was `/u/w/tds'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode name
# ------ ---------- ------------------------------------------
# 77596 -rw-rw-rw- tds.dvi
#
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
shar_touch=touch
else
shar_touch=:
echo
echo 'WARNING: not restoring timestamps. Consider getting and'
echo "installing GNU \`touch', distributed in GNU File Utilities..."
echo
fi
rm -f 1231235999 $$.touch
#
# ============= tds.dvi ==============
if test -f 'tds.dvi' && test X"$1" != X"-c"; then
echo 'x - skipping tds.dvi (file already exists)'
else
echo 'x - extracting tds.dvi (gzipped)'
sed 's/^X//' << 'SHAR_EOF' | uudecode &&
begin 600 _shargzi.tmp
M'XL(`!*+JC`"`^Q<"W!<U7E>[ZYE8FS74$@IV&!,II9!6FDE"_Q@(+*,'0^6
M;:R5[4G,E*/=L[LWOGOO<A^2EC:%:=,,CVC1]8&=&SE$9G!X&>BP::F;D@#%
MBGD$\NB03J?3XA:&$E.&4-'6I1#U__]S[NY=2<S0#N4QU<YXT.Z]]YS__[__
M??_#?T3G_=&!)Y=MB,`G]OIY*U)\[PK3=8JNLR*Y;EU7(IE,)+O6)]=U)6^#
M.^9%/L1G"CZ'HJ5(9.30^_=$(H>B5]*?A[>O'?&,:QZ<7++IK]]T(F=L>83^
MS4\7K.1E?]%=F7^9LTFS>-HQK9+H<RPW[;@6%UG3$JD1[_VO?&L\=K3UJK+7
MM"&W5VS6=&Z7Q\^$-?'C;6Q_=/(W]AZYYO3((J``_]&Z'=]/]6^IQ$[>O\>;
MFK_;M/9K1DYLL4RW*$Q#,%SXUPN]\>B=_;!PW+MPKYB-A.;4GM&'K"VMJ4U]
MJ\OX&3_O%T^/'(A\O>/EC,6R#FXP./:0Q2U;@V7;$\GV-=[I3YS:;OJ#/B_X
M`Z-]96Z)9%>+0)F6QR_8OF[$.^?$X<D%5[]]72FR$,A=&)#<7NTQBW<>?:5D
M:;F\<(B[IF76=ZI_DX:=X4NLOW]R\84K6\9JSS6E"W8IV7YT,=S@+7WP2!5V
M6=-2@1O7=8F!45A+.'E.S/9?,1Y=M0R8C;TRO%?TVT"RE$>B_,!2!`BHVCEV
M]!5N%30;N:G$,IL<4[@VAP7SD;19]$O>U,4/M@AF9/!B1K,=2QMP'0Z;:+;(
MF*-;EJ?=`C=\A\!CAE\21=<JPN^FS<7D.>]'5JT/$^]HR?:GAS0G#XKGQ>X^
M7#`K4U];E=$6I05S@`8OWGQ?%;8K'P9@B41U<R7F/ICE7,"V>6[Q@3%D-6?!
MC@[/M'BQKSU1M``#+<,S0!QS)(6&Z6AI+E@1*>(,)*"!+NBZ`.8T;B>\^,\G
MMCJX:/WI?<PNWTU;:_9*E*RB0/#AHL5M&VX!5K5"4=?@SR'`CUE`AW`$22M1
MOI<>3L'^H"VL+B0@F;9B_J`W=?UQINEL0.>DG2BWR=\V__2VXY'/@:#P7QPT
M9-VQGI0WM?Y(]W8O=G)#-6_:CFCNELP8&6U8;!)Y!@L".T`.!UPLG@7I&&F^
M.N$UM;^Q4^?,YHH=FR.,-TU>[W(;96TC'[:;RP5?I5!Y`2@3H`B3Y[Y\\O+A
M!O2<9/N$,Y1K=3+V%^V\[29XQA556&8`@2?4'::+8(6KF:6+C=P"$VM31"0[
MNU"F/5(<8"I?T@".72;+B#:Q4R\50-+Y%M';+=H[.B]MAQ_[^[H38@^*EHLA
MG^O`*U<8%DCU[$1Y_**U)Z29+?O#%W==&EF2S9)G0'.QDQW'>TS#X8:#;L1-
MC<@[EQ<N^L&N!L.RD^W/),O>JA/?W6HX%N*6`;<`HADY,&_?B^T=9>!A!"]7
MP5.6O2M./)#*<^3&,A''+)G>,7`=7E-U+]P9O?&]:J)<KBPX?K;\!E_$W%\?
MT5\CWIF[?UK'))GH($@`:C#)0<'!(E&KO7EO#]2>F8/B4P;>O=(8G^D@L]O"
M#6XQ'<RM^.!W.^OFUJ',K<\=0*,,XC;&1QN\>AKB7A["O1==^>]S4/^?P54'
MI$/9VB[TD1!BC1QZ0?1^CL6YUS3R^!P,GP*0.@FD;92`,!VMA64RFO2*L2=N
MGL/H$T=K30BM-836)A?RRC1S.,*U2.<&*W#;BYRZ=@ZMCQN9(#9U4FQ*809J
M%EMU/LC)EE08@MAC02D!,>OR>V[NJL>L3A6S>EG:,@'!;_QL#L'/H!Y<6D.T
M4P6]S:0(!N#NV*-?S<VA^IG&][(0OC)>;C>-UJS$EQHPYY^ZP[RB7B?J9LY,
MMC_;>U5J]/BR[LVCY74[MJ>\6'EM%;PUQ-6IPIQ&?"3(K`LA(V-C(/2=H]?_
M:$<?"'WDEW-5]J<?O"X";Z,W=>.O)YO^5AS:%5D`AK1`];@N>W0K7.KLJ,[H
M67I-_[QASI8^DY!?*G/96NL3G:GL[\9>>&H.TT\6J\6[?Y)LKZ>W:RB][7,+
M!8:Y;`DRV?1+VY+)>BJ[1J6RL^!)=3_4_,+&YZV2%^W]@SE\_^=XA%IAW81'
MOV%3FS^M+>(9S$.*&D]3F7'E[[Z;#+6BNQ4X.P$3TW+PE4)#Z3C_[>XY0#Y>
M,#OK8&Z4KQ/P[0R83>`#^_LUVW8)S;;MR62HT[E1H=F=,8N!?85?+$3+$W,I
MS\<"8KTULU$5?KVF16][3`.\74,C6C1VH?_IQ3F+^]^(6=9?5PTS-!>4M*;L
MIA9N6FM.,4VM9JBW'GCF_[.PI1"[Z@ZG1SH<6S7D+2Z80%WE#KYLI;?5HG0E
M.I[C9R3KS8UJ3[A=12]6@IF(T6%S3IT_>8SKC8J>F8VH1L#VS9\#[-,*7><'
M5T8A"+T%=SP\A^%'(_VU=>>XB9SC+JXS1R;5M7$92JPOUY+K:C=?1??BX`B-
M/%&?'^_:LXSN*H^?'XF,'(B\?MWA*I1*W\21N6CDPWTN#HW,X=#7^'O9#/SG
M0.2Q+]Y556-F_?V0[HG!49S/JH^:X=07T#8>CT1OB42RV7F'(Q&<4@L&[U[%
M!?&.X^#-$TWORCF63(^:8RF/G_7FO]#UF=V62FSW*`XGB>+8EN4FQ(DAP:VL
MJ[=XL=TO+^;#&A46NT<=42KZW(9X0J]]=X_:)=OA!1P;R]0FT$S79D;&QID8
MN-F$*"Z89;I&AC+9(2I5]$S"B[O#6YWZK!=.3/WK8WP80GN!ZR5)BJQI<`9-
M6"X.+1EB4+,<E^EP!\X!F;"%Q9`<(6FQ$U[3UI,[#"Y<(PO/NP;@+6PMPP4_
M'3(V-8ID9BLQX\`,0:RR!;&KZ9I#`U$@%351AN&4ILI@,2,'1.W#R3W?62F&
M?.:7<.1),W`"2A>:`]S]X$:<`J,9+8O;K@Y:AP-H!9SW"H:R-(=3L,XSV&P0
MF<AHIZ-2^DZP&#Q%(V8Y'LP[/;!DV%=39KP2?;^I:&E8?=/LW9B<O:.J@8;T
M_)JC(59,D>%V&I3:Q]P`-C`RS,K,,C(XZWPD5B'5U>L5]:P2^\)M]30XKP$0
M5AJ4)R]*>`F'`@OT`JRE$DOT9DV:^K+51.$7;D-M,%&N(DCU?)7H:4:&JSDW
M$L5,\K#=#C)F7^^V:]1$W_W[`J-,!S7/8J#U::9PI%%&+[;HWV;.+C+=-H-)
M.%MB:4LPTZ8<9K08#3WB@)WM!*->L],4#`\2JV8E]LV?L$!=:OX]X<T_9\U6
MAS2#LC-N("I:SL#Q11-(,*W]-!D(JE2@231N&77UQJ<-4606\.?JS`*^QAY&
MOM3FJ0J.RU%%8J`$#D;?^ND>(8=B?1H"]9M3>P"G+:N]Z%N/$0FZQ@<%MWW-
M\37;!P,&J_/!9+GE]QO:,&P1/_]8;U_KIAU]U19_#P`$=-K^L>TI^'IL1U];
M1[5%;0])Y#&\JQ*_M8AV>VQW;U^U-L27-U%'N30JEBEH!LZ5,M`@FZP\P\GM
MZ637Y$,&?%`2D<4^$]Y`@W]66F-Z(.OI=8*MZN:9"`WAN"'#ZEJ:1Z#_#6.;
M\<DC,\<V-1PU-7!"=`!-#`D"[9Y=#Y1/;&!.(+<"[9V8P(>5;U1<%"T.B))7
M_>.3,]>L3=\B?[\O9625'"PY031FH6$,U#4,\IJ*$%"IFA*2/8(N!`Z(C`/J
MK?AI%X#Z@NN\]7=`,POHS\@N\EPOSL*B2P/%BZ1+URSE`9675XH*N^28H=U`
M,[F:LBP:DE6[U!36,)V6@['OC>55Y`%-M%I\=C!VZ`D'@J\%6*_WYI_V;;CD
M&]@(LT%2>LEGM@T8^?O!)0^!G\QQW\SZ0)`//E:4?+00&W]B_E"@_C-8"01!
M-(-M_>);6R$R_'AS"01CNL`2Q1%6@(#`@$\-D*>!7>4%BI:9LQ@QB_:/P((/
M0F;5."Y('XSG9#0-N$$,P(?4EO7T@ZI=0S3,]B;*X^?>M$U-JUY`<ZW!Q+N:
M:WV.YE`[#Z^@.=23]X?G4"=7R/G6R<[P?.OSX+[+XTO?;E=9`#P7__RU,^97
MXY^_I"IC!=@'1L(;I/=3>)*-B=GLJ]62R96PS:Q#4(+X#L(61986^VGL&9RL
MCZ;OPY6:KU1Q#L6`Q@&BP#%T-5)L0^Y10F]8`$1`@AKF$T78!T4-)JP5?/B5
M&1S2#KUA"+L;C;<2_<Y9BRQPVSF=@:Q;O.A?_:6F--SF:!TJNHL>L!^+Y[EA
M:X/^;';=;:7]/%W;SAU?>NGFVI!V%9SI7:^QX!Y;0/JT2`^<5#,#2DZUX$2V
MLYI\=RU&H_Q!11:^"-8M?Y&SZT14FME@E?%=WT]A^%%(U0?#HZ?.#J"BF?0L
M&J'L15$V@</TDH"P`Z$C`[B#$KU$%$4/<@^DM]6H1-^X.PM1%(B+3#AJ?SNL
M*@>C;WRC2CX^H,BOHL6`L[[>E<X3L`,\0?L7:VHEB'HE'TR+G#%`(+AN\R&9
M7ADB%,?J7AAT"3*JIFW_):M>ZV!L\O$&AKSX>?W2Z%7^)!P?<U6T)W(!&)M]
MS%,=G^*=#]Y2#&@0<7W<U`0?(3TD!#W-V:`H`!6KQ':\@=KHQ:Z9I\D<RF)R
MCH[1F+O-<Q;/88:`>XAF/HC'*@P$1(/@3+^N#GRT\L)@#WY@#Q1:<!E0"E@E
MB*+$.Z!/^^BE"LT<8;S",-<B@K0+SS&$/,5S-`@-/@%*ET%N4+0(63Q@&EOZ
MD$J!QD)%*+!W?F[?1%MU)7)(V7R()J'>)U"(\4U#/F-O\&*K;L=(QF73CA:9
M</AP(=L&R9YC5T%SO_QJJHZH%G2F!"85J!7A:6V\)FT`A)+A>+9!Z@3Z=]F[
MPK(-'PVU`D/Z&GMIZ;3T3O'VSM2^L#D?1'->*7)RX!@TM,"98<^(YGX0RL%>
MWIF"=%!W,]CBC9VZ:]H$R.C:5ZHM8F+3[JT>T`!5G*9JMP!-T%)(1`$L,CWN
MI!,M9.)?!87\@"Q"11:H)6RN9^L9"OCZ5T\,872"O'U?6)-6!O;3F-]BF@F+
M`*HNGLX`5H$)B*>C_P#ZR,D/!7Z;-+A^T"?3,MU%@RQO^"&E[_;&`I-9+D,K
M$G02!6T','_^]I1R8T\#DUX\>VZ5C8AM(^/O3W:->.]ELX]V0RD;>>&665[[
MS[OQO8Z1\7DW3DTN//W0P!7A(QH%+=G^9ROAR9;UB6J8<:)J**^!ZZ4C-A"W
M?$AJ*"#;;A%4LU4QHC(Z-;/,&@65UB&A"`0MTU6\"ZR!(,J:NF["TT/H6&$#
M"D\`41$V1E7&,V"P#)K<>NPCT#(3`#LJ&5#]I4-W5+?);V0%4.D"=>DQK)=`
M>A-935D9>71?.2_N$*KJZY"%"]2^)FK[',T_;>%A*@Z1,2T@R<2"/?+D5XYJ
ML/.7;WZBNHNN</R]$G]X^?3=X?FB!\^S]'X0J'RRVN+-CRW1J`2#R$+Q1`I)
MQ2XC9\M;IM.+TDZ>N%<#I='2*KVA"IR1^QN`V@SL>;_@6,[*9@I]J*/2498?
MZJK$/EQ39=6U'T-7I8.Z*NJ80GG\[*ZA((^2?LWFU&<)*FPL<VPJ5^`WL&8L
M:-`%@.0@3\[1J;(@D(HJOM!`3_ZJHSQYA\KN\-A#7UGY^SL?LO#DP\G[;<Z$
ME48(RN-GW+19$M++4+LA5N2=F?XD'.NQ\C'!MT)\@@!D^&Y!1D59<#5X`\T(
M@E8HY$"V7M@0]OP^K%SOY$RD-O>B0&@H#O.*-BR`(-K/1E41Q$#5?/F!)4]>
M%#H]=_0?07`FV`_:5[T%0A59'CL$0"WZ("S,,+5#TMD'EF/@\-:>D`$\HRU)
M4RJ.S1`'3T`:02XZ!,E@)5X]2Q*.N3\UMJ@3A-<:(C<J_^=ZZ&>ZW^`R;!+R
M`JKL#(D14AL\@FKPH;#NU6-BR+>^\4M,.%[X<7U-&]1$S\@V`5"+]1TDR,@H
M4`)DU;,([#(5Z"!J!LJ8O[M$GFRD(@X<HNE:4D+<LO``8U;M+M-TDRIF2Q10
M*1H7Q@:6JDN0MSS#'4*PR9((]=A&WX4.+!2KH,:!)8&S[EX'(]?E5Q]+[1G]
MX;HM7NSRJZI9#BAP)IU00T[4P#:>VJSG(O4#0%1*QC5S(Y`BZZVTF0L*3A8T
M^O@PSM1KD(A6HC\_7X?@1HX,M#&DT`0;;48O<Y$@1,X/4>$:TD:`B@&LE..;
M%Z;D*S;XES%OX(;L>(85I-XHT_Z3:O\"DZJDV?E0OQ`6^Y/O=9.#E'DB%)BR
MM,?4&*1GK@SHIFJ%6H@-Y"M*H;Q`#0Q:"LS)DV,J2+_0V)J%8,FP1X9FI)M&
MKD60\EB+35]&.(!TVF%5&YBC(ZLVGL(,^E%!M06:UG(P_N>G:=E*O'CU=`&C
ME.I0".0'5-Y7$L`-0?]0@X-&J+28!JU07&(*HU@DI,`Q8$"/WKD+K<*A>(9G
M177\8^8&_F"-O30VDH->8O)'*=FF"('.(#$M\%8JW@OH;!6@D`'%7_@]LJ56
M<.T&2(5LQ&*R')E_R=>#.H#L8UJ#4_64@V/'4IZU+G*0VV9+H6Y!2):5^(Z7
M*#M7FHJ])<O%(`VVYRU@FW?4FH4B.+X<7,=$95'.#>B,EQW-"5C&HDVSZNT)
MS/8UE-Q!#&ZADA[<O2'+)IV3-?@#K@5I0DT5[$KTOM>9:GM#R?V<+P,=F?[!
MZ'V/5X$,3*>#\]JR>Q54W^@E*2SZ5463NFUFJV_6/D20[,%MD%]7HIEO8Q8H
M7R=(66/O`!^EHADT$F<Z_&D3'6-RH@,TX\);>\DQPF4-DG'53([>\=0,6`L^
M;!ALS_8C(Y78F<MA`]F9QV8&EQC[`<)LEOXVE`D7W#YKD4')]YG+9=L-A0;I
M/%ADK<"H3Z.@WY2]4Q8TN:CU2D-EE=@]M];YI=<K/.U:2OAZ*4A2R%&&A:,%
M'0`@N[X`Q3C=]$WZ'R]D:_U%9E2BK_;7H@7(<MORYAW4\Y?M&UAJUG$:)7R0
M\KMOA1*-&I4^;W7,5C`\/)(#MBZ?\O.\5G))5UN)_^;S%`.E/=<.^B=6>TT/
M7ZQZTMQ(0WRD*%H#%/O1@%/=1&>CTB<GW<S";;T9HUM!@+>"#HNU6O[_$D"R
MY*(;:KMG'Z$>7.S9T2J5Z%SV@FKZ`I&P)/5_F%8)+B`A@7#0\80(A`#RVK$!
M%22G\3JM,`*NJ38),4X)EA6X-WHQ!FZJ&1LW?2KAW9CH6#TM=Y5=B%TFI*[J
MB.C)^X,CHJ&,%8OV7U6G-23NI*(]_ENW#`F.E^T\!1-Z0U)[$P.ZYLAV9>Q7
MMU;KN,B7D-?)-D1UE6A&(>V;F14B%H&!50,I/!LRM96K05MWK%=U8/3-A\@A
M`GF(82T44\$FFU?U=B6&[&@^:&6H*$-W*I6HDUM+`]TB"/X("+Y!98`$ZSEP
MY\=V]HBJP56V9NVG/L)36>R$]1\)DG"J_?TT^G*_P(H^=;5T,X?O@/R@)^'7
M.R?DLP+7X)+/H*H8:M'4^FJ@E7VRCQ5XO5CK"LKD+CI3)\!JW6`)8HTQTY!)
MH7P%@>]:(/]IS7!05WRI-T8=O3AK"MXVR*19M6(ENF8M2<4-[]^PJ/9*8X,7
M^]DCL`-UD52H`XD\_LY$FVM;;;H)'+>!VE@<VS+UWQJ_M>G:@/2H'JP^T0:6
MJS;$)B:*0A5O)!I32_,&4XVZKQ&F4M5$%7LR(#NP.=,&;TC&B;X)BD6P3&9C
M7\"+1Y=",/COXMX$0(ZZS!M.ICL'&$$!%?'B4F9PIB>3A`02!287##G)P;%$
MI::[>J9(=U?;U9W,P+JNBH`<,45!4V94X&67%3Q6FU7A`SQ>,@OJJJOLLHOK
M8A`OT'47XP&NF.^Y_D=5]R3#MXO?^ZZ:Z:[^5]7_>,[?\WMJ[LMAFCCBA!%6
M$X0V$X@1!8RM!'9>D4\A?DQG*K\)<SN5B#4B_'3J;%2W%;^ZZ@>X\V\VJF4/
MJI8P4_P.?AZI$INX!7-:_`[5;DQ9I]$;832KA\)9(3S0948!=D`9K%_,X2PZ
M?N*-D;<,0I/%%CEQ%)D#KR\1GP:;!?4&3%6%W!^5_DP;5]H*"3/C]^.N:V;&
M)\7PQL41>AKCS)#70\.B(<<R9?S^EN2SX]%XW,K%=R<#GN]_DE2?L3*-XL/0
M476DYA20CB7[[H=53(S7L`C+C':P.P)JNPQBK3T0LM`.A&2G%P@Y_9Z7/A#R
M=2HN!_&^%L4[%9<_\PE=7+[KUF,^6C4)ILS91_*,GGU8*^]46)?M4?:M-JF4
MEPSV_NZD5XO>*NM`)]H&)@;<+U(W.Q$F]K+/KA(/DCTLLL!T*$([^,U,Z^TD
MHIQ\WJ\52(#[DKVDJ%XE%<,#)_J:]R*,A(<EJ(=VW-`A`.4(FJ7B5TI28W^B
ML@`J&*\_<D\=!0$[R72^\Z0KE+ML;>"#IWOQ:FL'@NQ[R[\Z%09.Z&?#\Z]\
M(GFV9M=/OK]-/UN$3Q6E'VDG44`I'047%,B:XAQ]08ECF76=O<;%L*+$RM%6
M:1R+8DI%41];HIWS2(<<'ELB\K7LPG/!'<$QQ=.56N2`$]C6#;7(I:!9..O7
MI>5HYHXZG$TP6L.KX6:GP.<R-(<IFR7>*T)OE#_NPFGV40GMYMQ^*JG(X=P;
MPC>]]@,#.3PF`_ON')SHNKBF4NX86[BXI4,45!.#\6@VPS$BS=Z,AH!(5']9
MV/7I*"%0NJZ?;6NH1GD87E7"J2W,(6Z_3](G.V[FXUN/QO%3D)OKG"!P&'_3
M0(A6@)_#$B[W@SJ(Q3![TM-*!JG]H\QJL4O(8Y(4*\^QNK4%[@$/`!W"LF1M
MW$+LT+Q%,/4Y,U,+]$R%7?5/:KW6[*K_"-5F`6PTULFG$#:"(Q1.%0.E-0]G
MD0W[WHFNVQ])A!H]MBSN'7V(D^WAC%_]*P:KX\XQ;'D#])NZUN.O*",`KQ/.
M//J&>[VH97LVL,GR#6+YDKLD@OX2X,5@P7$+MNBJC/7G@YL*9CUE?1-*7.Z-
M[XL;D5\X:C%T!%6!9DLCI067J@-SX=O2YJ;]8[*EG()3Q<-@>_1TM$$M7?@%
M,>@HLU!R*B,-F))<`6:Z)=X9W`SMJNQK+U_N,`0H'5*$&TU*?B/(Y8LCZL'=
M2'V:",_DPME?6K*UPH`E]#$33R:WQ.=K=MVR7O*AJ3M*V*^&+&05M02)$%`Z
M^K>@NF54?!3"S`6)O*62?B6U$N;A).*9!\M,Q[KIH1*BEZ83AT0F-3N6A+&I
MFDL$:]HH!&71[*IZRFAT&(>GGL&29VCUC,.F\.C1)`^IGJ*WV?7Q!6YN)`>V
MZL8U.&!+(>>(:`VG9'*=L]W=XEZT<8TR6-F&XI?R1KP*#4=QZS`S]L.5.[QJ
M0$;(H*@,@C_4V?!Q4T\@D\R9>P&[*!%XPK[;[CU2#G9+2UB-([1]`ED^6DJ3
MXP!#M(B6']@"$8(0RV`?12,E?YBF`O-;&%#JP0Q\V_W8J')*H-+A!25.)/-[
MT%O:\B,B5%MDYZG[Z^5J:XI;2F+'9^09`ZSLH>%\^8UZB7.@)`=9"4WU!IR@
M@64B^:M,#H]VKS'^N]E(''6J@7K>_AU.#;P5.QA"G_4'5=\O2<*]1^W%]1S2
M1_/%+_%>)KR%A#4M,:M"$:00P8M_PROW:C-O$9EY%BO-,Y]0I866F;>2(1>$
MMLG<6*<MI':J3@KPEG/'X'1Q0)_P(YD;"TJ)]YRL)&K<@G/%LQC@@`V[&M+H
M5;\MAU%[/]][CV+"-'>7'`+9\QPDMJ:CB+`UD)KCWPQ\"Q5`F">TFG1D%DZ\
M!]M3P7?G82SN+V:!O^))L!==5(^M&*]NN1B4&G]W0_(C8?;GCYWKQSMC<@_A
MQM?,U^"KS'M^KX*>08>PL:_]]2I#4^L*44&::K=H*G<L[U:M5'1J&Z['%6QV
MU88ZHB2MY`YAKF#%5`J$W@%-6)A/U\&Y',%8'+QX+:CK4%PJ5`8WD=.F](X[
MULR,/4W((?D&_KM?O+Y6[T3F?02&0CM3;D90[Z)U=0OLX&OO\7)NKE=A?@CD
MW/XZ`LE3&@!WUO@$8:[18F%DT'`T3L!!W#"QK-&['^Z6`%>\,#<0*],`\6M>
M$!<;-3S!N1Y1W':RZZ&C*[`;/WV\)$[Y`1C4O$=`S?2LM`\Y@"?1&/JQE99W
MK("GWKZT&'WR/B#K.1;PCF=`N9OYB5HFC4`*RQ>LM9W.7'ADTCLA3_N.Z
MJS93,$%MNCTJR&ZBVG`_$!QX-,'!F,A\O%M>S4)K1_487RL.JC?;82:\UV??
M`9?'(KSB'9X3[P0[HAJYM9C55Q##]VPTJ->KZ?(8SA%WV,SKG`HM:=<?KBJB
MM\0KBL<[EB5.K&S<3<JUF3EB:))X>'/5[:V>7IAMO<2("8O-VB^`_Q]FM_0-
M:ER#S-#-:H;('B9P65UM`QP,`Y\-\!CQT\#::8+ICF'_QW#,14"W!P`6V0&`
M6=,+``P]\)(&`#C35[+K,_>89`P&F+=7?(3;%N'(@FU5&%<BD.8`U'Z58\@$
M7/LKY2>BZ:0\-0FG%I36(9G)"<22MUVE)V`[$T*N8<(#%2/VEG92OBSU,@\?
MYQ?#[*XE;2P^!UYH6:*/-'M5S'/.ZWOULE.-E#76P^>BHVPT<`BX,9::_.K9
M%#!N]GE[$,3/50H@-++'7:2PGPX&W\$(*JM@`?KLG(@%E<W8.YQ@!*PV$`ZT
M3M4(R/Y$%8F>VD3F,\?E\4@@2B(H$<]T26T_5*:\)<D=BR>KC4J^GBL7,>JW
M=\TDV,).I41_H],?!WZ,3N2L/W\-^RBQKAO`);$\"K([8(F*8!Q3NDM;(*J$
MAK"JHE!).Y/3!+*?7U)9=ARF\!,3+&R_#,A92("<+>$?'UVDN=FR]_0K;K:)
M!U#([;KUU0]=;P&>#UML.WQL7)%-+3&%FD\`?T0@<E25T[!@OX0S=IU^F5]+
MH2`/#CN!A;[ALL$P>]A<M*^2J2F<J+)79Q.[44'X"&RT!+)3!U(&2YC''1EM
M=CD_,'P`SNTMSG<@O@],8HPLH&'='F'CH(JD3&EU?!,XU7*,=50L@EQ9.>12
MSGI=GH)%S>Q7;K)B.9255=F*@(T\SKVK4!F?:=8]M**V_0U6M($NJ]"IJ9N@
M1-K[;INRX@9-1U`LU[=<I>S(<&,/PV-XD($HHDV*L1]*UYM8LDE3M#^`7Y/0
MK5+N38M'D_"_M.]P8I)P!\YI2,X1!!^8<(DT'^;8IOBI;>PJ,YH]#A"!%K(0
M`T-@G]]V6XM@RB#3.U8D1<J*B<"*Z3&(P4F21##"F<?O42,(\UE?`@%F_7Z!
M_?NR6W=P#!ABW;Y0#=%=,0QJ/=%43&GVH`O3@U;](#5H&_=7AV$6V<,,>\,\
M/2LNO44-<O`\1MN[GF:/5_#SR;G&-&X*9\RVDC7"8GL$1F!93]2U[2?\&=I>
M;WR.(W,,B@AT(-+&FBM`L/PJE8GHVM5DN3R\(*\N42:B+P4FHH+XV_Z=>&FK
MAR*ZT\+F1I.%.MJ5ZO[:$QM!)%-J=-Q`8^*/PC/(^S>SC_^B12]*!/!44%7T
M13`(@A<5/>ISD8<6N(6.`TG+*>'2R\)9'UWB*6.5XTG-S.SOX(`*32;`$PIN
MD*MH^X6P&!=.2)F!E>=Y]0<G09!YE1R9UG9F?ACCY6!@DUB3^R:FH@7*_1^_
M)G"@9O;*'[,D%Q'E1-L$G`=S<***8(#`X.B1?FZJ#445&>.4@7+6<4T294VV
MD'LC])LD4V;6!+TK>OS^82?`G"C8-@C&8KD(UUDB(H$I]I+<-3/VY@E0[#]U
M%1^$8_ZS@Q78+=.&Z<[S;YITR[@30'*>\)U)V7,84L,?BV8/9!<@[)%<8@R,
M*@]`++!F]FM_77!=#!P'#0X268Z^C=N(_$X9E910G_NM+U!K$969J>B)UEL'
M]F%A(ON7SS*!!E>FP1W4K:*Z<FRRW_@7<-FBT1A<"/1ZP#0ML675C?.?P_A,
MJX>L_;);!H\X+C3`@E!I7;A9MVRN8KG>ZFG.FO7-$9^,)5"[[WX&]ZEH',(,
MMM&B[$281EL4.!<>]H'<9D9IJ+E4R)3EN85V($E0OR!CIEAR#G8%B:U1);RY
M'XW4(J>L=\:&RG_1SLC^O`JVA`=^(F(?VAZ.A(X<69O6Q;*_BYV646DFXXQ2
M]5TS>^L<:]?-F?76R7*QWNJ=R#X;3!8P^`F2*)R[_M^')`<4*XNOU1MK1:;^
MC?JGA1BW0J04B61!+#6-+I\=[XO+#GAV7%L4X#Z!S4"&$1;X<5TB@C.PG*O-
MSSO-]O-F3\_/N_C!/T&B=Z%@T)G&>->MQ]QX7CN!P`2G]I_\,->6"FS9T=$U
M"C.3E&G#\%(,(IO]F*ZA4B0"J3(<#C/PIDDDB$VBUP1MDI4;E_)O3\'[HY5L
M:]0.1CO)73AEB#'%J%W@%AMH4DYNPS/;ZB.YDWR&7$]2ZJ.P326G)OL[Y:8F
M^\&^'WJS.5+V3V"-AB8.@*YLSAKX2T?-`'E+UDZ?>^H;6'2`?)WUB6LGX2S0
MIJ:][56*/OY3J>+P\-GG+A_'\>#<[*8@#@%MY?%3#]#,ON>KK42Z!9;JX>]S
MS,J"Z'$DGU:ZY($[P[ZRE6U.P*Q)V@JR185X7#"#:2XUFXV*]4A@K9DY]B,<
M'#WVVI8C";D@61.M!7ED*154<YY&&V)=+M9=VPCMB*-!8>;D+Q/'-\^:2AJN
MHKGM:7:]]S4&(,[;&6XF0Y>D8AULL+N>E8PY@P!56E5MWP9,R+34D]Q>8<_^
MTTH&UJ4*8;<-T5<OJ]Z2$+46P(!R/NG'[Y!$57(.7@FSRUAU[43#R.;PS65.
M`:$]"CH]1=0XL%#)N%.PIF$1(HP]2QS4'`)3P(UWQI@TXK93.&PY<DR<%H1)
M,WOFA]O>E=Q'E<#FIX>=.?8$A8U@$M#AE,<LLY$GSA[F:TS&7N[C#P=Y<)M5
M8:)7HV>AT"N/G=B'6[>R)\;Y7K3H`I,F9MQ\:DJC%H6O5!A^B0I(G0/R0@>\
MPUE'?(6TYA?&+`W(R&@N0@$I%)$0Q@<CA4_U,+C#U*(;L8"OAN-70'3EQ/AZ
M^XV39-X&]7$4!=F1?>>H1`>W^:I3T<V2V[D6DL[BN-JY]"3P%('4)-?=$8:H
M4=PID/MAG.NB]VS$(Q-U!ER2PR1V<\WELFZQP:W=*O,>9J\X4^$5N(0XAJT3
MU!FWXW-GJW,DI9S9^TUT'SAN;J:,TS<819OJL;K%ZP"+*Y$8U"8S6*MA9M_=
M)";4Q-;=H(X60XXR&5NW<B;#<A!,T6;;H@L0D=WM6H?T,&FQS1:\=D%NH=F$
M-V-"!O;[HT<B^C-[U1>)+6$\U@?AT2.9PR/OUU#N(@J4SB3:I_68"M`I()[:
MI[&1]62IPB45.ZAWW0&U72,+;=M-_@IL#K\&<P?[:M:K]FY(IQD4RD;71YE"
MFWB4!1>%C)34U=D$S&MD3_DOOV))T5PX^^F/7(A@,89%W#NHEW3=KO"PUURW
MN=77#E*<R&Z[)0$B(?M/:<M8Z=!8ZN4'S.&DY4V$9Z0T:8]^B=U4+=2+GF#>
M0>DQK6?";4WX_3H%2<TF35K9::,!`R.W_0;M@JY?^)WBCBE(1=IBR+Y]"^YP
M,!!W(N1SYF63P\ZP6R*9L/X?#:CE%UM2H!8CXHR]T/9TJ+P/(O#8^YS(+KZ2
MI-UAE^/`^&$2=8%E:@Z'%F1;QQJ]*C%$S3<59OOF3`ZM']JRZJ*HM5,V+=P+
MS37*BWWZ;T2(L5,TZ_('TM[]1.:A^Y7?K8`,TPN()#@(>$^5,$2B7#MX#@&8
M4/U^HZ;4YW##*Y$#A'`)-]`&<VR;RS0>S4[2#NLH5D;'J_#RF#OM^4MRS=]X
M'8("Z5/VNZK$C00.:TRR+):?D(*`Q7_7E5LH0X/2DUAAJ@)/H;DF03K,Q%5X
M.Y[Q%LFJ(?(IR]B?$`R-AKC%:4`XG7[._]-@5N1="Q:C<=O>SRNC]L?W6[^;
MWF_M$_21Y3+VQE;F=%4E[U2#!L<Q-\;P<)LIQQBA(THQM\IO5%"=0S'R:A@A
MQD#$1.:LNRH4$L?P>`-D,WIYF,'D;![(5?;VF"7),>5#DE#91O[EB7#(5AQH
MVSHQ3D<0<S[_'#2"'=@C)SW`63*5^1@IH1M"C$,-$H=8T`-O.(9&I%!G57C2
M/$+X.6<-AIF3_K;L8G4?V)-EAJ&/$K.0W(JFK9E]P_-BL9$DT_$-_**S\A8K
MBC:5YH`S!#C=0S11;@V>N0AZ:.,)=,[@.W>=LQT9?>3^A!</LT,_1!GV[W?2
M[<>1%$X(X@+L/9I@I&GE(G#<TQLL[/I-\^![3&Y("Z1@$M/:;(?4T<)$U19R
MZ:RYV\8O>P%:?5T/+Z=(\!T/IFMNE9\4>$PXIIE#N(AJ\<V#E12_5,JQD<IH
M#/#59!H$^9#=?V2%;`:8#7AF,!0BA8G'/<WRRB[WBO'J"NU\?H@^>(@X2>GC
MD$WAJ5MA(KWF=DYJ+[:#'7.F%^P8^>N7-JD-V@R$6/:*%Q3ECN2@M=\M2T&!
M,I)>]H+09D"6C8H//MX8,46-IWVT7I,/QL5M9M8]@S^E;!VG0R5;A.DR+?ZU
MD38ASD3*(<]L*&*0"<M^X<GTU3$&%TC9PF;QUQN%IP*!HOBZOG.QY?4VNSY[
M\8A8Z,G8L003U/^R3Q&C%=_A(KROA?31/TA@RQ9*A=CJW9^J41[*P,F$V9;)
MFR[=]Z+C25WA7CN>%(_3&BF""OJ^B+Y$I(#`]!&NH;JF"$N@J,E46`FQF-K2
M/V<UZW@6.%8^4`.\*<1><.$`ELQJ5HAT@V5#+ADT8APB+&!]O$H\'A,2(FH#
M+$_*51$^)F@DBB,1D$(;C?`M&F;&8GS[(]]J&>X=UNXTE^0^XERP7*%,9V2[
MN'%'!S=Y`^WBWMXNZ9QBV<C1P8*O`'<,@"J[8#[E$0@RC\]URC\NFM\JL:U^
M*F`,CA1UN'%UN_EM5=&-D!EVJ%^JK(WZM>`]3-YMJJ1F+[%\<(56S"7N@91'
M=;Q1W9Z;3K@U>Y*F?EY8#'?`&LBL[@`O;D!N&N7-6#QT?IP=UFP+QZIZ!HU$
M0#A_T,S>^2$B$P(M__O'Q']G=9T*]UE9<$0ZU#GP)#R(*L>G8S7=L.!$?J,B
MDB8FP`18!OX#8K/@%11\U9<>YCT)UREY;.`EUS]^,OE-/SW:$5"H%"(*1$ZD
M`F?C;)=I*>QCV+JX)[I>.`'=1@RK5AO#)2]/CM.Z.7!N0AB8?:>?_,Z<GB0P
M)@'2[%"+,+7K1#<-N_9N)HOAMJ/X4`HNW*Z-49"!P3*>%U`OZS`;B!8B6C";
MR93QW#H5M;&.Z>"M\KY1+@P\M!):_YL!C?8SRS.*977;R,8?OP1I/V&]0>"K
M5Z0(O-J7HJ?);)2IA#W%<=GN@1ZB-'`#BDE;Y@G7>S6[!K]G13(<)DN`)1[;
M+_![G'.J;*SAM=T+>ABM[D0C:"39O#E:D.J`,HPBFP8WR*M^/517MA%KV&;7
M#>?C"<C["J%"&%?0$-C5/I+W;GMKN`.,_?E-%41MU[@5N@0+82*0*\WP8RJ'
M!L5'G4\0SW!4\,LZT)"6)N4J>NCN^\A#[S_**E3H,V4":OY[8R=(<^*E^4'"
MV7]\@:I\*:*H<ZRX#BP35%L-15FAXG@%7\L(]-"ZX?C'_,9M2%:UEYF@."$&
ME$(E;:DUXOH[[R"-^/@EI)BE-MNQ=",:`1$1?X[;PF#6^*.3>9+;O]\VZ39*
M;HVR+1Z<6USI62\\CJ(`QN6$Q>-G3%<4='C.0T13\F609=M:W8(YU`()-L@+
MEZA2G26GF<-2<.=)OO\AA1V$*<C=CS;-EN:!90^(6A??#L[A\M]=$/FE1AG>
M*'?_JE;G\X_II6;7?<]T?)+'9_"38";(/(@EKRCP-;UPBRQR6\#H?SG.BD7O
M?ED*P"OHR+A1(K:>-MM`D??S*_?GR_T,*H;/C`ULKD1=W4]RH;]1]ZN>`S^L
MUW+5HN+H$/,7),ZE7](%)UJVD95*'O@>M45I[[*M`7;LW8IG]J'50B<'DJ;U
ME+(PUCRDYO.;?61AU(,PL^`'+:1SP#L.5@G]AP2T/>VNVQ+;=9L[/==M[,:7
M/D_]"&*T!W:%2RH_7$V!!$HBLIT'GL71G[ZFW;/(_-^K+$-0<=]$Q.MJ<2,A
MB#M/XL7&8!"M`R7_&=J<Q*@B`I%)\^:YA:4F10T*J=GU-Q3S-&N(8J?@[O#0
MY*!JAK#KZV>7_;C@]@@F1J2A*'PL0D:A*W'%96'7DQ743$)/KJ"V$CWA5P3K
M[<C']M(S\!28FL9F]O!K-46=QB(O^1=#!GSX)2WM3@5*R=&A-53U\@+H/S$P
MJIO>(.B!B<,3KZM6Q&%KF@[*A'/%D[A"-NYDV8=?YA`;2B0C@U4IFJ!-27.B
MLZ$@/NA&#!%/'MZ/?+I:X[L3K9VB9R*.B63%OS5M*AM\]T-PU<+Y\R=FWOV9
M0M6C<[=X_OP8_MU#7R/,2C&7!0W8+YHU28W5S&S;2&E/2R/K$F7\THGLNA6I
M"5`%0E?=M]X7=F\N-"&4.R'BX/[O/#+PD/%.T1=I*CGEXDU)`^&Q.T?,V3I'
MK8,9=>0#K$=V38)@5HEPM)E=_#=H#6`I+(:=W!'%[,5;2`6+$:6D6",[;$R#
MHX]55'[.JQ[<4$E0<8/8^NV3G`$5/4DL98J*%O'Y%>U82\UCJ1UOVK^WE212
M#6<\_`9<PL,FDP]F&&J['KC#Q@CB98K_5MEV_Y:3TA'8(E@]`@MVYI,;DB;,
M;LN$,=5:R9?HU3S#;,@3NKCF6C5H5B2#>8)MHP=-_;;-&TW")H7GZC?%+6H5
MEW-^JIDY_493;W;Z=8J70<G`U#S;3#^#N0&<O#,W$Q9<"B`406J)FR\$F-4K
MNS:%\M:MLFU,#X@=GB/"E@YCNF:,2\DT6+RZ/>+(RTBQU5$%5[=C6*3LHPE5
M>''!$Y@N^+!2$:S;9'\'O3U2_%\<WC).RWY((VJ[=/F/SR:[]+8''<4M)/)?
MJQ2I,3<BEU2/;:+.;4[F*>E_SRV3(T$1[(SMA`.ZK`B^+5FIF_^X-6CHW+\V
M3#E&)#+")BSJ%/)0$DL=><YI48Q]XQJ*CZFLM3)ILKDKM,M:0_%=X^RO:&J&
M]VJ<,U.,64A;JZ(*,V4Z91'"N)KV6\$Z&G4PK$C/T$11/HKBJ<DI9Y<[$5_D
M?':"WE\?K6JP@.=236L"))Y<:<S4'O9\R\#Y0;0\^YW.>EK%>NRHP]FSY"2C
M0SSK7OICP1DD;#9.7(I_MD[AA"6#)0N^+G)D93?1]?3?@21#001>[8&E9%Y$
M56\,#A8!5=U:+-]C#..G4M>CJSN8J%]=CV5ZX`R5P-.IXP^Q2PA7RI49+,+]
M%M3\%Y4J8JKJ4H&AR:A,J4B?&"-LMU%$;8>F'3'^/,&Z0MFM$2YKC'<F$#KO
M=$3IC\!U]G)$0I3/BPR>0%Z2@X0C"#/O^V7;)K]E90O4=GT4WA@I:#D_58FH
MRP41L0S_E.94TQTW,_G7R>FQGJ)MW(D_M@A,(Y!$WJL11;]$[,)Z3!PG['2F
MVB8H,ZOFRZ1OA+HOJ/TY!U(;BX(#D>8B:#"<O%AKJ,*:R"D3;!T[>?1.9%ZS
M,]5]`UFQYAS0IE:'TD>_%DQDGSF9'%E8)025E/#7I7A^O'?E[B^=<<%0F'WZ
M?J)#IR)/2:['J%)BJ]M%O+(']Q&+@9B*.!4*VQ72$0;<8O&D0W?#7AY.7&Q<
M?CEB:^^=W9K_^:6M!6^.R06%;S`U5HX:9?QV@$87S`MLP'!F]GOW>IK@;"A=
M!15,=#UW+<%YX?A'6.H:NV-U9*:$[S!'AD.!$^KE8U9K<9"/4.7!.7W9:S44
M'-5HK-1H;#HQ%)4'@@'-X1KFBG3TF,D)#1T8W45I5,WG:\P)MX"\>Y==8_E!
M"\@/N@!VGU/R"E+5H^+EMC=$'&;[GE"$O%W[OM+26\TTO8IDYP2C:+UHJP#3
M78I6%N2R4Q`$9US'9!=LW_-^@ZD$RMF")A_#LZJY[B@!UO7C3<2$AD:_CM^0
M5R-RT7#J%@S!@,4Y#**22"J2W,-A=NV[![&K$ZE&#%Q9O;;`M9GY"EWUV\P\
M\<46(Q.E)9&Q]%"@6O65,75@VH0ED='`_!"\@FH='8G3KAB8#_,`<Z;JG)-F
MSX(K%BK+/DB4E$<+<HLTVTQ@%;OJ&889$3.0:\S1"B<]VLRL?)"V-Q?@(8T,
MEXO"]COW2&/8K;P/^89@$U+\5(YQH)4SHH^XB`!K^2N,@S!@`D,U8$7)FYG/
M?=!0=HUBH2^14^V,,0HK+BD8(*>^!>:&H&9<.LDS`%+FD9""-T9.,<S>GD'%
MAQAP8!#%/HUKZ\EDOZ;G]MG/#?,!-V8B733.QI>&<^[]=X>SK&Z;&R^,)25V
M)`-3C$+FC"%T(ZZ<_SM;VR^T!=.2/?O[IWE#.8VZ+R%W[&2GN#191@NC;0*Y
M,?>+CP\5N2\*UTNW!5].MX,OATTO^'+5NI>\&)R.C@L:Z/-[&)#G*/XNF5!,
MOE+A$MZ`2Y>B;@H).G53#-S3R>_7H2C8V=_\)%*LZEB*FL5FUP_/2:V^JCN'
M;4VPDD;-['DX@VO*0U16!6[<\^>U;PO<GP7%7BD`5R8(23C9UM/F!:(C7#:P
MK]1MVR=";`CK$-9<W&BPH^]ZW1\NU\EQYM=;SZ64=>1=V7_2<S?Y9U+_)VJ'
M4?)'_('YW\(->/_]@V!A[]Q).S#WBZ\3^NS6HU^Q7KH"^,B!_/,_MIDA)S]I
MU[M3WQY)==I=K<BJ,XEB_16^"F'%1L$0A)DB\G#./]FTG5NW@L#8X?F-0&>^
M)T`.GFL;&]R+H^CNC*SB4;L6"-QH0O7DXLU":S4U*B#E'JKBGJDJ,&Z?$FE)
MZ?Z4+^1T](12I(5)NJ')<K%*:<)=?W7D-:?8%<#3@9*W/54JV6X3'`B\,LQ\
M]5A2/Y^\+@%IQ"??8S_YCRHMJV3'452<-)^<)<!41O:.&_>?3'M/M6*9BWLO
M*`W,_S:,&*OQ'AKF>C!_.S^"$)#MNE7!7AQR+@4EC0>'''IWK%I#DH%<IQ?Z
M_QC#[S`2(Z[40(=>Q$!!?H@XOA/H)[W*(@_$(Y1SS`1*ZI1N#&=<<\V&S5O,
MX4P7-G==_FU*40_^`OQ@CY`D?2"F%0&=(G+3-(V\5.@WG^>/5J)S_>'A6-&3
MC\],U(M&:RIQHSYZ2F#3'M^EY*G-?,R@3HY&V;U%A3B5W2AQ6A(PR_UOOK[O
MN6/T/IF3+^>#_,#\?]QHT)<M"ZXD)FE.D2_+_K2+O$D&2&UKH*6G%4[3I8)?
MH[THO\6WT$7L%C5Z9WEQ9UI>8`'@5/+BSJGE1=<+KYE:7NBW.NWW+<&C:-Z\
M[)9W#$9U_#W'')`O@$0@TJ&QEUMQ60+"T3KBP6'=.89,=WFF%H-9E6]!53=<
MS`:6&.4I:N1U,R:4RRDD!Y<LB>(>$TQXRI.%SU%W-;]:L4%M3!7-[TLJS28R
MRW]-TNS,;6W2+#&O.\^RI!E!@37_H8B<*A5X%NV_AOTQ/+7P;]D%U-GAL8N9
M]Q"_`-/LU_^4+,ZW$.A$L)=]_B>(AUZWD0'HD4#/H[);CI2A'0MGL]P&UKCD
M@[50X/8<^-B8G!6A]O^'*+1/W8L4A1WO@F<4#BAB";;V$9;@Q"X+*&<I=VT0
M#]],L[GJP^EGRO[9CUM\BJ-Q'$?9('99@",SJ[SK+O\I$"X@!C_VL&/E\R(N
M8^.&7X2JX$O0F&D+0EOKAK;<3D5PEGH^N7-+5R/+U'*(D[(EA(?0%"5,**ZZ
MKX`';YM^IY'*6!X>\.+]/7\?+`XITXK_F85=/$__)V2P.'+;US%0=GAX:]?=
M=V.@[,;K+K),OH-372C)J.7J=.0B%T+C_QQ$,NJHN;KZ4'*T)<(#ZZSMNB+A
MT#L$94?!@15$?[)[,@<#M'HB73AJY-(D/,2+'SJ@#&V)AP[J>NB#F(O98^YO
M%_^'N$T2]YT+9__M\[H$)WO,M0<%84XE3.7UN\7\UJ$1-O%Y1/;%.+FBN$9X
M#;CJ'=]X:9L+>H;M@AX^/1?TEJ^_M/G_SEI#'<&$RICF;F([0W5&#GHYOTN*
MA*P]VFJ]2JO@5.44_O9/)+,/O:E>G/A.X+(7,^<G4;LW-`^$A<]F?_*=L],U
M"WE?T9LG6NS8+19IJ*5AYK?'$W\.]K%J.*6@=Z+KP^]1I*:LOD664L\E[?2/
M-+P"M=#L?16B:L/LI;<,528R)TRJ">W%(5&+Q(D.\HH3$+Q^2E)03VAL%DN:
M%TD'"5"6J&F(+6=(3KVB8`-?EOMDL$"O!U.WA!<2,,/C14+I>P<X0O>][[=,
M2QX3<@U<&U)>\.,4Q9`MLQ,%8X[!G]L=T!!S42JY)=7:A9:'(MKD[%,\@M*<
MD6;D3+!B]W)I.<F>-`"JX.=1PN?1]\,@'=8%AS-^^!Z4\;F<)2\[7-'LVO_Q
MEHXNJL2F!#V16LO+=]Q`/%$@R#Q%E>3BHT5>?5F8.69^LD'#G!YGR@91'#:2
M]#2*>F%*Z-5Y/_E<.!58J^'WNOQ*8!6(U$(QJDGANI'J!G^3XN6=KK$L-=:>
MVYG`]4("VC6S/_^@`J%,,<5P!1,5$\WOE.RHO>&L\U^9[#\BE8?45Y"5D,1%
MG4!QY)B5T>P_JD]Q&HTL+!R!79?4D<YS4M8?69,N>#T;CE]E$5Y"+RC9M]AN
MCC0O3XT"N'#=*B?7.5Q[8\@;G.<S8;Y7QO32YGPT2CY2X90@)H@DJEA<5'2&
MHY\*6VX"1!?.O.E6E05.O<FH6ZH:H8V.99\5JNRUVZ_N71W^\;D?#8(W=W[K
M%#AP*QT,&(-37WR)V$%"DC7$]0<>[U<N6KME[[I9U:Y&HRF8HZSSA3!,2
M9O;=1W[6WG\U9:FP@%9]D!9%%`'/A;.^<G[W$'XNI//[[A.$;KI]X;[[J!#`
MZL/%,LODZO$HJX0Q87A[%4.%)A<\)1!6#4J'_&_I6JN=S[5G(\U;RE1,$Y6E
M&)G[$GHF9HH:[IZ!658T_4E`V,2*5JN.9,\K)ESJ>N%S$JG>$@XEN:;Z+'+&
MIEPW5>6PA_X''0Q%IYDL'5-<A["Q?_!ON.),ZBMG/$[3:ND6\?V'IB]),=-E
MN]ZS]X)UH.Y^<&\+CX3=SX@L4`1KBCK940[ZZ=@D!6;YM1U$37NEB?+7.BEB
M+M[IG<@$AV.?;HZ^]\:)V!1_1*V1Z9^Z@RB]"9/HZ6+C2!.640^5J>T=B_P$
M/!&A76OK;*#!BR[=2&W21;D!$=U!HXR1."X`3UCF/]YWQ\!\VS1_V?1,\SO7
M_0F:)B\BCM;-^/!(R#INT;$.DGO")3UN74$1234J=E!S%E&)+=UU*]G9%L5C
M_RYXW`]^[=N'<'F3:[=+ZLW"DR[]&(XSS4%PGVHG81>:Z6'?ON8DUSO*"/A'
M0@?:P#SC/O28GZ-IKW]N"FP[W(R>%CSJZ;^R]F+YK5_\$QL?!\MA\F7VA:?U
M\.K><E]AT307)_<Y^!U6>)=V>H+1W@S"@#PU3(JQ5)%'Z0EK*U:<U#^=QT>:
MH=B"H9.WWFZ]8QMDS(Q@?BKM'B4HKO#<>'!MZ&+40N=+AC[]T@]WP`^JH57+
M&#H2*B.FRP#T@TJ=!8^X?-\UG>M(IAC6/#X5$JA!\V4UX+I+WS?9#E],SCR.
M9F-0#_K.4Y-*FG$[G]TVELE>4E(6*C<2HDES*TWLI\;NE/9)\-6FQ80^=2_R
MP&`:R/QZBD-"Z964JZZ&,=DD>R=WBJ-U6MAT/E(-RHG(Y/Q0KB,U/QTS,!04
M229>_@<35)W&!(7M$_0_GPUS5XE0FQLG6FHD$DO6I'1.+5ES6C0CKEN]1>^H
MH&V+U%N)4]&!3_,@A\*.X>IPN)`G)@Z%L%^:!Q1^7C6R_)BT!5>^*M!#A\&8
MOM50"II1;55\2.UKUC!)DCB%\",&AL3LV2KHT%N/B[C;1\E9[W`097:P<PH3
M`LY9>B#NW:9&4JZ(31W.*=1:!V)4?-@V*D@9^'\L`53?KA9)@THQ".QC*"7V
MEH0W?4N4BW.S,#0FZ#_,FS.ED!XAR4#$$\DD1/J1+!(B:P:9[4>/PY0UB5VD
M!DCR_"#P1MGSTUO93B_)&)@.-)&1H=3#\CAC(?P/UT4HN':UV_4#MET_;WIV
M_>=^]B>@AETDU+#I0#$U>L:`$UEQNS]50Y/_J)MN/*3)G[+UDVQ\8#FVENZZ
MZ\CSAD3>@+CKM\UX^%L9AN&VVSZ@_LP5G7=C;`,<3`<V/-&XWZY_05+,_(+^
M3/PB**5^D;B>PM%R[67^N%NK:7FHG1.\]!"&>IL6Q=\,U\?@UCDBL9<QY?W4
MU?@G[BWY@57OF8E^>I!Z3W,[OU08<6ME&2#OU[97G6K-UDEI\4QOD]C04P44
MC<A1')<II9%Z7\6KW[&^M\U2L'\A!?0JX&A.=ZIQ8-HM/Z0IH6Z"ZVM?892>
MA"K5M<S/F=3(<HEE).!KP%8!UTY^QW_(/N(_+AGH._T=^G*8-8POJX6>7EPR
M]91>>MK8["799_%O'S*99"\>R"RS'7$G.16Y"?ZA3PX\`X9TU/W3<5`S8KZN
M!V@1'Y&FV`:9OW?%EO#`TD\.KH]:9:]6DR:8UO/`N94?V\'40';J),X@'J<Z
MDQ=Q&%7/$09/U:\Q<DJ5]_,2SBMQ&\DEYZS?2NA`$_UD["?AK.R(J6K$H$>Q
M14[+"BS9[$VVUD\=DU*]XNX,3N4XY^2I(H&LER$]+EI>+4:M2-=-P]BDIYJN
MK;G',@\5C[QD,#K[8#AZN3CL^]L5*2WB:.5[W(Q]PRZV,P.%U+9`EJM"PU1A
MLZD1G$K1&VG[A9EG^)>Y*<;Y'QK$4W,.'!^0$D.5NDQ&H9%G#1;]%*RSMA/5
MZHV3=P#C3^Y`9F!%CG">_P)=?L(_/"=1L,%=X?PU;]N*C0P+*[BW"W8JJGI8
M&[SKUE=]^6,).`0K1"G+!)NQAA21;4W^D@E(L)2Q@1.\`'XW52JR4RMCNNDK
MKK![=R(#YYB;%]X1M>A+P^R&/U-=JNI^[',C6AV5)KO)I7Z`U-M)<58[*AQO
M]R&`R7K'-6`$-#.7_(A3.ZK^%/Z="[,?K`^&F4M^*.U*.:E#K83,@U'I5*"`
M]793Z,@IU?T1%U-TJL6"='V#!;+Z*P\3OR_G3F%TY*0NV]WL*.QB#!/%;T%W
M:E$(V.IZW=[Z>"OU?Z<R^YLWI?/EA!6S^\@2/@/ER-)P]K-?Q5YJ>:*:G4<M
MMZ4+):P,)M`X3=7(&SI6#D.C*=?L^HOK3=5A+9#*83T_U/@[IJ$+4GX[XE/?
MB@+^E.KB1YU:&0G-WZ^0^O(#U=*(J`*XMH9`5Z13I,<)S66#M)YZ8,KA.()N
M:S-R%]A&[LNG9^0^^)67'%<"*[DP<4:^<';JC+3WXM"I2,M'F<A\ZXH.S72P
MVP?G''J6AK,6?IS];4[=<"^O7J8:-<R!THZ36,R8<=\MUE4ERZ%[H%BYU[9L
MV'+,AMVE8"SPZHO4JV]4!3_-KO\JT:9M\V.X@T^2&ED5:X)-MHT+(9`*-;L'
MXTC,VJ0@FE(FH:H0=%6C-+Q7CVJ'BQ=(`Q/:O%)&170%%I1E$#V4TZ[^U,:;
M/U4#:4028XH.MK2Z3]W&J(RG_CQ=$-^>4P:!3*Q*M`\JB:(MHO>@OF39.0N9
MID%!P@+3LU9JYYK9U_43KK>SS%;H4<HMU9%+(,'JSV6!N7#V0UL4Q2/9S\27
MX<ZC*F;8CS[":G:.^M223=5F^,WL$^>6G>U4QP\+RI$O$O<'YSG&Q;8/=&]S
MUME7CIINME@,AF-+5^1($W0I'HQQ0Y6AYE!C]H9@;P_/@;U?(=G.HF?OT.8-
MK;XS%B^>'Y5=MQX(J@N1E2*AJ?&$ZFY79(JH]B0L+0^1%?AQ@30*)]-NU[?6
MM>_"4.R)4*4J+B>/S25IAFBS,_)#W!W*N:]8V;<)K,X-ZUJ!8.BM9FYIB$='
M7`<Z<<WL33.(+-_0VA)7Q$3VJ;MQ5UJ85]Z7YD)JSD&Y5RE7I>W2&XO^A%_+
MX<)&F6S0N1Y#QBV,;$<`<LOR+[_X6F%TU]V-!4VF[YL+9]URS"I=-,OI67QX
MOC%,!35CL&Z)/UCIZ;:O_$(*FF,HY&$(==.*=;N#M/O<?21.IFL_"PUEL>L^
MA,L=9FO7MZCHRSQ5-#G8NF+RS]!YG0__.`,MO(\_B.-1="(`GQE;5Y_PF[6(
M#E9S6T,&V69V^ZE@W=`HJ-?AQ8E2)!?.N6=5]Q:UQQ3WCM7XM.R-N84^8J$5
MH:$;G288^:]\M*T+C\7R`EO]4*1:L>&89+!;M2ZMV.`U=]\SG;YP,$2GG@[T
M\&S4<1GI`'$"*_8&<NRH^MS075,7G;8U!!/PZ&>8JL!#\R1S]'\K#J$@6:^+
MGA=^8+8^\<-@.>#.F^]]RHG&@PGX-1=71%A'<<++F=C8*U)!-PZC`"ELS>B1
ML),D,DS"`ZNPQNJAM:O6#ZY;E8M:F/#*K;IH2ZLG-\4K+/P>M5,A$V0BL_`I
MD$)EMJ2P]FTIM?+`,G)\B7C@BH4+EBQ>`D9I$#NJ1MXMJ+ISY%[63]:K*7`+
M,9D/L:,+Y\M>WB]QT+7MH>%IEPU,\;P;8%LVL^^J:,'03LHBQ(,D\PN@YV[_
MM9%)I/ZXM25"Y;O+/C;O<PL]=G?[P%53+0J=:J6QO21ST.ZF)A?"<\+6.-:1
MD[E1\@JV1B"1YYF>)QPO7+N@?^W"_K6+^M>>UK]V<?_:)?UK3^]?O6%#;OG@
MIF4#<NU`>-Q9SRYH'O[>WR^,%D6G18NC)='IJ@6.>&+6[=DIH_L1>3L?X$`9
MO3(YJ0?1[#3Y,8LB+L70HYZGB<\3+<0G6A2^Z;V_I$=22'EFM?K%%Y0N@_,$
M4H/DN@-VT!YIZ:L4$H@U:Y98@X39HW:584^1[BA51QUD4?'RR7($4_A=DAI-
MDF?D.-?<,A(BP%;%NDW<@3'O93JA`3<.J3E>"2]!QA`\M('XS5;CWN7@#F_]
MZ5`R#PS^,!RR1J)CK^KEM7=$=QLF@T6S$[#)MG<-5^'6N`"9Z3D+V-`.D_(U
M:C3`1C*(T9H`M:C]"+(KU!$S"1<B'%D9)^TYK*Y?/ICT8\`9OGG(\,*!1,DL
MYZ"(U'OSPXB$+]:D)J#F%IF^@WZ@>B.A`RB=(>!Q51$\LJB\WTUBGVA4JT4N
M$=`YP79\H.=^NQIIL$J*'?R&3Z@FD]KX(HN`C*0*L4<Y@5\AFT94A[90Z[4&
MG8!MA1H<9Z]R8M(*3&?$.G(8=_#U%MJ^WA'3\_4>^>L_04)C.;D+NS\\6&"8
M(28R!-?]#1C9\A946ZZGOI-JA.P43-\O9@)^ZN^8#\!J/UHNNP6/=ER-+,S=
M8F%B:?JSB*T_%+PN,(!X')N#N79W4VKJB3WLQ+HG<WFG5\<J!NJD6EIJ/+V$
M[%]1<IV:2O87X+!7\)[<:E-\BH![K,7D[6$DBO.KIE5#!YU"7_01FZ5'^/PZ
M"A,E0J@[(FS:>'ODCBO@/\B2FAL[(O.]$CX$LKAHWI/>&"13J=17)WI?:G\4
M3*%_LU^:N0TI35$JG3B1_=*[C$$!IEX`'C$EI&!PM,)ZPUG'W@[*]N6-8#0&
M'R06=@TX7W,_]2-0"S'+\5C"-JJWH\9$V_ADRZ685\/V%76WRDXBTW;$>"J5
M\X,,B,A73,=<G^&7;RQ3P<5_KY?=2`/!071*@=TD(^SZ[R4MJ\\:!:01(U-V
M%4MQ^_4HG+"T4Y4X,,"SF?WL?05I32W$B?33*2/#4>`7D<S-07-X[@=^-006
M"UH&L^:$5&Q`M_68-09F&P.$;/&:ECCR`'F_4<,4_JSO$9RJ!KNPY`TK5XZZ
MRZ;((10\DJM'./B'S0VMC0,;!<R,FE]A/@ZT,BX<VD+$)3!?ZLYN#4,CS)/,
MM#3*G:^J:)M%F-@81E`Z"610,RDJZ.2&CU/)9+7>&T`)-#/?_992*TSQ7"O3
M7-/1'3_$2!PQQ!@(MH0+JDA\`5OF5V^E69]"CO1IJD.1)\W,U4_3QH%#$C6J
MJ7N2?T#M7V'DFW:A6^V#+3Q<(H8-55N"\D8',G!CJ]E*M+._W;"V(#N!RY?3
MO4L>O3&,B@>/G']U\%0`TI7&T/YPS(02BC3(KQ"OL=`6JUVN,-:IC7Q*,_-O
M_TFYHV5A]DW+DM4B+]P,"E/"6(15ICAVX)=0RVX`2^/?_D&:D%J911,NSE,#
M"AC%OD#SAA"2O):^7(E;X;2FEA'L34G@7U=1P`%B&Q3C+('%SCE8K&.#F]4_
M)KHE.>,%I&;$`T>BCVA#AQX9Y5G@GJ;*<D5/V*WQ@6%[XE`:R((TCW@651`I
MP&;F[K.LSCVKR/>!BPS?X$3FR^,DU.#*#HD*7!N^@Z%+O?LL&IN)W)5-9;IM
M,(L0]HU7)4^)6#O.L24:\9@@&ZL3)Z0$O$G;<</SJ*99]'[VNODDD-`8W6T9
MHY9$YZ>'?Z/73C*2(TEPSW<W0'5LYXD`67GTQ:;>\]I]1AY'097:,-+!5@$S
M[/C8S'S^&Q12Y]WD!H8\JWTJ<;@8C(QZ/-ZD^\V*NK66B9$\"YEU?H81.QA6
MF]BQO).]G4!H8T$$V>=J0]/BP-G`QAK9=^Z!QZ`B=C)[F?:/5P`GEU_QG5M;
MNLY=!7+HMK0-A4(&_)3;?@X*A0D'^$3DPCDWW-S9.C+G_&;[G$]T/?KF43`@
M(C<F]P1>6+BQP5QPAE'"Q%Z:^BWF-^P-N_ZC'YT9-0`_(O@VV"B"K(*@,3)"
MIH?<'M^/<L+2CE,\V3WLR6(R1\X>P]'<G:!":M6:%S#U2JK2`J-4S+'`6R]A
MUF?W;R*V_V;VMJM0`8@+BD5SW=J_\:GP264(\53W1&2X!*-3:G/F/DJ&,>=N
MOH3ZPJF#I8=H9FY:@'<?]49&82.5?;@)BQ"V/F4#D"174DW9Q9F;3FREWA@V
MXAW/"`+<JUDJ5VTWMG7WK#6U*K`[W#$6IH''(4%JRH7;J.*Y0I4=CP?2ZYPW
MAL?WQ'X&98_J>@XI[;1\L\=0YAU5O%KF+R_8JI>!E1HTL[_>2-U("<LD<2C\
M$*LP6=DZT38^&OM_W-H$TA1N.GZB:#P4(H3&!!<6-D"=>)N]D8K<W5@:VGAB
MN<44(+^\/15!5DW7F8O,48P3.'.ZDKZ3\6*,.W$!U?VD]3*(E5D_[MY(>W#4
MJ<+.N.KO2!QR^I(I"ZF"D%ULD?".(K)5\@#N;=)+1K_"0`I"R:VV-8VY`%F0
M':<WZ9W61VM$:&>A1E0A/;;VK>!YX[06B&>>=,X%6/FCY4BE"`[A.G_/I^!0
MD3]8(8Z(S;MD9N,:!H"<N);'<C?+1=SDPD$,6.@WNQ[Y8YI90IJ?,BNBT,E[
MG"_%K2%)@R(5:O.E;/E@Q(GM3YU7L!(%IMJV$,Z<^Z%[/49((%U,S7H@&8.H
M1"TR:5U':_U>5R5A'JN9_=`FPPO_H:Y$\;*:3DKFL0CC!%T@]5)A]K'SZ:Q4
MT%*$HZ4;9Y-<@!FRF\XI@Z*D@E"H%8Z-,2@QD7GV.O4Z()NEN2W*98]+O)T\
MVQJQ8A:AWG5.G-S8D1'_4EZG[%/6\V'F;R<+/M@J?S^<9$95I(I-N,!@'.P)
MMI=7=CG-`Q:]]Q7A]2H%M#XPK8]27E-4.E4XG5S/*Z7:XGT0NV-4<[@#(^;G
M6<QAU05RX+OU40H`!KQ[8MX[&*IDHD+?[("VEGP8E%ED!V6.G%Y0YK'P)><6
M9$?A'4\775*&-KF?38$J4"26+6V*M).F$TU1!AL+'TK#^$$)77H$;!8385$0
MK:ZGW[=WY:H56\%M?KK8:D^\4/[O@G58N+H2$??=V['YR8&CW'(J7<*T]=@#
MI:9B/SW(SGS41M2L*W#XY"]Z(]Z/PPORO=%%A1T>#FW<=80<7?R6BSN$WNYZ
MQ8K'6!>QG=_L>G*QQQR3G<`!Z5K/)/,V'LP23WN,Y1_V<15Q1G74V#6FZ[DJ
M2)C&!-R/6'3G&>Y$V!*/_51Z<V.Q-MKT*ITKQ`7XB&@Z-!1Y/F9LR]*]C)I/
MI%I=HO[Y[7M4`IR<:8ZN_FZMO*Z*II)S?^IG<4"+VY6J'6J<+]H[B(6JI_YU
M2Q/5AYF%2[P4_`7V8T!-F_&TU;F7!/>:-R%I&*,$M@?:BF:QF/-76%&3[8L*
M'FAE$EO2[#Q5%X`6#!G<'D@?DEFX\HJ2@M!0B9+9$TY2Q+Z9$U[=1NS;41_M
MX07DT$P@"5:0TQR25IR8$B=FVE8=+R>/J)F]_1ZZA`M)&'U0(X,881##L8^>
M:,4EWPPUPJ^_;K=XH\Y1G%5";A`2H+BZ<R]X<CUA"Z1C*?T0+E(L#JY;:F:=
M/Z@7V]/V8KOEQ3RRLV,*)4D>P4=7!9N/]_FU$0=GJ*`*T%58DV/D`><);!;0
M>T<,'&4`-N&>/PQ996J^2OQ6,*8%^Y2L8FU^N951G!0Z<('*3C#=,_8MR7L8
MS=+!^-1Z-3/'WIU8,GP/U`=>(6(+54^Z"J*`)7#R/W`>D++'Q]XMQ,Z.SJ'F
M<<K=J)MM-Z>26-K,51N<0+.EHF>J-%ZRN)Q:$<$C]6B"5^UU8=2X*("=[<F5
M@6]&/+(DLU\8*D:.1LG411N6+R;>IH;I^:%,5CBAP24'MZ\L+$^!+B=#.#E/
M9(;%#>/<INI!!*1+0!8*]NU1P;Z4Y6+S]R6.C#J>*YG-FL+@V6__(66$!'%`
MX6G4X.!D#IN9C6TI&^N&!SJ4\.3]0\QRCA-$D0$*34=4XNDKFUW`P82<+R&[
M_1[!P?1*^ER0O`1%L"2P=$\@J*R+$B)"F[5D=RHC\6SZ(9`>7`JJ_JS'PQV>
MPR2ONF7KY)95%ZW>L'[+YG=MWKI\Y="FJ'4(\68&3NI4TEYXF]4O&YRL+]T&
M<P93=L()K64$]C2?4,=G@U4I25R0EE!O%W.7-60^N0X.O>&[.R6?RV/UFR8>
MI/3QFF6GG<G7++V$+\KE<N_0E[50<V/6HQN&I444JOP%\Y%H*WSO=]^3O,.I
MIZH72'SZ(E\"+`.<QX[SM?G2&&9'OQ$%+Q#+H&=LVS;JV9M9IAVBA>00K5*P
M]6<^D2SEQ4J"S;N$B@4CQN`17?TI"V+WN1-9.7[N<`6Q4RY$D3M_I'R(!.7&
M%"!+.-"/O`I='+I6U1605-(Q"\5=BH&=)^Y!/]R=Z/KJX9K>'S<['9V"6W1`
M5L7B</*!I,[7?ME-^PL8XSG[XHV<!<KC60?/`T1(C":WCHA*P5\S\X.W4L%?
MK>8*YBV<?>2Y%%L12]V1^+;RR_$QD;'^-K2B\/?XI1*)%LL*B%DVZHCB/FEM
M*+`3-<QPM3.`WGQ%=HH5VNQ:?;V%V@8'L;WN6D7M9*:T>\JOP#JXCBEF'1?1
M(:FTGVH@V9=.YEJG,/ACT/0FX]X4U$V*J3>%-",UFL+DP"`XBNZ2@/%[L#.1
M7E%MX4<0Y3JP*SSCM3>0N4UB</^IW_4?WDF4ZH<IEL4S_IF,_>@1=7).?PI/
MSA$G7F1MZ:%BLZOZK%/AR#T*@HFNZA=;;?M5N#^(K8IO&[$O$7<@;Q/(CU/#
MO?KQ6P5.8PYZRDQ7P4\OA9B+K+X&R#].@0+A_N)=PVV7U$E2$*$=Y>!=!5#L
M@<5C+")(%Y@@2<NN&\*1XZ_`=V::[+9WMHJ*DN03[I@KOP:)7^C#-0ZIC*M<
MQE8VFAQADH/\ZEKY7FI0\'2Z!7`7@MY(OK$"25R18XHU<#1GK*J&&O8J#L^4
M74I`#:H1%`-.P$4;VTLQ6P.GV5[R*Z;G)?_L+2\Q=`'?;8<S=NAWVWL!545=
MI*LF<3$D6*U^7:4J`+^D"N![!4V$Y3Y)TA-5T65O`DJ824L3MBC(2?""/-C7
M3L7%E!U=DZB*HOK<D5KG==YCK;,I/4(>*EE@-M/%)X$?@ITMVQ`6\'4JED?G
M?@&=^PMQEL&7QCVW)#??BMEUKRH[7DGIW+[M9^>#7*,\G(/[1RWN/D1B,"]-
M+0R87N>W4X<SUV.(_T"N371]_8FVC$-?DJ>P32#$_&Y,8-@]F:OZ/M)<=?WD
MPU1`@-#4''->PC_*;KG50\@)YH(24*#(ZH2L0%=X\E>ZF*6?2_O!`'_H8ULD
MIVH[H')9+E\1XG:+#)&2X5[!0W31Y#IGN[O%O<AP_[4864HY.")-=N@'-5!#
MZ-X)F##P%7U57173X(^Q`T('*-:>,"5>:!09H&BUMS3DGUBS%W;M&6ZI-I>@
M;19>=8Y'U4J.4&/;6H6JY(@X9MY8.'/1RGL]]4+=5@41;7R./\DL]TBV)ZDF
M;8,B2:=XIU64E[@=%>0Y^_ZB9</.")P@SVH_1]3B\A'U$%;UH%=1`UDBP2JI
M=?3W\$^N[4\4>JK"1WZ4HM_&L3-9(@HENH"//[A!>%4W?K-=[.C<J7;I;S`*
M*]:O)8!H&!J#34285GE/(\-IC^I'.?A)TAP>^LQ$^L#HK2Q%@_!<%OG6\#<G
MP1"MYAPO5_;J>/R7(G2S?Z32Z%?;*<B))4X!`H>I.B65"=JU$+%"XJVOPI`*
M)83668V2N?+XL!6WOVXPS`RN10MN(C.XB>)FX+TQ'";V,0M9JZ&I2HAI=:*#
M96'FG!?0/C40AE6;ZGY<;=1C"E>SB1A3`DK=FVKPV7^P/&:++]TJD.-*MP1X
M<\6NL/\/ZX>"9O:>?CJL<'R&L:R1NC_NO'GB`7CXLRP0YTI."C>S5W_2I`^N
MWM;2Q-^JD11&9&M^&7.BX,_.?62Y+R8D9X;1(#5Q0L4697*+=J>>'_Z9":DE
M(FW4N!)_7I/>"&"P(KQB7H7PFH(L&*$>;](BC8./?M6K*'9V'67[QK]@&)<[
M6Z)*T\-SB%!2.MWLD3.P!SGC)#-6=\%R%E"2A!8+B)GG$BEUF2Z7$:CF.,B_
M.]FR<\>(X$]U>"A(0L7'&%?00^/4W)$&^?DD'KKI2.#;56,R"+E&D@H@L6><
MVI461R$UZT(<*`'*`K<2N"?V)%OM7M]GP1$HYE)P'97^,]A$A]BKX%PT7&6*
M8E@3EU7["&WA^Q)&>I-MF-#$U7!6DPCH6%"S$7.N]=&)KM_\VDH4D;-6\TNQ
M4R>WKUWKLG<.!_/\/PP58X/`C>I!3.\5J_*E.!5[LA)2JEK#;V8_=[O3%IO$
M%J@T"112%Q`NF]!CN"*H=@6X/6ON/7:Y%`:6N-=T!=$FO/7A3O-TR^]_OCYO
MU>(A!&7,+>B:/-Q%4;?QT/S8E["HW9*2+#],8_SG<>JP=01?J#Y]*F]%$'D)
MF./J5USV/;1\5G$QOD4G4M+6.I!N'@49_JFGY(_@&4D4^&*H\)?+5=#?2+_]
MU.D+2X95^8(H8CQ7W9@[ZB,^,ELAXW.H]Z!E:&:N?KN$%J(O<FL`NP5=-[;#
MP.O:1HD*X]@1D`YTG[1#L[(6["AJ(GFX'Q>=$53"I!<L4#:I&.J2RR3D].JF
MBZ7,#,(OW!I&F"E_;@)!R@E*Y_L6VY[,*Z?GR?QN[9\`A+V"0-BK?K(.N32P
M6%/+^W2UYAWC.K]QA]L2C)O:6&W4)9WI\HV\HW5U$$;'W8]-26FD&2BHW9W0
M>)H$89UI*G@D59(4I!B_LZ-O4(UTG!+R']D)"/(<S*.H!N^.;ON(+8!A[6N4
M`PD$`L=5#7Q6-3K'4G1+PUDSKNE,;9*:'33ZS_D9YUH_^OF:@(G(4K<?:I2?
MB9+?.DI1HMMX=82'N=6`*R]M1=SUL>72Y*.D@$%.@IPY`=03$G.V32@-!1)X
M40D=DL2SJ`Q_I$&!V-K0E+9FWOM:!L-*[JQ1%\"<+Z>)+#>$"DNNJYLHEC%)
M\J%KVYABR(\-84P^R>1RXI^Z^9,4+6.>AN[*3%5\/Q$<"*-Q\Y8I*%#E&K?9
MD6H6B?3$;DEKV/6R'BKWI4ARIKG%C;T$KUT1K#2H!LXNJ=Q61]6)LNG)RS"!
M4_(#KJ!A-2TMXMB-6A9F3P&='Q7AS]XPFX5+V5;KC#N7(_ODJI8JXU3=^G`J
M50FEG$BL4-UQP.14=_RV->K!V"C=8DE[9!^;I.VACU7LJI2/5/MB808:<-NQ
M5W"%@Z2P?)[2::J+DA1^%=V2[I]$>YTJ*<#JK[M6](QTIV[SSF8PW=9P(QC$
M&5;[=*Q-($EV_G$IF9#8ZEX%]4@@Y8XIG+E5:&?S]8>9\W\5^%H8Z5X`.+.[
MA4'@EW_.I@'GU+AU8X>DODHPDG_-1XI/DT!38<F/F20*:FH&"ELZ%\Y^^]NV
MF(((LD,P\Z'`O+&#)15T7XRH8\S<Y\25>T0>YXH\GZFMJ@1(:P6!M%;]9/7N
M3]6D4Z)1&7<E5$;VZQ>K_9?]VO-T,D9&4&D(@%Z,(=4#T9H(NZE")45O#H[*
M/SZZ13A1I,":$K8$[H2KP$6[>`:9K1<^#.]=\HJ6H86@.4-`+98"K:_$OPO\
M8!W@&@&["-QSTFISHMO=$@]6(C"<U'<!%0.Y9&CT*G>JQAE:&MK#<*JC,-<,
M/7<1UYBS0VNP`JBT3_]N=36^3$5YWM1_=P];*9+.4:6,JJJ/R+L4281J[(8$
MMWU4XY)2S\I'8(2$G&P+4)CJ3,&5EQTH=M,<N1-&+<+GL#^MOI`M7-F)S.8B
MX@5]WK\![=4RD7C#?S%PC]UU_(+:5\?,`)'9_#5B@*#R)HK@D8M+^P*.P8A'
M!<B2HB46WMCH$NSOX.Y'NU7JDK)WOP[S7(T**@)2M5:+>I5[48>6S0K2,2Z(
M5A]GR6[+DG?$1#3*&A'%QQ_+B&(.[*5RY+!:>21OA"/^W5>D;>^)[*9'O(JI
MMIQ'=O/DEM7KB.2$N$P$/Z!A^FTQG(G,)S^],Q+_BJ(#'7RSNJ^D02PX3YI?
MRM\9*<C=ZSDMYU7BR8UK8B);B;V*`1=2BDSZ,W-'TSI-K&$TMDVYH4JSZ[IC
M*4U>*8!?=,]U8,M@/0Q9/2GW.Q)+RBDE'2]JP>0Q2(ER6]KC91%,,A#VA%H@
M!84@U`S('R\HHX2_;74`=DXX-)7U.`QO`WNG`,;=F_]*UQADPJ6MI"7%84@^
M?9+*PTUCV5*7?U0YD>R`LA7'?B,E,X5(.B:+8AZY81_X#]4`&C3TDQ,K9./`
M8R$@*E*"'L;$<T0_D*:&QI1RW;+J6,,/4!&RHIV$.,$RQ(*O,YKRPH=08S3-
MR%+`:-]D7<=7CJ<XM"63`G>DYHXPAPAN"]$-NNR-&S#0K&`$)Z9.[B3X\."`
MVW[<HZ2'83)2W-,Z.,ZID&;V2_'.W<H+W,.5G.1VZG8LME1#\JEPUK%/P]G'
MO<:Q'0*6T1.9J+Z4GY?X<E,4E6AE]*-+=-79ECV:#'U`J2--,0`2:.[KB08:
M#.@*"($W/CY8XJ:3O###)8^0K4*M@9--O\%X.)I5=D0I.^\ABM[5T"K8.8QT
MLO@9EF'C4(S2S3O<G1(T8)YJ41O*A&[4&9(+YC,6G_!@I#BI2!4>+CY*[7HU
MU^0CP_M^?`.M$FU:QCAV3^I^M-52U!+J45X;Y/SX[`V3U:*CKBBJ-FDC05%?
M#*K#'6CU*`3[<$P/8JH:2P7#VD2V3P>W?(GMEA\U+:]\9O;5+[U;3CI^`>GX
M=80S=E71FL7\;K3\7>E*Z:2B'W6H?D.X(HCJ'.:3'2#N15?WRR8*18T:J?F#
MIL%*<RN\."5?QDA4+'\4JEXX,_L]6^6#E,\>NTM`<$A\D!W:ED2`>W6\PD,.
MAB/RF-W!'JM(071P^*%(36H';KI>DDMF.G6)8TSM'ZB-0(Z;7EB"BCW`BBVH
MRGYB3E.D_;!)JSIHQ(8Z/0?I/>KNA<+6U7#TCI84SW/9;U(K!&L^K2F<<B$B
M7H6$:;4<>>6_?RR]"M,4H--F8VM]G-+.+Z3Q$(;HC^"C0HXA(9.\P[#>@BK@
MH;7P&0PDNJ5!@".8.14\;;-N%\K.I^E"VPL71YH7)_I8]NYE)=O[_R1*(]BY
M8I"YYE2G+"!O!?Z3LTG88-DT+-8.)M/(@@<JM]6M:1"U$68^$J:7"D03.(?;
M^S&X\ZKK!BO-S'6_2+F99"<0N,;0"5I<3I;JP2.*[ZV73C82GHF)S-^\@(\9
ML1$6-/!?MAG&T7+Z13Q"%0QDE'A?1M.:Z^]'"3ZE#:38*;!^0M-MA`KLC6/%
MYP;328AQD.9G'!Q-ECM945+41:I!G@57LBP[W(O9OZQY'.8J>(%^!$KYCU#]
MRC?.J-/661K.?F2FP80K=&3)09\E65*:YLZA4:H4R1.#S^(<X;;*S>S<-[IC
M6/V)FFY9F'7>SR4#D0X3(P<ZV+-,'H@FJPDR%=PJXK"2/'2+OLWX-Z[:QOPD
MM:7516V,V&UF+WS!N`]4_.:.>&(7Z^IX)//$+E]8#*!AWDA1UV#>KSGC7V8Q
M!8^2IX92!))'_B\+%J?O23`/CB31?:@(W*W2T_,Y4%T^1$-0.U.)>>C:&FY8
M(*<W8=1E?KZ(636W\V23N>WE83:=(&B4JZ:?8+HY2/9DW<V;RJY4&SE&I3#U
M)A_@/EV!2H=>\88V,T?_DVIQ'F8O^=60@$3`-,!6F7#BP=S4UBR7RA4*E(<;
M'H8MXIFT@N7G43@*[RHW5=QP_W66`U;DQU^)ME^YF!^+6CN"7#0Y-GXY_IOC
M?J.JX0LF(CA&I4:]:/SRWA@[6ME/(_Q[=:],'2DULK"9O>4QJT-EHEFB%LR-
MBH=F96E<Z3T.#LT]8XWR'!&RR&!IY#6P09K9G^U`98H>@')_?*S`._;E7EDQ
M%4KS2K+7F9\2=*H>+@$\#+QZ0W>.)&Y:(J%`1C]BI\(M/!HG9T9I9'5P1"2S
M\J7``Q/24;33)&Y*6$&0BE`MI`A5FBA_JNS&H)[89O8S_]"I[QF=>AT^E1)7
M544M>'\'>9V(5H#KJ$<JA(W!TAD,)A0B[07[PP%,%#=;H6!X&A/Z[$S+T,!+
MQ,S0!2]T)(VDDU,ITD$WM9"&9W99/FBN64<-$QPUX2!0F5"(XHXKH]6*Q[(A
M&1?*;I(CML(\4O/I5JG*=X'-01ERU08NS/QV'W-S6J0!-&PB4EGQ+3`]Z$GY
M>=IQ7/U&5=O--$#ZMG`NW[\17U#19%#UH`03*5_887E%K70/]'!6A5$.?&&?
MC@;8+3>/FJ%M(%SR[@4]*/`P$%XGXPXIN3#-`'=$X"]!L(Q&X"?16-MY$A8W
MMJAN5MBQVV>=>%2(G(,2:!W\FM-MO^;HZ?DU1W_Z3]"<;N6N<."-_B;I'9:]
MIU^3<R%T_:%/FQ@@.3Q5D>_>6#3""/,`<_<>;3B9OD1HP.+UL+8FAI2.6'^Q
M"BEESIQ)>B')'`1;=/DG[QW=_]8'+@OOL\')=>^,Q["J^;R[!]<_M#2<<=/O
MT1XNNT@706@D/_:%X`O^C_@=Q\L8S"O6JZ8>.LR\_;];+)&SE\U0\6NLT!I%
M1>';*4[5\$%EPFTKBS#;J5"@=A_@CKF"4ZF[N8*[%*%$?0Y62N]0Y'_X?3`:
M-!ACU?E[;,GAY'.-[6T7X-*L1@Y8*@.G[@%GVR,JK4>A!+?.=B`5N%M%X<0#
M(_D;,A2HMT!`>M"OE0J8XU#'_5R,D%(8W97",+59.N;/*.?P?8$[?3_7*C,O
M'C^&JN3!>#)>1:1:HD3J-6$6*1!$!->-A->DGJM+ZCM'^NJ%X!T4B%#3O:,<
MY&JCPY6\FC"9K*`?+L_5$;36ZDR1)7WBJR45YB>'&Y?VWM&VS38)(QUDG+Q?
M*KF:*>E%]ER7EH%T:]H^9;33&W5GU.#PD-@?>RAV>H3I-NW-/OWKUC`V"D=Q
MCTV`P2HNQZ;_[Y3O7O`M%=Z/6XOOU.<7^[:X%[6F3O-MW:I-H_G1WI6[OW0&
M=B$M$`JMIK,W4]]XA[<3(9/X@SYU=3\,Z9;ZYG>>"\/8FSVS=)".,.&,[Y[0
M6AK.^M'8H=]8=9T!OW+VQ[Y#DC%[Q&<2W`M2K!$8*E\N*&&^8=W#D!).R0Z$
M8L!W()#33);4'4$3E)`'I-#?B2F<'*W7JTO[^W?NW)GS`C^7'^W'8"+^5XXZ
M)4_%U3I\NI(7S<SP,B3I\(MAMN>BMMZ!$V]LJ<P!W/&ZFSK-G41KL9E?OV[I
M!R(SOIPD[KR2>XC92KDVMQY?6B&J"U:P_])P!=R`)M['YJI)I26=)"CC&;5&
M'6HB0+F<$O%H(U76,HL:#1'MI4BL+O8X&+*B6(0$YX3\A8VRZ5<+Y[?N@5.0
MN6/+)H<P5Y<K4HOV`[^5S(QS$(`HC5(4!#):`;9XWD,F,`=6#"FD+]F[GE)/
M7`$/WM*H&A@>29M"Q)=$)21$8^K5-+]:S1M!WAPN+R&MRG-5,[#K8:<&_^?H
MV"PVI0I[GKIRC5,K1<O=6FT\?-M35U_@D=WJ1<MKB"$(3SOPO'3H7@'7>4')
M-%?9,NJ7'3(75@58VI)[ZIK!$KS">>[+:NYXN.3UEYWWWO#W!P[XM9%H3441
M_(:YTQ_?"*<"-,LZ)[^&:%WUD)L\#:U;YX/C'BZ]]PD][1',>5R_/'SS^ODH
MQV*08]%F^!^68^%;#OQVQ6C-XTLW5SU8;M/A:15X*P1O`ML1!2$MB#1$9R,]
MVADYX5$##VP<!=U5C?F":+SDU\(%=_^?K:6:MSV^P(.?ATMO7K\Q<AJE^`(R
M!L(9NTZ_K.[H6_%"XDKHM83OA+Y,>SP'6ZF5Q.KGT;$8#*I$B!2^]:0KU[NE
M`/L7N"Z]23AP]:O/17`OG-SEX#7`<K[U]:/+L2)M!;Q$P?3B6>F4:=MNW;JB
M,5*"M>F^[#9:JI6-"D=[X0;SO_S\.@QN.2[E"E=/X):MC33@EN&;#OQN%4Q`
MM#H&[Q=^@4F,43W\<HRUU>AQSX%Y*;EASYM^Q[L@.@<<12I1"-_ZRP7GN+`7
M7#@3R#`%]GG!#8\;>X+W400V1]U:L>4(!/(YEW"N7ZN$O=_J7S$*>Q`T*&S9
M"K[%J?]G)4?8"_`1NAO5\*WY*V6_KG&QESJUIY$A:3W\RG9X`8INX498XY7#
M!?^\9A.]>:T0KP$I%8V&O?^\?I,_#'[0&J^V?=0IA]VO+PZ6W+%XC;_=;"J&
MIXS*NZ_#AG]!>,(=5R[WAR/8O[`9PZ5W7+W6K3#H>UT#'JD")^647?,W8$7S
MQAB,@@"$PG9KJ?;HM=\TZCJ%<.'K+UOGU+9'F[T*.#KATO4#@Y5"S=W)0@4#
M;'`G.*OA<>>\:J7?&!$1TBCH,5>,NF[?A4B+YE#Y\L61VZ`^PVWNRQG*?7EN
MQLSC/SCS`S=^Y?7+T$?)_*SKSS_RT9D/[/LKL,V/[FBI=ZPMW-_S]\'B<,9<
M^&"N^O#T_6^^ON^Y8V8<#A_@?^;DR_D@/S!__\G/W>2?J3^>6_)'_*`$GY]$
MG\^3SV?CY_#I\>63'MPTX_#]"_E3'!D^?=/[O[5I,5T[3W^Z8/\;$R.K$=[`
M(ZA/9837TPA'%(N)$8[[P3-O&[.OK=?AVM?Z?W?=P_J5L_ER[8S]Q[XPXY2E
MB2L]N/+(BSYY_LOT<\U".NP%^X]8^>A_U&>\\IS/T'_HPR7[7W["B;U[$D\U
M#K\__&6W#9]I?UK&4>>L>?;2<?TI#3!__^S'H]LVS9B#,RL/M>3Y&3/[5G;]
-`/[?_PM_JK98'"\!`.>L
`
end
SHAR_EOF
echo 'gunzipping file tds.dvi' &&
gzip -d < _shargzi.tmp > 'tds.dvi' && rm -f _shargzi.tmp &&
$shar_touch -am 1115195195 'tds.dvi' &&
chmod 0666 'tds.dvi' ||
echo 'restore of tds.dvi failed'
shar_count="`wc -c < 'tds.dvi'`"
test 77596 -eq "$shar_count" ||
echo "tds.dvi: original size 77596, current size $shar_count"
fi
exit 0
================================================================================
From owner-twg-tds@shsu.edu Thu, 16 Nov 1995 18:32:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Nov 1995 19:30:34 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511170030.AA11306@terminus.cs.umb.edu>
To: schrod@iti.informatik.th-darmstadt.de
CC: twg-tds@shsu.edu
Subject: Re: tex directory structure draft version 0.104 available
in TUGboat, I assume that it will be 1.0 and no `draft' any more.
Actually, I had thought it would be desirable to keep the version
printed in TUGboat as a ``draft'', lest people who have not yet had a
chance to comment or seen it believe a standard has been promulgated
without any opportunity for non-electronic input. I realize this means
1.0 will most likely never be published in TUGboat, but I'm not sure
that's a significant drawback.
Thus, my current plan is to make the version in TUGboat be 0.105,
not 1.0. (Or perhaps 0.999, for historical purposes :-)
If people think this is flawed, and it would be better to publish 1.0 in
TUGboat, I don't have any big objection. Speak up.
P.S. No comments received so far.
P.P.S. The single most important page in that thing is the summary
page. I'd ask (plead) that everyone read this page carefully, if nothing
else, and find out what is missing, what is wrong, what should be changed.
I just noticed in the closing minutes of 0.104 that `images' was missing ...
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Nov 1995 07:53:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 17 Nov 1995 08:53:37 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: tex directory structure draft version 0.104 available
To: TWG-TDS@SHSU.edu
Message-ID: <816616417.182445.BNB@MATH.AMS.ORG>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
joachim:
in TUGboat, I assume that it will be 1.0 and no `draft' any more.
karl:
Actually, I had thought it would be desirable to keep the version
printed in TUGboat as a ``draft'', lest people who have not yet had a
chance to comment or seen it believe a standard has been promulgated
without any opportunity for non-electronic input. I realize this means
1.0 will most likely never be published in TUGboat, but I'm not sure
that's a significant drawback.
i agree with karl here -- there *are* people out there who still have
no electronic connection to the world, and it would be unfortunate and
unwise, i believe, to exclude them from a chance to comment. so making
what is published in tugboat a very obviously "all but 1.0" (the .999
does have that connotation, so i'm for it) is what i favor.
(i will try to read the actual text and comment, if necessary, before
the tugboat due date, but i'm very heavily loaded with deadlines, and
it may not be possible. i shall certainly check it over after it is
officially submitted, and consult with karl if i have any questions,
which i don't anticipate. i think everyone has done an excellent job,
and intend to thank the group in print.)
-- bb
================================================================================
From owner-twg-tds@shsu.edu Fri, 17 Nov 1995 21:41:12 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Fri, 17 Nov 1995 19:41:06 -0800 (PST)
Message-ID: <199511180341.TAA11564@tashkent.berkeley.edu>
To: twg-tds@shsu.edu
Subject: 0.104 comments
I have just a couple nits regarding the latest draft. I hope it's not
too late to fix them.
1. Karl's address:
... or by postal mail to Karl Berry / 135 Center
Hill Road / Plymouth, MA 02360 / USA. We welcome all comments.
Usually addresses are written as:
... or by postal mail to Karl Berry, 135 Center
Hill Road, Plymouth, MA 02360, USA. We welcome all comments.
Also, it's common to put more space preceding the zip code; in letters
I usually say
Plymouth, MA\quad 02360 or Plymouth,MA \ 02360
2. In Section B.3.2 (Web2c 7.0), it says:
... A site may of course override
these defaults; for example, to put everything under a single directory
such as \path|/usr/local/texmf|.
This sounds ungrammatical to me. I suggest instead:
... A site may of course override
these defaults; for example, it may put everything under a single
directory such as \path|/usr/local/texmf|.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Sat, 18 Nov 1995 12:39:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 18 Nov 1995 13:39:08 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511181839.AA11265@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.104 comments
it's not too late to fix them.
It's not too late. 0.999 will go to the TUGboat folks on Tuesday.
Usually addresses are written as:
True, but in this case I prefer to flaunt convention, because commas
make the line breaks ambiguous. Slashes seem clearer.
I'll put in the extra space before the zip code, though.
This sounds ungrammatical to me. I suggest instead:
Yes, I was getting tangled in my words. I've put in your text.
Thanks.
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Nov 1995 13:49:01 CDT
Sender: owner-twg-tds@SHSU.edu
From: "ALAN A DUNWELL" <DUNWELL@jnov.colorado.edu>
To: twg-tds@shsu.edu
Date: Mon, 20 Nov 1995 12:46:41 MST
Subject: nov 15 tds...
Reply-To: TWG-TDS@SHSU.edu
TO: TUG
RE: TDS dated Nov. 15, 1995
Howdy All,
A few last comments as relates to your final structure.
1) All my previous comments still apply.
2) Your implementation supports the fragmentation of applications
as you have already mentioned in C.1 as regards to Macros, but
also it applies across the board. In addition, again as you have
already mentioned, there is no provision for versions of a
package. The net result is nightmare for support personnel. If I
get an upgrade to a package I must ferret out all the pieces of
the existing package and delete them, and then install the new
version. I can no longer install the new version in parallel,
make sure it is working, and then make it available to the users.
Installs now become a real-time "hot" issue. Most TeX
installations require quite a bit of tweaking, so in the long run
the software managers will always look like incompetent fools
since each upgrade will result in much user dismay while the
package is forced into submission.
I suggest the following:
1) Try to get anyone who is writing to the new TDS to provide a
"remove" script for each platform on which the package can exist.
This in combination with an "install" script that assumes the TDS
will at least make the managers life a bit simpler. This does not
address the tweaking issue, but such is life.
2) Make the scripts editable since there may always be some level
of variety in individual installation tree structures. That way
if one wishes to continue using TeX as the root and INPUTS for
inputs, they can make mods to the script to make it work. These
should be variables at the beginning of each script or a separate
script that creates environment variables.
Alan Dunwell
JILA Software Manager
dunwell@jnov.colorado.edu
!--------------------------------------------------------!
!Reply to: !
! Alan A. Dunwell, JILA Software Manager, !
! JILA - CB440, University of Colo., Boulder,Co. 80309 !
! E-Mail - DUNWELL@JNOV.COLORADO.EDU !
! or DUNWELL@JILA.COLORADO.EDU !
! Voice - (303) 492-5308 FAX - (303) 492-5235 !
!--------------------------------------------------------!
================================================================================
From owner-twg-tds@shsu.edu Mon, 20 Nov 1995 15:59:38 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 20 Nov 1995 13:58:47 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511202158.NAA04188@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: nov 15 tds...
Alan Dunwell makes good points about the installation of a package
but it probably doesn't really affect the structure of the TDS
as such.
It is more a matter of how the contributors of a package put their
stuff together. I have just finished my first attempt at putting
together a Solaris package based on TDS, and it leaves me with
quite a favorable feeling about the Solaris packaging operation.
In TeX's anarchic world, however, I don't easily see how to start
framing the outlines for such packages. It's tricky enough
(and largely undocumented) even in the Solaris environment, and
it isn't likely that it will soon be emulated even across the
Unix family, let alone out there in the wider jungle.
The Solaris packaging system is very finicky, and perhaps
rightfully so. So much so that I do not see any good way of
reading add-ons into the basic package tree structure at all.
With the aid of
some sort of version control (I am still trying to find out
whether that can be done) it might be possible to put upgrades
into the package tree so long as the earlier file has already been recorded
in the original package installation. But what Solaris seems to do
is simply remove the entirety of an earlier package and reinstall
on a clean platform. If the remove doesn't work right, it sulks.
That is why I can't see any good way of infiltrating new stuff
into such a package.
I fall back therefore on a system of sticking all add-ons
into $TEXMF/local and having $TEXMF/local a link to a completely
separate tree. I don't see what else to do. That is not going
to please those who want to be sure that all TFMs are rooted
in $TEXMF/tfm/. . . especially if they have no capability of
using symbolic links. They will end up facing exactly what
Alan Dunwell describes, the need to pick through a whole
mess of discontinuous directory trees to install (and even worse
to remove) add-on packages, a little bit in ./tfm, a little bit
in ./vf a little bit in ./doc a little bit in ./tex and a scattering of
little bits in ./pk or other raster directories.
If every package came with a map file saying exactly where the
little bits are to be stored and whence they are to be removed
when a new version arrives, much of this problem could be
relieved, but what chance of that is there? We can urge it,
but it is unlikely to happen soon. Such a map file could
even make up for the absence of any version control. Sizes
and checksums could be used to ensure that any file associated
with a version actually belonged to that version. Needless
to say, the map must be preserved to guide any removal operation.
But it remains that such concerns are probably not directly a
part of TDS itself. More like a set of unintended consequences.
--
%=======================================================================%
| 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 Nov 1995 15:59:41 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 20 Nov 1995 13:58:47 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511202158.NAA04188@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: nov 15 tds...
Alan Dunwell makes good points about the installation of a package
but it probably doesn't really affect the structure of the TDS
as such.
It is more a matter of how the contributors of a package put their
stuff together. I have just finished my first attempt at putting
together a Solaris package based on TDS, and it leaves me with
quite a favorable feeling about the Solaris packaging operation.
In TeX's anarchic world, however, I don't easily see how to start
framing the outlines for such packages. It's tricky enough
(and largely undocumented) even in the Solaris environment, and
it isn't likely that it will soon be emulated even across the
Unix family, let alone out there in the wider jungle.
The Solaris packaging system is very finicky, and perhaps
rightfully so. So much so that I do not see any good way of
reading add-ons into the basic package tree structure at all.
With the aid of
some sort of version control (I am still trying to find out
whether that can be done) it might be possible to put upgrades
into the package tree so long as the earlier file has already been recorded
in the original package installation. But what Solaris seems to do
is simply remove the entirety of an earlier package and reinstall
on a clean platform. If the remove doesn't work right, it sulks.
That is why I can't see any good way of infiltrating new stuff
into such a package.
I fall back therefore on a system of sticking all add-ons
into $TEXMF/local and having $TEXMF/local a link to a completely
separate tree. I don't see what else to do. That is not going
to please those who want to be sure that all TFMs are rooted
in $TEXMF/tfm/. . . especially if they have no capability of
using symbolic links. They will end up facing exactly what
Alan Dunwell describes, the need to pick through a whole
mess of discontinuous directory trees to install (and even worse
to remove) add-on packages, a little bit in ./tfm, a little bit
in ./vf a little bit in ./doc a little bit in ./tex and a scattering of
little bits in ./pk or other raster directories.
If every package came with a map file saying exactly where the
little bits are to be stored and whence they are to be removed
when a new version arrives, much of this problem could be
relieved, but what chance of that is there? We can urge it,
but it is unlikely to happen soon. Such a map file could
even make up for the absence of any version control. Sizes
and checksums could be used to ensure that any file associated
with a version actually belonged to that version. Needless
to say, the map must be preserved to guide any removal operation.
But it remains that such concerns are probably not directly a
part of TDS itself. More like a set of unintended consequences.
--
%=======================================================================%
| 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, 21 Nov 1995 04:34:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Nov 95 11:12:31 WET
From: GOOSSENS@CERNVM.CERN.CH
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: nov 15 tds...
To: TWG-TDS@SHSU.edu
Although installing TeX software packages might seem complicated, other
packages do exist, and installing different concurrent versions is often
also quite tricky. Here, at CERN, one of my colleagues, Philippe Defert,
has developed a distributed system, where he can test, introduce on some
systems, or on all supported platforms a package, so that it can be released
to some subscribers for testing, for instance, before making it available
to a wider audience. At CERN (as, I am sure in many other places), we are
running a distributed AFS-based filebase, where thousands of machines,
at CERN or outside, get their software. They can copy (part of) it locally,
for efficiency, or run from the central servers.
For more information on this system, point your WWW browser at
http://wwwcn.cern.ch/dci/asis or http://consult.cern.ch/writeups/asis
and/or get more information from Philippe himself (defert@cern.ch).
Michel
PS. I use this system all the time to release new version of TeX-related
software, and, although it might seem overkill in a few cases, in a
complicated distributed production environment it is a must.
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Nov 1995 11:15:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Nov 1995 12:15:26 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511211715.AA04269@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: nov 15 tds...
1) All my previous comments still apply.
You mean from June? We may not have agreed on all the changes you
proposed, but we did try to add further text where possible. I can't
find my reply to that message, but I know I wrote one. Anyway, I'll
address that below.
1) Try to get anyone who is writing to the new TDS to provide a
"remove" script for each platform on which the package can exist.
I know I wrote text to suggest this, but it seems to have
disappeared. Maybe it was in the now-defunct Martian section. Anyway,
I'll put it back.
Back to your June mail:
- On your naming of the TeX Root as texmf, I find your reasoning
Sorry you disagree. We still find `texmf' preferable to `tex' for the
reasons stated.
- Comments on the TeX Root also apply to the change from 'inputs' to
'tex'. What was wrong with 'inputs' or its alternate 'macros'?
Why should `tex' be a special case? Every program has `inputs' and many
have `macros'.
prefer to have a package in just one area, but such is life. Having
If there had been *any* TeX installations which had attempted to keep
packages together, it might have changed what we did. As it is, we felt
that it was extremely undesirable to specify something which had never
been implemented.
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Nov 1995 11:50:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Nov 95 17:50:36 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9511211750.AA00683@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: DUNWELL@jnov.colorado.edu
Subject: Re: nov 15 tds...
1) Try to get anyone who is writing to the new TDS to provide a
"remove" script for each platform on which the package can exist.
> I know I wrote text to suggest this, but it seems to have
> disappeared. Maybe it was in the now-defunct Martian section. Anyway,
> I'll put it back.
I do not see how it is reasonable to ask that package authors supply
such scripts.
I know something about TeX and a little about unix. So how should I
write install/remove scripts for Macintosh, VMS, Atari.... I recently
helped someone write a texsys.cfg file for an Achimedes which was bad
enough not knowing anything about the file structure there except that
it used . as the directory separator, (just to make life fun:-). If I had
had to provide a script in an Archimedes scripting language (if it has
such a thing) I dont think I could have started.
Having automatic remove/install scripts would be nice, but given the
portable nature of TeX it does not seem practical to me. Of course
such scripts tend to be very simple so it may make sense to distribute
scripts in sh or REX or perl or something with the hope that porting
to a TDS compliant setup on another machine would then be
easy. However you can not expect the original package authors to know
more than a couple of operating systems.
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Nov 1995 12:43:55 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 21 Nov 1995 10:43:50 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511211843.KAA07055@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, DUNWELL@jnov.colorado.edu
Subject: Re: nov 15 tds...
> I do not see how it is reasonable to ask that package authors supply
> such scripts.
>
> I know something about TeX and a little about unix. So how should I
> write install/remove scripts for Macintosh, VMS, Atari.... I recently
> helped someone write a texsys.cfg file for an Achimedes which was bad
> enough not knowing anything about the file structure there except that
> it used . as the directory separator, (just to make life fun:-). If I had
> had to provide a script in an Archimedes scripting language (if it has
> such a thing) I dont think I could have started.
>
> Having automatic remove/install scripts would be nice, but given the
> portable nature of TeX it does not seem practical to me. Of course
> such scripts tend to be very simple so it may make sense to distribute
> scripts in sh or REX or perl or something with the hope that porting
> to a TDS compliant setup on another machine would then be
> easy. However you can not expect the original package authors to know
> more than a couple of operating systems.
Agreed that package developers cannot be expected to know the arcana that
would lead to appropriate scripts for installing and removing packages
on a variety of systems. I certainly couldn't do it for DOS or Windows,
and have no intention of learning how.
But a map file along the lines of what Solaris packages supply would
make the job of the installer a lot easier. I'll work one out for
ibygrk as an example.
--
%=======================================================================%
| 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, 21 Nov 1995 12:58:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Nov 1995 13:52:41 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511211852.AA05429@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: nov 15 tds...
CC: dunwell@jnov.colorado.edu
Sure, package maintainers can't write install scripts for
os's they have no experience with, but it's still useful to
do that for whatever systems they *do*.
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Nov 1995 13:10:30 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511211909.UAA16866@spock.iti.informatik.th-darmstadt.de>
Subject: Re: nov 15 tds...
To: TWG-TDS@SHSU.edu
Date: Tue, 21 Nov 1995 20:09:30 +0100 (MEZ)
Content-Type: text
David wrote:
>
>
>
> 1) Try to get anyone who is writing to the new TDS to provide a
> "remove" script for each platform on which the package can exist.
>
> > I know I wrote text to suggest this, but it seems to have
> > disappeared. Maybe it was in the now-defunct Martian section. Anyway,
> > I'll put it back.
>
> I do not see how it is reasonable to ask that package authors supply
> such scripts.
I agree fully with David about the impossibility to supply packaging
scripts. The person who proposed that works obviously in a very
homogenous environment, or he would know about these problems.
Nevertheless -- we might not want to give up so early. While we
cannot write the script itself, we can propose a standard way to
describe the contents of a package. That description can be read by
scripts that install or deinstall packages, such scripts need to be
supplied by the respective user community.
I write this because we're thus back on a discussion that came up in
the context of a TDS registry. -- And I waited long for reactions to
my proposal for such a description. The problem: I think currently
that creating such scripts is probably useless work; if even the
folks on this discussion list aren't much interested, the general
developer community won't use it.
Bottom line, while I might not want to give up, it seems to be the
best thing to do. ;)
'nough musings, back to work...
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: jschrod@acm.org
Roedermark, Germany
Net & publication consultant
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Nov 1995 15:31:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Nov 1995 15:08:39 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511212008.AA14214@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: nov 15 tds...
I personally think supplying a make install or VMS DCL script or
whatever is only to the good. Maybe it doesn't help everyone, but at
least it helps some people.
I added this text to the new version, that will hopefully become 0.999
by the end of the day. Can it stand, or should I remove it? This text
isn't requiring anything of anyone. It's mostly deploring the current
situation (by implication).
We encourage package authors to document (or,) preferably, automate) how
the files should be moved from their distribution structure into the
\abbr{TDS} structure. It is also useful} for package authors to provide
an automated way to remove old versions (e.g., \path|make uninstall|).)
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Nov 1995 15:50:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Nov 95 21:49:50 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9511212149.AA15762@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: nov 15 tds...
Karl>...
I wouldnt say that, but if you want to put it in I'm not going to
argue at this stage.
Personally I agree with Joachim is not that every package author
should be cobbling together makefiles/batchfiles etc, but rather
should be an agreed `tds registrary' file which really just needs to
list the target pathnames in an agreed syntax (any syntax will do, so
long as its agreed) Then a single script just needs to be ported to
the different systems which can install/uninstall any TDS compliant
package (with a bit of luck)
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Nov 1995 19:08:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Nov 1995 20:08:15 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511220108.AA09913@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: version 0.999 released
OK, I've updated ftp.cs.umb.edu:/pub/tex/tds to version 0.999.
I made several editorial changes, but nothing of substance.
I don't plan to make a public announcement.
Sebastian or Michel, I presume one of you can take it away for
TUGboat ...
Here's the DVI file for those topologically far from umb.edu...
#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.1).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1995-11-21 20:01 EST by <karl@fosse>.
# Source directory was `/u/w/tds'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode name
# ------ ---------- ------------------------------------------
# 77552 -rw-rw-rw- tds.dvi
#
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
shar_touch=touch
else
shar_touch=:
echo
echo 'WARNING: not restoring timestamps. Consider getting and'
echo "installing GNU \`touch', distributed in GNU File Utilities..."
echo
fi
rm -f 1231235999 $$.touch
#
# ============= tds.dvi ==============
if test -f 'tds.dvi' && test X"$1" != X"-c"; then
echo 'x - skipping tds.dvi (file already exists)'
else
echo 'x - extracting tds.dvi (gzipped)'
sed 's/^X//' << 'SHAR_EOF' | uudecode &&
begin 600 _shargzi.tmp
M'XL(`/UULC`"`^Q<#7`<9WD^WYWED-AID@$*^2'!F6*;2+).BI/(3@.RG!A/
MXA\LR?:`H5G=?7>W>&_WLC^6+I2&H90&J`YM/G*SV"4R8-+$"71R+>"V0$AC
MQ02:%-K23H=.XS:9``Y,2<6T&9K@/N_[?7NW)RE,VJ$A3*493Z2[W?W>[WW>
M_WV^_&=ZV>_>\;6+-Z7PD_G^19>-BGV7.8%?#?S+<H.#&WISN=[^W,;<X(;!
MC^**9:F7\',&/T?2M51JZL@+GTFECJ3?PK\>W7'-5&B__=C<N5O^]D=^ZORM
MG^=_R_,5-W?UGPTUEE_M;S%=D?<=MR9'?#?(^X$K9-%QY>A4^,([/S&3.=YS
M?3WLVE3:)V\P+>'59R[`,^DGW-SWP-RO[;OO[>>D5D("^L?/[?_ST;&MC<SI
M>_:&9Y;O<=P#IEV26UTGJ$K'E@8]^&=GAS/I.\?PX&SXQGUR,1'6CNZ=OM_=
MVC.Z961=G7YF+OK[AZ?N2'VP_XF":Q1]6N#@H?M=X7HF'MO7.S@X&)[SX',[
MG.A@)"K1^/1(7;BR/]<M2:?UF4MW#$Z%KSMU=&[%C<_>7$N=#7'/CD7N:PX[
MU3N//UESS5)9^KR[KHO=NYK_D,?*^",S-C:WZHVKNP^U[NO*5[Q:KN_X*EP0
MGG?LOB96N;*[@0L'-\CQ:3Q+^F7!FQV[;B:]YF)L-O/DY#XYYD%DI8_>^KWG
M$4"0:M>AXT\*MV)ZM)M&IK#%=V3@"3RPG,H[U:@6GGGSL6YIV`7ZLF!ZOFN.
M![[`(J8G"\[TUDOR0478D<_@&794D]7`K>)SQQ-R[G4OI-9L3`KOF[F^AR=,
MOPS#"S.?.EIQ&F?>MZ9@KLQ+PX<,87;M'S6Q7/TH@&41]<6-3'"L*(3$LF7A
MBO%#M-62BQ5]4>@.,^][L.H"`[,@"A#.\)6$MN.;>2&-*DDD#&C`A"U8EL3F
M3.'UAMF_F=WFTT/;=^\WO/JG>&G36TV:U1)(,5EUA>?A$FS5K%0M$[].`#_#
MA1S2EZRMWOK=?/,HUH>U&&TE061>RH@.AF=N.6F8EC%N";9.TMO<ZYT__>C)
MU*N@*/J7A84,GA@>#<]LO&]H1Y@YO:E9=CQ?KAU2F[$+YJ3<(LL&'HCM0!P!
M7%Q1A';LO%C7&W;U/;/+$H8G]'8\03"^?^Z60'BD:X_VX06E4ORG4JJH0#()
M0YB[\(G3UTYVH.?G^F;]B5*/7_#>ZI6]H%<4`MG$8\8)>$;=-RP9/^%&P[7D
M9N'"Q=9K(7(#&TBGPTH=<)6WF8!CMV,4Y'JYRZI5H.ERM]P^%'8=.];7/W!5
M'SX?&QGJE7M)NT).1,+"=H6&L<+6Y_769RZ_YI3RM(L_\/CNJU+G%HL<',AC
MO%S_R6'']H7M4R0)1J?4E9=4+O_*[@[?\G)]7\_5PS6G/KO-]EV"KH#(`.U,
MW;%L_^-]_75L8XJ^;N9Z<=UUI^X=+0O:D.L0E$7VOA.('F%7<Q^N3-_V?+.W
M7F^L./D:]1?^D$N__8)^FPHOV/.M-B;(7PP)H(97'I0"3DF&'2Y[=KQUSQ(4
MKS#P[E;.^/5^=KNMPA:N8<'=JL<^.]!VMW[M;B/!.#EEG+HI17H(['FDOC(R
M?IA>_1]+4/^?P=4&I%_[VFZ*D<BR=HFB($4_WQ4B[)KZ\A(,KP"0!ABDF[@&
M,2SR%J-0,%54S#QX^Q)&OW2TKDR@=26CM25`:9DW?$%PK;2$;52$%Z:>>]<2
M6B\W,G%N&N#<-$H5J%/ML<1!P;ZDTQ!RCXMN`CGKVL_<OJ&=LP9TSMINY%T'
M"'[HVTL(_@K:P54M1`=TTKN!#<$&[KXW_9[2$JJ_TOA>G<!7Y<L=CMU35/CR
M#.8-SWW<N:[=)UI.R<GU/;K]^M'IDQ</W3!=']RY8S3,U*]I(EHCKYZI+%G$
M+P29P00R*C?&2M\U?<LC.T>@]*D?+'79KWSP-C!XF\,SM_ULKNL?Y9'=J15P
MI!5ZS'7U`]OPU4!_<\'8,NSZWJ8E7_J5A/PJ5<NVII\43-6(-_/80TN8_G*Q
M6K7GKW-][?+V2BYO1X)*Q:!:MH9*-O^=FW*Y=BE[I2YE%\&3^W[T_-*C^]U:
MF-[^.TOX_L_Q2(S"AAB/,=OC27_>7"D*5(=439'G-N,MO_737&(4/:3!V05,
M'->GMPH=K>/R9X>6`'EYP1QH@[E9O4Z@%S1PFS@&CHV9GA<PFNMWY'*)2>=F
MC>90P:G&_I5\L9"NSRZ5/"\+B.W1S&;=^&UW7'[;X]B(=AV#:-DYA?[7QY<\
M[G^C9M5_73]ID+N0IDWM-ZUTT],*BGD>-:/?NO?K_Y^5K92XH1UPAE7`\?1`
MWA72D&2KPJ?WK?S"6M;>0H'GY/FY]G"C.9P<5_&+E9@6,3WI+)GS+Q_C]J!B
M>.$@JA.P_<N7`'NE0C?PXIU1`L)PQ<<_MX3A+T;[U[2#XQ8.CKN%9?BJJ&XQ
M9KBPOM9,7'P]7TO$$68]\9R?KMI[L9D;)&[8&U*IJ3M2W[_Y:!.MTA\0:RZ=
M>FD_;TZPYHCW-?-\L8#_W)'ZXEL_V=1,L[$QE'ORX#11M-IL,R)^0;:9;"K]
MX52J6%QV-)4BHEK,O7N*'DA7G$0T[^WZJ>*Q%(8UCZ4^\^H?_9"_7SAM:63V
M3!,_258/;;W$09Z8D,(M!E9WF-GSQ"HQ:7)CL6?:E[5J)#SD$W[MNV?:JWF^
MJ!!SK-`BH3F!9]@%CS@QN-A!%I>&ZP1V@2O9"6Y5K$)OF`TFM_EMNA>1IO[]
MBV(2J;TBK)H21?4T1$.3;D"\)5L>-%T_,"Q<03P@!TNX!HDCE2Q>;]BU[?1.
M6\C`+N+^P`;>TC,+0HIS4+%I-I)3;&2F+EV@B#6>Y.V:END3/X]9<(<SAR\H
M.Q(Z.0BU=$<DZ=2EFFM&69:H6)QGA2UM!XO9)0B]G\A]Q'5:+2<B(ZH1+\JT
MB29E2=/O#9>__DU$%:.[M5"N\`(+ULGECRTKALV\+,_T!5T6':1M%LQSR&PC
M/WX85,\\M)*(&5'WGCL9:2J::*1?Z*JZ)O7G3-`[I`AZW%<PDR]JA2*BJ$'&
M@O#R,/N(J@<L8!<,M[`(KW!1$B7U*<UU&_5^C$;FTW>U"^6R":C<//1:EC7Z
MBIB#%7Y%UMW(?.''18>I89ZF'7[Z+K(7AU0LXV(PTJ6@:1>$)L.Q*A:*IZQ!
M"T+3>1A<X9$A0->[V\"J7!*1B;H&W"-O`/!#,>!AYJI+%_(<#<MS8M:<IR#U
M%*9Y1Q$?78,)DD3&\WS-"=,2+'2Y[(H>$@NWTZ8=4K:RFU8B@"7__J[1N/O+
MKD@UDX8&F,R23:1'F&;DN`>83PC;JC!Y3;AVRR.T#-O040X?JQHN]AM8AHM]
M;AU@TNAA(MAQ#V.3*N3>J(-&"UCW3G]U<&MS79@9OIL%L$S!\0GRL]W`Y\E1
MX>50*^K($SM'FMWRQ/:1GBWTFY8`GZ[O;P+L?UL]9IN3N&#/]A'Z^ULWDXOO
M!:P.M#'AR1,[1ILMYE_98:P5O=,H5$R;^*@&C,KCT%`0!R-A.63;Q'6%XL<C
MV(TLHDN(3=%FKV+:H)LWL<>%)K.@XP#*Q%$TJ!]7[A+[0P?7,SMWWT*NITG\
M5)MHI>/D<B0-K'UQBJZ.HAT[D[15=GW>(MVLHZG>4=45@)+C\.^=7OC,%F67
M]O';"BRWYE.3"KTXE0[N:&#;#)\6)&F-[)_2<6,J*7L).K3L69?"?&&B'WG3
M-A]7137E(&5A51?98L`LY)4J"9BNCH@Z+V@[Q2HEPS9O92*OJ5V,F;5Z%3,.
ME+:#+&G=;D@?R=D%FAO#[)&>">(T2YM&91XT0QG"\X")/&`[T03B9*E%U*PH
MPC)<@<W%4!Y$NGDQ=!`^OG3SMJ(6H(:EG*"1N7;6<#G3&!6D#`/[,H$T/URO
M5'6=DFOPYB041D`B^-#F-&<7VH8C#OUQ'C@A^NOX$9<FL".]9(+]2]7+EM[Z
MS(7OOTGS62]EYFM,B]?,UV\P4W7@Z&7,5#U]3Y*I.G>98L#.#209L-]$H*G/
MG/=LGZX3<%_VM>]:P'#-OO:*ILH5\`?*E;>JL*?Q8]^A&Q;HLL=5Y9?TG*+/
M90;4=QA+5(V\/,#<:$37B/P\PC<Q&SO.<^3!Y`S(C<15U[QC#]5)C8)?!:!`
M@R95'%6L0ZJ&RYJ5")\:MD!A8G4PM8?(61OINUZ]TD6\+ED&--X=IO_R+TQM
MT9X@;]")7@[#7UQ1%K9G(MXL8BE#;CXJ\W<[A!^IH+RVQ>1&]$Q_\FDCOL:3
M*+!66E8<H[_X"L;9]MLM6AB;MPT",5?!E]8FBM[-(><.##V:GOD=I(L8I
MP1U_]Y_$0#%MO4@NIV957$L0WUXMGPP7?*J`5M"*5WB2XJ'U6'=()NEG/E5$
M\H1PJ5E?K^\E#>5P^ID/$:>_+5'4)']!7+XE4*$2R`%-V/XJ4S\)*:X6.8$*
MO0!`"LL3$UQGX4I20"QR*^;"DE!/==WT7ZHK=@]GYK[<L:$P>]$87!X/UM63
M]".J9<FAO,@I1I2)(ZIC_8C36X38*,=-I->(%G40B50\C`+;]#=I"6!@C<S.
M9\@6P\S;EZE,B/"M>'8&,^$]47)%B0H#SO9KQ4&*4C8!8B('\Z?KXHBL8RZ\
M(8J]@1,)/09&@:?$F93W#O1Y':O68$X292=*7MTR+KKHJ$,B3GR#B=*("&AM
M#@J;<T/"WZE`..]^7?D<2C2IV-X;2OMGUS=7JUROJHY8)JG?-W!"B1Q;W>-M
M"C-K/D9Y2ZBA'C]DUA>3E>)ZE'J^UX3EON.IT3:B9CRYDE0=D%4DV=STG?(!
M**4@Z/B#L@F4W'JV18&1;DV,"A/VFOG.>?.J.KVWGYS9GW3FP^3,JV5)$9)A
MH15AH!:8G[NC.#7`7WYR!E6@%11H!)QY[I/S&"+3USR)8FAVRYYM(61`EV?J
MWBY&$U:*^A-@L>L)/]_;S2[^'ACDB]0,.J^@_/*$56S7(XCT3YVB3.B@:M^?
MM*35L?]TEK544^(A0#6@`QS8*C:Q,5P^_<^P1\%Q*([:;,'MLT"%[OD!&KJ\
M]:M<:GF;*X:J;`WR(LF'5<AW@/DW/S:JP]C#V&28+5[8-*;D35,S+\QMF`J?
M+Q8?&$*KFWKLPXO0`I;=]GS_U,RRV\[,G7W.D?'KDD<X*F:N[PNK<6?WQMYF
M<N,LU4391.#E4SC(6A%*&$['7E"%:?;HC>CZ37.:C4Y%Y2V4$[&B565*5\$;
M&**B8UE<O%)@Q0*<G`!1%0N3*=,Q,3R&7&XCS1GX,;.`G8P,4K_MR,>;-ZF_
MV`O0"4.Z_"'JEJ"]V:*IO8PC>J2#E_`95?WGA$L/:/W9VUKG>/EAE\Y;">3%
MO$1)20U]ZFOO/&YBY7?<_F!S-W\CZ/-&]G.7S%\=]U=#W&_D#T"AZLYF=[@\
M<Z[)#1@R"^<3I22=N^R2IRZ9+R]I.W?J;A-&8^8]U>URAVYP^!M'2P9_/B`%
M-;-JV,(_/''IKZL?GKID7MK09<W-+\/4I9^G+OH80WWF-1LFXBI*Q35/\!PF
M[J^I6?'X'!,^@S?3((-"`#2'JKC$!\_B1"J;],*#(OE3OH[D_;JVHV,1(W4=
M[^^\WZ63$:?O\80AW3Q!4)\Y__TW*$&VJWE"(U/V%VE^$KF>^AP'L17Y"0G(
MCH**RHJJM^J(!J8=)ZU$RND^G*EL2D;^"$]N3WIF1V_83@IATAS5%>NIW;$6
M;<GL*M3`[7O]WG._=GGB@-WQ?X'B'/@/^5=[`,+]5YGF`Y"68A"U8538J3K_
MQ<I[!+QK3JD$7C#/S7,A3J,0GPY)VG$E.H%2L)%MOEH)3I4_#[YX2D/?=61N
M,OY7#?/'?+TM5-IDY&50C0JL1I0V=$K5%A-)VVOGQ$1L?>8'5'`\]E?M9WHP
M$ZN@9@*0EKHYE,>T44@"L=I5!`I)4>&SJH7></EWKU"''[EE0T!T`E=I2+@N
MG7&,^QQ5I#O\YM.5%3**S@?37$HW)K0W&E)%(@&;:HC(CCV*713`$KD*?0X>
M2>W/=I\RU[4WZDE#F+GV^F91``5AJ"#441-U;)L.=K9KD?8!(6X<LZ:S&:*H
M;BOOE.+VTH@'@6*2./>F3S74R6<M)#<.9+#&A$$S;+P8O^PE@0BY*"%%8"L?
M@13CU!<O?_0/A\+,R;_C#IZ;B0G3*R=F@*TJ]E8T%(WT#\LTC.K4+<3?\?@0
M1T95(**O5!T\U<10VS(1"\Q-BNIJDW)K$:OQ@4:]@:@<#Q$,O\S!*9XU=HQO
M<9U!XS%R)<NQ2]V2#<A=A79:+2KFGVGUL`4^V>K12<W6`$KW6["V[L/9+YUE
M%AO9ZHWSE4P.U89#TM9@]I'6%RT(&R0KAJ2J?6&OZ;`,O6$J8_06&2T$!TKJ
MZ3MWDV?XG-/H/*E%ORQ<0$U:>7MY&C9+/4#,/3*J!A,)X`T4IQ71P^U[A0)N
M>^"4?>R][$\]T+\-K;"?N(9J299?\<&X%V`?F3?B]!2D\>EDI<_6'#FN;XNU
MQ(PQH<M&=N=WN$+7UDK3)#>@1`W_"U<8-^QL30=E?,HY_IZ*E96E()8S6_=-
M/]XR-6YFJS$GCZI43=+<84IPB:8>(=]6K9,EV".B\<!%J=`R!5A=3]V0:N0-
M4][P`97LV/T/9WH^V(085%+'Q[K5O"KNORE2<FJ,FEHF;['Y'>D@J*KA;.SQ
MI,E&=NI^&@^0E7-G#)-;G-AQ2!$[>L.S+OSF=HY_^-I$S:U'Q=GO/K0`N4I$
M=7O%.$"A,%Y63=YI6"$:Z:\T&<0HAM!89(3=W4C_4]>BG039%CV")VFD%=3L
M<+E6%]&FI%!P5+-00R^W4A3FF0L"WR=^@]^PB'S@:MU:M;@.X5@(U1QJJ\:,
MVWR(W587)S++B1R>HZG_*X#*!.TI/'QH_"L[::3?R*R]6@UH\*2?IWG81NXW
M$\5$2\Q(]/A.#QR+CN7`E^/01HD7M[1&DGIU]M9&9M]GX%(<0`J4";/O;>HA
ML[#SR(*<*UMXTH`90+6=<#$Y(X[(>D:DF%N=L_\XA;OQ_(J&H4I!4"V'X([^
M[='/\Y0M\^ATD]MPH>8]+7,!E#5EY)/\E/@+$B-6#H]"V^)!(T^?&->)<-Y.
MYS4_V#/W'XEM<Q'EQN&+7XY!MVMI.#.BB]K-O?WKYM6G:M*PVT%YJH^)GKXG
M/B::J$JI,?]Q<][0X4YNS+.__N$)*>AKK\S)@E]YM%ZRP-1\-9#,_/@CS38J
MZD7DS6K4T%PCUY*2]B^L_`B*V+^:L18>37C:ZG4PD)T;=:^7_M']'/`@'D'8
MRKK<E*D!57L@2=DY78['%3J+\)5Z/M86MU7J!54H_CXHGB<<L=%`!/<;"-<G
M=@W+IBUT1>8>X%G!0T6:=HW=%Q?:W-]'>8K54<6H1CRYLIP2O=6)XKE#U)Z.
M<,"*XV+`(8.-%/WFZ,9F;)4C:E85A[Q,SV5<K5U^@<6`&6V3Y_(YWIACJ\)/
MO52@MR>HA7H*`N9*K^T.\=0N:W3%[P]48:P=2:'KM`I16O">32M;+RDVA9EO
M?QXK\*1(IS)HY,L_F5T?>.YZR\&.U\-L7$&CE_9GG7^MM\QQ%5!#/'UV/=Q7
M+TB#ROB-$99AU3AF7G2X:CIXFC%5IB:;-'>![N!SCH=@R,Y)L0D-(3S3\*CW
M#[/I\Y!L7+$*:E)3)9JBML?,;072U(#F)Q[7'W$>82^DC]FG\KO_N[@W`9"C
M+//&0W<G!`R@B"X@'@%=9G"F)Q<)#"XP.1E##G(@2%RIZ:Z>*=+=U79U)S.P
M_OV\7<&8LJ"MS:C`XKIRN&KC@9]X?606=%>\D/UP70WBA?KI8CQ0%_F>\ZVW
MNGN2\*WXWUW7S$S56U7O\9R_Y_=@MJ8:L=J#6V?/+_59,:JW?!=W_@V)9MF'
MFB7,EKZ&OX^TS";&Y%SI:U2_,6NMQD"$$:M^"EF%\$(8M9HU[9D]-<,A*UC`
MP?LHFL]>%WG%(#U9=)&S1A$X\.Y2<6BP2S`C#--5)3='LYF=!I2Q-,+LU*=Q
MY[6R4S,5AZQ<7"!AJDF<%O)N:%@TUEBN3'VZ+5GK>"*>LC+N?>G`YAL>)NV7
M6)+&"J0046V\[A21F27WFGLU]L7K6(*E1EO7'0?-70'1UAWP6&H'/')'%O`X
MY\&G/^#Q)2HR!Q%_,8IX*C+_R0=-D?F>&Y_MGYRDD;(7GL`S>N$Q[8)397VV
M3VU88U.I-PPV_=ZT]XI>*>M!)]H!5@:FJ?5AI\/$7O61->(ILL>%)E@2<C".
M?"M;GB`QY10*?KU(0MR7G"1%[ZH=L3K,^QTU$O/1I*1.)!@5-#/J:'_($[WQ
M";A,O#QU/GP*;-5;F5OW[JCZU;+4XY\.>XQ,+-R"Y"?3\2^0*E&/V=K;A\[O
MXM76YCS/;#Z?+:T5#?.&%![1M\*)/.3[@+505^T%?[;S[$45U+(6^(1TKAW7
MR@H6)WF<_)Y;3_CD=:DPZH,KC'<>F9C#@RM$^%9<>#&T/P,2J1VK'W"^VGZ4
MRF.*FH5S?U5>B2;PA,/IA$2E>&224>3S/#25*9TEKBN!;D1>N'#,?=10>SF5
MWY%3Y'CN.\(7GO+&Q7D\/XL/?&!D.G-Y73/LY:E6YO*VB5%0T0P&I-E$QY`T
MNS(&^A&IC,Q\*$I)FLQU\VSUU:R,P:=*/+7M-%J9G9^2_,FN&_A<-Z(I_"T(
MU`U.$#@,OVDBABO`W\,JKO2#!LC+,'?&HRJ<9.L8FUO3YGN3#"O/L3[:PO:`
M=X#>8$72-I1"B^'N&$[Y+@\F+)9(:#Z9MB5FVL),X_;$,\DTOH\*M@C6'&OO
M,PD7P;$*IX9AT[J'4\HNP,!TYN;[4H%'CVV0NR;NX<1[..>7_QM#UW'OB+9\
M#CE8&_$NR@_`MX5'/?L==WE1VW:!8,<5FD0+)D])I0#D(U&`G+K$H'@R&R\!
MAQ7L?\H`I]2]/!N_%W<E?W#49M@(*@Q#KT:J#2[5T_.*EW4:IO;-9'4Y1:>&
M)\/V[>F@@Q![Q2?$]*,\0]FICC=A2O)%F&D<0-X++;#<*5>O=!C_TQE@A`?-
M2+8CR!=*X_KB;J2_305J\N&\SZ[87F6L$CJEJ3>31^+[M3+OWBC9T8XG2A"P
MCK1E55V"5#"H,Q:XI+9M0KP9PL\%J2RFRL*RKD3R<A+_+(`-9R+?]%(I*4S3
MB4,B]9H=5<(H5=TE1C9C/FX"792I>6I>.HS)TW>PA!O:1E.P*3QZ-<E*ZEL,
MM#+O6^+FQ_-@U6Y>CP.V%45'S&PX)3,;G)WN-O>RS>O5M&5+BS_*&_>J-!Q%
ML</LY/=6[_)J`9DJ(U$2O>2,`*UGZ@UDDCF/+\`7E8<+#]QTUPERL-M&W!I,
MH>T]R/+14B89#S!92V@?@L40(2"Q`E94-%[VQV@J,-N%H:5^5'A=SV/3RRF#
MXH</E(B1S.\A'VG+#P&TV5GKH4:EUI[ED9+F\:O%!%QE#PWGRV\VRIP1)67"
M&FFV+^!T#2P3"6,U3#S:O8F;T,>FY(13"_1]AW8Y=?!K[+`)_6XHJ/E^6=+O
M_;H7-W*`'RT9O\Q[F=`7$N"TQ*P&+4@[@K]_VOG?,,;@,C(&+0Z;GWQ0"Q$M
M8W`U`S`(>9-[X6=I"^E.-2D"WG+N))PN#N\3FB3WPK>+1I_WM:-4HL;M)$\/
M)XSG,PAAZ*:IHE3?GD[R?UZ-FI<L1=1J9-'-\A:262#KG\/&UK24$+J&,8J5
M@6]A!2@(5&49@ADC!B:T<M4/@6``(>`YB%9"(!SX-YX$@-&M]=BX\1J62T(I
M\]<T)6\2'OV9KU[DPPN32PF/_G@V@61571,(U;"3^$/[3#A4XCI)1#316AS0
M=R<+;LU*47=LR(VXEJWLP+_WPG;921]"8L'::6J$O@'M6IA1U\'91,25B=MU
M1-5@=#EPMFV#1N6J#R=_&!+OL#TPG5VW'",M:'#*0P@:;@_3!G=S-/3R;GY`
M,4!D"G=_A@+T<`O*P]5P;&6G3^2M8OA6DZS6]-R5?^S3<-C2_&)C'@2LODO-
M.I[B?'^\;0+-*-2\=[P^@8OS<P<U-XX`YWT"<-Y+,+67?9.VH(1Q"Q*>SS1^
M8>7I'2LZ:G8NQ55`S%<E3IG,2M2V8H=J?_BMW,<6LL2Q<[KAW&<\$#2/QPA(
M.'_/P%8_ZMY@$ODV@4/YIC16&[]"GJ4NH'P-PU]LH;7+<T#,@P2"#1^QVB)7
ML,N,R??:KQL<#"1.3>>6_::$7A+#O/`,QQ-.!`M*9BDN88Q+&/>1)FWERM^9
M(9;>?&UGNW\`YC4VIA[:LK+(\=+\$OA?^10M\[W!3`89P00I*W*2K@FN(3XQ
M</E%QJ*I6,#:,6SO&(ZNB-\D85:V2R&MB<8X+L%:*5)2!L.D.*52@QX!.K/&
MH5HO;72HPR,ARZ+*:]K%G(0K>SLU!^!'C#1K)NYW-1$3PUW!BF5VL&+ND04K
M1N]]>H,5LXBQ>T_U2V%NSXHN.I\GGVA;LHR4=DTL;T[@>XV*4XO4T.J77=]+
MV"6X!W@PUIS\\K$.!-R\E^\;K6H5`CAXN5,O4Y"G@P<)[)N*A@30.>=L*VAC
M!MGA\B,NM8FXGPV*_)<]B8H./;+I[#^=6L`#@'"(H$R<TV7=>VC?\GXD3RN>
MJ36KA4:^4L+0W_[U,V#F.M4R_8QQTCCP8W06Y_[-7[#[$:?J`2QG@4P*V$,E
ML'L]R@VK<<%@SH!!J;3)Z@QM(G\(A#I_I!IM'(_P4Q,LM+^,O%E*R)MMX1^_
ML<R0M.7N'%*2MNF[48#MN?&Y]UQGX9J/66[[<FPWD;DLL8.Z3[A]A!IR:)5S
MK:`7PCE[SKG*KW?`'0^-+X&%?L=5(V'NF/E6H(2C"S11%:_!UG.SBC@1V&@I
M"*?A[1XI8[)V?**5<;Z;$`,X-[=9)2&0#ZQ=C""@S=P=8N/@B9!`T^KX2>34
MR"ZNK^$P?62E[U`+/*]`./M6[O/76S$;C!:9E$4@@`=*L"OL@84.ZQ5:4=NT
MCMH61EG#2$DY!*$_7W^31"&ZYQBM0E"GU[5=-?G(%F/GP6,<4()%1$,/8SR4
MDT^"R4FNHOL%_+K$;A6RTK((-0GH2_L.)R:-:>#$!FU<Y!!'!9C*]:%!-LNM
M%@>(L4W9F0`9;4$(T4@"T_NFF]J$1P9!V34_+,@LXZ0_@0;.D"2"$<Y_T3X=
M02C0!E-0+^O^)?;]%;?AX!@PQ(8#H0[15TVHU/JCV2C3[$&7=@Y:\X..0;M(
MP'H,L\P>9LP;X^E9=>6[=9!#)S.ZOO5L>[RB7TC/-:5RB]T5O?8(R^T1&&IE
MO5%FQP_Y=^ASO^!QCL`Q\B$P`4<;5*[(7[FK(Q61V=-BN3RVI*"7B%`>]Z6P
M4%00_W5H-U[:[J=TZ!&!<*.98@--1WV^B62.([BI8W3<0)/B:L([R/>W<@_]
MK.UI\1O7295\$0P"U45+!`T.D8<6@H6.`TG+67'1YX5SW[."L1=H9U*HJ)6=
M]S4<4&%C@BZAN`476EJN'BS&*Z:EGL!*]#SWS3,@R+QJGJQG.ST_AJ%Q,+!)
MK,ES4U/1!N7^U2\*YJ>5>],/6)*+B'*B'8+"@SDX78,3(#`X,&3>FTI`447&
M.&6@G$W(4H+]1/\S$*%#)*FR9$W0;:+7'QIS`DR,@FV#B"N6BW"=)2)2X&$O
M36(S9W^!D,/^(V_A@W#2+WK8J'TR;9CSO.3Z&;>".P$DY\*OS<B>PV@9WBR:
M/9!=@/A&\G$QYJD>D5A@K=P7_Z'HNA@3#IH<_Q$`)F7-+>A&Y/?*FW0(]?GW
M?X+:C&C^I6HFVFP=V(?%Z=S_>(R9-+@X&IZ@CXKD<V%U_^7?P!6+)F)P&&HW
MP-M&?IDMJSZ<_SR&7MK]9.I7W`IXNG&Q"1:$YG;A87VRN4J51KN_-7?NE\=]
M,I9`[;[F)[A/1>,0C+"+'V4WNES=GE%XS!OS6QFJH7.IY10K\TOM&)'`>T'&
MS++D',<*4ENC1L!R/QJO1T[%[(Q-U?^DG9'[:0UL"0^\001`=+T<"1TYLC:_
MBV5_EWHMHVHFW1M29-?*W7BTM>N.GOO2F4JIT1Z8SCT6S!0QK@F2*)R_\3]&
M)=<3J\77'HB-(M-_H_YI(Y"M&*DBD6"$I:;1R[-#>7'%`;>.BX@"W">P&<@P
MPFH^+#5BA`;6;74Y3V?;SM.\(W.>7MGX,V1ZEPK8G/F,]]SXK"_<U\TD,,WY
M_8??R26C@D]V3,",(L@D9;K`NA1?R.7>:XJEE$V@H]Z&XPF\:5(9XB33J^F3
M/JX&Q>J,*_FV,_'1:"#;RK2'O4XB%PX88D@Q`A>XI29:DS,[\+BV!TGDV'D&
MKG=/Q#U*V8Z$T\Q0KWS3S-">]Q]_X/O)6;)O@<49G7ZRS;4#CGXZN4FV8'W-
MO3.P\6D'8^Y&_D%B!/\!/WO5DH\*F-^1K,Z3_XZ3\2>_O>U(RBI(5PP;>1A9
MLAFUA4<J18-D6)5L0]XC#J&$V1=_CCBS^>D#B0^\AMZLOY5YW5\DF&K>&/`\
M&;W,OF09K)E;'^L%K#,;H0DZ](@$O7R]0KE^867,&@+<WVNCVO5[]4,)@&HE
MY"DQTOGZ/3*-*C'@DS`?6QX.YSK1&-(??/D\IXA(&44:SQ)0#2P0+]HE6`:P
M#`&YGG6PZ@Z!#^#!NV/,K'`S)QRV$CFJ7.A8MG+GO[/K6\D1TY0OOST<Q\GO
M4(0()@%=-WG-"IM+XC9A4B/)<<MS_+&@``ZHUO)Y=7H7"D[RV'G>]68W;M_.
M;@WG1?<1JT!'8+IC5J,V!:N&)6NR0J,[Z^`,FK!P./?XSY,*^L2DI4X82\RE
M&W"N(Y)H^&ZD/:F*!#>9KGMRU&0/XR.J(`_R8LS\U;MFR%P,&E.H6W+C!]9I
M+H!;:#6H6F7%S5Q$2&&;*=V_]#+-0+X7HW#CC/NB.`XMW#J.&UWVVLUX<*+>
M*$9R0,0.K;M<#2TVK;5G9?;#W#7G:YZ?:V]CV$!!@X$P/G>-6B?9U^S^+YMT
MB35K%#J@J-1LK]4G5CQ8,*D<FC%!P?H+LP=N(WDA3X1+@@9J8)Q<JA`BW6L9
MW%KM*&*S8^D%X*=!Y.YD*CGQ6RW8ZI+\TD0P[I.H_/!&LFF77N>4*]AXBTS1
M*7,PX.]LLBO3`"/RQ7>`!>4B[A["(+)`JDFK,PZ7@3VVMT;6B*+>K(O[R!V`
MH?TZ3"5LL[EGG+*I,T*O8!539Y04K,03),TT+$C"M0Q6T0E[3&B>`;J;_*HE
M7[&3V"=>@8@L1A7<-6*6><.>\)B_N'9K>[`;#1BG`!CT2:JA8E5,%LX"H0Y=
MG^Q9M4W[S&?LI;J;`72U"@X*E2-Z(5PJ`LDW*`J9[-I\A_;MTL\8?+CIUT8%
M]W`VTS"U7LIYS!ESRZ*)P1K;G6CB47`"KWE"J_@E'&\4/6&T`@XKTFDSU>$+
MA!`)"W>K/NC`2:*>F.K480/V_D)Z@0T_P5LI+LB!5XE+86#.8%C,EIWNW+("
M_MU40G/6=8KX9N;J&*T9<BKAC/D;$\=970[>#M.9KUUN&0:MS$<N'Q?9E?92
MQ6[1_V9I&Z-\ZW$1/G=(71OKAO\W1=.U#0ZE;=B/GLXM?Q.IFF.NQO'PEVEH
M"%;6.1PD$3$2&S"N1$,-A5:8&SQZ9G3CZ+8UET5MQ$,FF@<-4#JH'_I'V2;L
MX<V]^N[.4,5T]IY/:Q!!`1='%MU),2?P^2UCO$?]5'@/`<(0ZT"SKA;,6-/C
M6C.$=8!D5.L_MFU_&H\F*+VSL+ZSETR?F*K!%&"2M_]_D%A^P;68/J7?LA]9
M(RXG<,!CTB6QW,([(,R]^DW;*!^&VHO(:VJ"I*$9IZ,UQIE>?!S/>YL4Q2CY
MR*0"P-QKBIO?B7(G<<M0!1K,RB08L:9VSP>ZO\^KX%G%[]NXE[[OXN_0KRP7
M>""V,KQKJ@6G%C0Y+KLYAI?;2FG1"!UKBB%6?ZU)`@XMR:=AQ!L#*]/9"VZM
M4H@?P_U-4(SHM<*C)379\,5[I0^)G=A\JB2(=I"_?#J(@E5/=NV>&*<CB!D`
M"T_%Q&0K>\;=G)/43`Z(,?0L,,'2)-6#14KPA9-HR@OC5Y4GS2-DHG/!2)@]
MX\,5%TL2P:JO,+9^@@B0Y%$T;:W<\W\G=C,I#A.OP3_T-I[$EJ5-9<CM$MZ>
MOE&:*+<.[UP"LWCS0CIJ\#=W@[,3">'D^02"#W.CWP-]D?F/#]#CIY#M3ICO
M`NRKFB+2:>>CT6K4N<'"S*];A]YC\D!:(&7,.*+-=E@#B2:D1PBIE]G48_R*
M%Z#AG;EW)46V;_E,9[$P>Y6LVCAAEB@U>,KR&T:J'318'1ZFE'1CP+(NTR!9
MM,S'Y[)82ME$#(#$1R#;6H>SRBZ;5R>H1MT50,4WGVLI.(%3TH=U!VR6VP&;
MHX\L8#/^T3]+P(:KK];NO:-.Z9T;3WI/C4,VPAS+U$=7'GC*89I,N-\.T\13
M9)`HP0/]O80N1:306?H5[BN]I@3V1A*PZ4/@HK'UUZUE1<-;WLJP&6@T!:V+
M+FR!<J)1JL17P;NS,QS#J#U0[(VI&G%@3$OPI0O>.R-71?B*(!0Y0O-,ZC\M
M-B+\%<V#Q$#\J_ON;R>\-:Q@:![)B<1YX*U-R</(MC_BGM9'^@&',CV<4B4Y
MRB-%7V%IS.58<4&)%X(\3W2WEUQ*[E7)H;<*OH%A-3T>7-N9W%M3J@XR!@YW
MIR9"]&Z!4"2IK-GRA`/$D,&53S&7A@=2=M3S00U[;GIAO.Q)FOU]83'<Q=9`
MR>HNYL4-R#6C5!2+W=ZOL\N:;>$OU7<PR7T$OX/B^,,F(N(![7K<9D?QM^37
M)1@!5B%!6M(E@8UJXICVP4(388P=O#*1&H/SH4(W.']>44&>OK0&[T_%^M/'
M!3YNXT,OQMV?^=&S'8%,2F&?E*.*).#$ENT9#</^A2V+>R'SQ$)T$"ELV1PK
M>P6*HVPX&LY+"`,SPN&'OTU.31IC0L=GKX#N>R#VY0#UT%;T4%T6/(DC%3P'
M8)ELP,09&A^H'+>2EO1<.MMG!CV=3MD,!7B7=&W#GR(^T6,DF2BL/-M!5N/4
M%4AV">8GR&ZUWRE0K=M,_$LR1&2&0&IRO+5O<3]5]KM(N,`J44-/5!+5RCYR
MBA6,$)3<O+?3#%+=7QTOZ5O2SX0B!--FT##(:0J=\%GAX##=28N/O<J?=])H
M0P-8\E2D=\Q=\;&"KZ`-PG."B'>HWSQ_:-=GPA-@[/=>7$6,<IW;A$O(#[X<
M><(29DBUB?'X-WC_\Y3"FU0H--!CTA'X#:Z>^WIR]89.M&#Y@PDH7B=\(':"
M3CZX3EZ,<-X?GZ#J5PH*FK0C3CP<=F4"+ME'FH.*CO!UI4ZGZC=27D9!;?S`
M+:2@'KJ"%*64(#N6JD)]'!&#Y91]1N=.?6.F0&+T]SMFW&;9K5,8PX/CA`LW
M]XF'\(3"N)Q+>.C<(SVA/=X3B=L.<5(+%1`Q.]I]@JHS<@),BR>NT-.[XNQD
MLQ?=!9+1OD?1<<C\^VFT,;:UGCSO;M&R8NW#.5KYVTLCO]RLP!?E/[VFW?O\
M8GJEE?G43WJ^R4-S^$T0I9>\B%651I&G(_/!Q:SI"B3\:<4*U7;[%:ESKJ()
M[$9)P+N'%26@#O[JH1I,IU]WAFI5!,N"SDUB,$FU1*FBEQ<J0PRKG>5*5+9#
M)!B&F@V_YL'`S48]7RLY6K@B00ZP6S]KZBN,-",3D[RX?;JI:;>SL0!&Z&U*
ML7K/6N%2`\W5?D1-A/7WZ`I\>9!,A$809I=\MXT\!_C$D1HAXKS):'5_MRNP
MPG8%YA^9*S`U]O2[`O<A2GGQGG!%]7MKR1FE?A%LJ*%;,'A6MUN07;;!LN24
M]$5J)1)2($0U%RAP9^,2B.^`$N(,1D[C-A&5QXQQ"U!N#UM^P.+^5N8?*7Z6
MK"**JJ*[RT/K@<#[8>9+%U;\N.CV"U)$<A-L2*-ZV(UR5P)4YX69AZNHEH24
M6P&HXH/S1Z(!]MP;Z!UX$I(BOE;V\6L-0YM!Z"Z\S"`OLX\[;>,-!:KGZ*`G
M/.WR`88#KX/2LYN]1\\KQ<8K?A%^@Q!)F&C8@_N$!#A:33-@\I@@8&AB&,>=
M/MY_]R%0Q221B,-->8B(;"%=]FY-DJ9R;[L'KEJZ:-'T4;?]4['FT3E;OFA1
M#/_NIS\CU$AINH)F0BZ5C-7*[MA,"4N;G#FIJMBQV='I8K.<\U]2]9)[RZ<V
M^D)<S344G'Q!5!@\_Z]/`!>]X!H:'T.ZHC[9K'P('OM?1!)MLLLF(M%`\KM&
MU`W*WT;LFJW<\G]$]8^5GABJ<,>5PHHWC`88$:FC%(D]MF&")8\UF'OT<SZS
MR7!RL*'0ROSF8;;O19,2'9?RKB)&O6I<82GI*W=C+H?VM].LH>&<>Y^/2WC,
M3/K%$CK6S-VWV#@YO$S)7F5[9/X]+\42L$6P7@(6[/R';7HI10<6?::Q2:J/
M4A\Q8$AU&59/.9>Z:Y5666$'/D&V^X.!B*[-&\W`)H7W&DK*.7055W(*"8R"
M:Y+3G'^-DA.HS$N_8IA=?B'C2ACRK]R?96XG$&"BK<(.E.P-E@C*P+^5$)@\
M@A9KD%"E0]A9!\7E408H7=L9<8P$?/>>RKFV$^,7%1^-J^)3BW+`-,$OJU7!
M><T,]=#/XZ4_X?"6V5KQ0QK16*PK?W`A6:PW?<91<AV1\JHZM'0Z+5A3QNO\
MUDR!$O1WOGMF/"B!/;&3$#)7E<"$(?MUZQ^W!TV3IS<F*Q+ZNS\3V6`S]G2>
MI]S[OM)62:5'G5,@%(_=O)XB67">;[E.DS/&+*RCP*X;_)H#7_OC'XM2%NB3
M8X"^S+-E04VM>B+,KI@8]S0,DA!<^\T&V$\Q3Q*Z1L=]63BIX(E=\]Y2"SP5
M#.2D<XK)WARM6K"$YU2G-P643J\X9E*/^5T[@;2#:'GL:[VUL@9G['#!A7/E
M)*/+._<N^F')N21L-D]?B3^VS^0\%X=\BWXCL'"C;GTZ\^C'0)*A(!IH99X<
M)F,BJGF3<,`(K.G68_D[!A]^)+4MIL*!.>GU^@BN!G>I#+Y0`V\,XJ;4AE48
MX!%3:P$%Q)14%3$O<[G(\%Q4IE2#CN(PY2>*J.W67,@I7Z:=9C@\*",R3F7F
M?KQ;<=:4[QS:*DI_'*ZSER,25GA>9/`5"I)00I=5@MYA=LN!+A4RL;P-RKLQ
M`=^-K*N<V:A&U,9!B$>P>)$LM6SM_1[8DCOS<I:L=^D:]_W/:A,,1A!ZO'4C
M"EZ)\(55N?,2H6I+ZDZ""I-(PI[71#.U36AE]TW*)%H;C*("D2FY;S*TNE1O
M:I%)Y%0(PHW-*@:FL[=_84*:(7'C'Z*)VC=93X"T;'JULE>NLO'/2!LG45U6
M#USGNBC:OWKO9\]%%O`K+R06<*IJU.PL\:E971[`S2#Z/I(*\KP24:(WB&T1
M$1'1A-01HF$0H<D:.W&I>?75B#2]:UY[T<>'VTM>$I.["G_!Q$HE:E;PKXO[
ME9<#=@9LQ?"HW+?N\@SG5X]ZQLSC;R=P*PB"",L[8W>R@62,\#?,&N)0X+!Z
MA9AU7QS@ZU40-?^,4PPP&A5JK`HU3AH0E-3WV+Z][(W5,6ID`K]43%I,&++H
M*4;;*HUM8EBX1:2BN^>`Y0$M(0_H4MB!3MDK2HV+AKIM/X@.SCN^9WAHW_%`
MVVRW('D%V3O!!-HQQ@Y#2(8RJ8*0=HI<R(8)*Z)SG?N\*F8!*.,'BS^9$$6A
MOCNYPF54#6'%#%0.D#<C$I+Y8NE?5AGS;%2[8>Y55R-YD4-*TE.B'K6U3)EK
M*W-P?9LAA?M8[B>&'LI3J\0PIM9"6[`J,%J\*`2GH-9`/^+L:Q8O@H^'B=)J
M7KISR35+M=I-4&WDW6AY#*[$DOPRJU@Z*4@UTPK3(%9@OE^-<-*HK>R_[J8]
MS35H2)+"%9.PYWYR`=M9<+9ARU%D-(7X5`4=&)JUR*URUCQ)/2=,3E9@NY7]
MZ)L3QJH).>53PI8DKB>8(&?]90H,)M\/<N6^D`([B61BD+D]>4H)&'`,$`4^
M)S<M#9EN0O3X`?N]82K@P5-*@%J>&@Z/ONL_'$;^N%T.NU!QE-F%#))2##)H
MDFU*)##_:Y[A&*$MUV48_?Y1WDM.L^%+%!T;NFE5.$MELJ^+Z3S__$\^-%KB
M]A]L'G>%6<ZQPRS''%F8Y<V5IS7,0N2B^Z@I5RO[\7V<,7:4I4HF%'.D5+:#
M#^#"G:B/PH5.(RF%[8\L=U_U@0DZP:;^\NUHPIF8B<YB*_.]=1VKKS7AL*T)
MA-"L)SL>3N#ZRB@5%8$#][N7=V\+W)]%)7`4."HS7J3<:^MM"P+H$)(6V%?Z
MV.Z)$+O!.H)U%S<:[.A;3[OW%2:'S?1R&[F0L(&$(@?/>/QZ_WQJ<D1='\K^
MN+]XT?VX`3_]Z1$PLW?OIAV8_]F7"*YTXTE+7B#D]R!S6YF?_K'+]'CQPW:U
M-[6GD:RDW;K)M(IB3]W\"3^%D$438`+"3!$_-N?%;>;*[=N5_$JSU/EID((7
MV>:%X/S=W9%5.FE7PA1]QH#DXZW"US1[\K[#0=32EMG*$&Z>%0-)?D&'-^3T
MK.?L`$.F>71F*J4:9?;VO/^9IYQ@U[_^*2!Y=GF_0/+"[!=.ILS8[=>F,'#X
MYOOL-_]^M6T5K#C*1$GSR1D$3'/D;GG7P1?3WM..(_-Q[P7EQ8N^`B/&.MX]
M8UP-Y>_D5Q!FK3TW*A33H<"&8)KQX)!+[T[6ZEABG^_U0?_/L.:ND1B?HP,=
M?A$#Q>H0-WHO(&KG*HL\$%]0SC$S`^DIW1S.>=O;-FW=EAS.SK+>S-5?H:SR
MR,_`"?8(]3$(8EJ9U92AS/`1\E)A!.CE_D0UNL@?&XL%KIJ9.BI5+1FMK\;-
MQL29@<W\>ZO*4YO\ER&`'(>R&V@*;R@[4.*HI$!Y!U]RW>#C)YE]<G2A4@@*
MBQ=]=7."U6M;"",Q035$I/O3+G$F&2"5G8&1GE8@S13*?9'VHMR+7V%*N"UR
M\-[RX@.=\@++WV:3%Q^875YDGOB+V>6%^:JS?]\6Z(@AA,MM>]5(U,#[.=J`
MU?(D`I'GB_W;JLL2$([6\9\9,PU2R%27=VHS]%%]"0]E=9.)9V"]P!JCJ!OU
M0_`91<@%$)*C2P/$N*L"$WORA.&[-%Q#'E9J4J-.9;M]6B7:=';EKTBBG;^C
M2Z*EYG;W!99$(_"H(?<3L5.C$L>2_=.8/XDG%_XM.X$:&#QX.9/ZX1_`//O5
M`^GR=`NY3.QQN=_]$!&T&S8S<#D2O')4<2M1RM1&B_(#4KH))Q@LAB)WH<#7
MQN2M"+;_/\2A??*>HCCL^10\IW!($3JP?9"@`Z=G+&";I>"-43Q&O8=S:][9
M^4ZY5_Z@S2<9.<5.SZ@=8L/)'9E9]:@S_B,@8$`4OO=>Q\K>15Q^QKVM"$3!
MEQ`S66<HVEHWM.=V*W57Q_O)D]NF'E>FEL.=E"LA^(,AZ6!>;6TR@H1REOEW
M-JF-E>&37GRP_Y^#Y2'E5?$_<[%=Y3D/((?#"3N^A&&R8\,;,[?=AF&R=UU[
MF67V'9KL0:6CD:U'(ANY%!C_ZQ#2T<3.]>K#R=*V"`^L-+9+?X06[C"D%44'
M5A!]RKZ9/`S0[E<R2D+;@P-JC4B06$JQEOGZH"'7YP]E!^9.^G2W7#_,:Z7A
MO_EPWH=_E_0S/NGMAP1"SB8A9;[ZQ*XVL0ZVW7E$=K(X;Z(4&CRQ7,R-7]S-
M776N[5L>>V2^9>N!/RMWE:@"&[1F],`1;A$V(+2/+^P12MF2=B`SCO:/EA#3
MYL@K!O;/)(@/OZF>FDR^\?G/VF^$RG)FJ23*\J:A-[#PT>PH_O6\3NAZP5=N
M;I)AVCW&;A%(0PV'V=^\B&AAL!U3TRD'`].9=[Y6&>U8)XN`I'Y!QIL?;WI%
M:@$Y\!Q$MH:Y*]\]6IW.+IS1"1W`(5$UQ*G^YTIL!^X\Y1TPNDO-3DF=QGX]
MIA*'V&ZR&UM>CIQZ918#)Y5[0+"4;IB6KK-R6R7T5"3$OO4D9U._]>VV(?BS
M8J>!:^.Z[0;T%B]$K](A)P&!VQV\$$51+KME0V^)RT.A:?+B2012!E-./S.W
M6)!VKO,FV=.)>BKZ!13;!73J,/J&Y;GAG.^]%@5W/F_)RQY7M#('W]<V84/-
M64H@$QFCO$+/#<03!8+,4P8@ES()7N.\,'O2HG3C@:/[>]0E)NUI*PZ)'T[8
M"SU`_X!)Y<GO64=)D2+^W53A"%("P58H1@W761\RN.`-'4RR1VH!2ZFSY_8F
M>%H>M:N9^^67$ELTPQ7,'4ND1,.RN;YT`X]Y)GI7MK2`T:]<5C)20!3R?0
M'&FZJ;NCX6H;TJ>\7,(P$=CE*3TY*6=D_9$,Z-+3V!K\`HOP,KHWZ;Z[=N.?
M!07BN>?Z<:NJVZ1E[8TA7_!RG_G>O0IFC+86H@EN!'=F$!,N$E4L+BIZN=&/
MA-4UA8,+C[K^1DWL=GP)=GI/A#9ZC(-6#'+`;A^Z?VWXQ\>_/P)NVB7M,^'`
MK78P$@S>>M4-SI06\RC2)AG3W_-IC8JE:_9?M&W#Q<B_9!-O]9YPHK_`4O-/
MD?.T_W\G!8JP@%8QJA%%%-K.AW,_?TG?*/Y>:-(/?*KL84>OKBY\!SYE>DVE
M3$?-$38;>)0U!TR%7P-*%V$X\\X,A.*"4AQ_*EUKM:IY^X7(7M9A6G;R;W7T
M4!E,Z9F8F5>X_P,F3-&>)P%A\P7B2IC>AG8_)^81RGSX3@E!#X>C:0JE08MS
ML"77=2L"TT8"W)6O/N!0RD?[>?$)3H=>']C=Q92D/4</0QK2V>3E5Q?NOW0#
MZ+4'+FWCWN]F,1S:50DTEDJG(RT7*Z?TD"C=;($F'=5#WW*=S,!T-C@6VTES
M]'P@3L66^%?4P9?^:1I=TG<P!9PI+8VH31O7EY#$%X*';JW$)[LO,-\D`$7=
M;\ORBT4*!\U*Q=&JWI21_8,#MRQ>9%O9SS@R*_L?%OT9^O<N(Q;1K?CR2!DZ
M91&&CI"GP<4R;D.!@J3EE+\R.5:HCX;WW$@FLT5".+0'7O?-7_S*85S2]/KL
MD?*M\(PKWXOC'.$@"/$U]OX>M+C#P0.M&:Z3EQ'PAY0ZLV%SB2?0G]R.5KJY
M/2FJ[/$P>-M9G%VY6UF:_%)7LQ\S`KII3V'2C$O+\_;4OSEQ>.`'IU!AQ_B(
M/E^?_2?[?.&:3!Z7/FO@QEAA8#IM:B@B.C09@Y%[.DH'K6<H40_[I=/EA\D;
M+V#)P<AL`=O)M.VT)JD+5I:,D-PJ7RZQ<X5WH^RP,8Y1&UTY&?J<*]_9`VC8
M<SHU<6;J`LR+2JD&C[CRP-MZEZ+,,FSR^E19H(,6*CK@ABM?/].-<TS//(YF
M@U0/^<VS,R\FX_86'UU4C`-DJ%JPW4C8&)-'&?8[';M7=BA%ZMHIJ<RQ?8HG
M#K-%R=VSG#+*PG0X_CI,DG3Z[Q^_9%#.5Z;GAU(B'?/3,U%#(99T?N:_,4&U
M(YB@L'N"_I2R6(+8R8/-QYG8:8\8>N\,E#6G)3/BAK7;.-7,Y`V=6Z313IV*
M'J23AS@4=IC71,P%9ILZ%$(1F;R@U#OIR'(SJ1NN:55L1(_!#!F?D)TFH]K6
MP&$-@&0-TX2"LP@_8H5)S9ZMPPZ_];@LNWN4O"4N#J$-#W5.81[`U>L<B!N9
MZ4@*1++YM3G3:H`DW22B^,Y=[(DR_G];$&C[JC8)A6HI".S3*+7SEJ"GCA<I
MOPF='SF>4<?AQ`E@NAHS0IK=AN>3"6[,*UD$-]9$,I.,&8?I4%*;20=(<\@@
M3$>]AR-;X%X?R8B9'ER044*7AV5SB:'PWUP7)M:"%^[R,!;;'L:"(_,P/M+Z
M,[!R+!,:U<[H,W5&QB@6V7)[[ZBC\W'B]>\ZK//1X76DG5&P']O#>VX]X>6C
M(G8<]$XMAP)^5OLPW''3&_7'?,EY#09,MF^'.TI5HCR_V=Q!4BVY@WY,W1&4
M.^Y(74\Q;KGV*G_*K=>-6#1N$EYZ&(._2YGB/6.-27ATG@C?94SY/KT:?\2]
M)3=8=:#9Z$>'J`--'N>7B^-NO2(#%/SZSII3J]NJJ5-*T]>D-O1L4<I$Y"B%
MI2J1_I[?JQST/2N%NPP&^PZIK-<HYBP$.=U!@,-:%/H07%_[BD3W2?Q3KV7Z
MS;1BEDLL6P$_`[8*.)ER'_\@^XA_N&+QX#FO,I?#K&'06A?ZR(*='6_I=4X;
M6[\D^RRNZL-FJ.S%`YF5;$?<24Y5'H(_F),C`21]?F=P-1FQT#`#M(E1S]!1
M@\S?OVI;^.3P[2,;HW;%J]>E%Z3U/G!NY68[0AO(3IW!&<3CU&#Z/8[-FCG"
MB*S>C>%8JN%/;!:\A-CYY))U&[>3@9>$5!DI2J@L.PRK30O,*+;(:5MA+)M_
MT-;Z'<>DW*BZNX.S.'@Z<Y9((.MC2(^+EM?%J)?HNB.P.>FMCM3DW&=9B<JY
M+FF1WJX8CEXIC?G^3B6<1=2M_!TWX^`8M?8"A=2U0);'0L/48+/I"$ZUY(UW
MW9',,_PK>2@F#^X9P5.S#HX/2(G1:D,FH]@4&'_T(S#2NDY4>R!./P%L0'D"
M68-5.<(%_@ET^<)_?5SB<2-[PD7K7[8=N_@55W$?%.SJ4_.PAGC/C<_YW'M3
MP`E6B%*^":9C'1D(3=I)Z2?264TPF+'9$7P`_FVV_&:O]K[TT&=>8[>P1(['
M2;<@A"2ZZ,-A;M,KM:-3PX]][L=J0MUD-R&8ILI]D+1&P=$8O\W9#Y/UJK>!
M$=#*7O%]SA=IG2K\.Q_FWMP8";-7?$]8@SA31&UWDA>CXJI`8?AVH^3(*3?\
M<1>CP-J.@)E><(&LGL-CQ-W+"5D8'5FG*W:+-XJ^)(:),F70D]H4<+8Z07=W
M`-Y.S=*Q^#YWPY;.)#RARNQVJ@3Z0#DR',Y[[`O8%:U`K+'88+'J(QD`\R5A
M5HYS7\U"TNN.DI-DRK6R;\\EU8EUK=$W\\/=L&GHHI3KCOO4XZ&(MU+]_(13
MQ\*3=R]27+_<H.U_'*O_`KDX;_LC)1BD"23.9I/TGKYRTO4>TU$+_I>4O[E5
M^,8Z*NB4MF8R='*6;,6-908#W4;R$MM(/N[(C.2['W]Z"RD8#E@"Y3]65KK9
M\894D;C]K6SA@0FB9M#ZI(0DF*:X0O![`?H:9K_$M[7::^/JIOB76]D??)QA
M"S_8F_3ASH?S3O_Q:,/4F$EV1)C/[&[$UNR;0A?L'R`O7Y2MR/5$BY$8L^(K
M_P&H,OB&9,JLT):STVU692>@_W3K"8V+],@L30FC3US8(8RZ&X281++E#$YG
M[[^F1X<?;$'"J:3^X7#NTO>9CI=>71J,#3!?J)++<\=/(H&CM2B[I896%QV^
M*XN5-N]*9*Y,.+#@HY?I1V_6"JQ6YC_+)!>Z7$5N*)0FDM:Z65B1'1Q00";3
MW#Z,V#%%EN)E)=R@92&F,2<G;(LV28>5<Z6]0?)!2MJ(.>+&YQWXH#B!(^@$
MGOW6.S;?<$<=!#X)Y72OW!-_O-?2;(_<Q-ORD;_IY";HQ@*`SB-&*]H!U50!
M'?&J4)NTW-%+F3%#H7RH"DU'.NXYG'O>$`&M>ZM%A?(2!JJ!M`ZIU@A<EPE'
MYYYM6OA.+@HQE[@+J*`<=J*/<*C=$SYUB-.,K=_*?><BV/54N@<+RC%&TJB'
M9BK&Q;8EYD!K[H5OFDBZY6)U'HXM_9<CPX9FF+42UA*=PT!Y&Q/[(K'['>V3
MX59@%]+A-?P?*:YQ.B::--T_NG53>_#<Y<L7M7)S?BQX2N$-]D0"4+6<4\`>
MF_3AM(<9B"..(D$@5JT>W`+V^J8-;202:[Q^),S-N3MHC@5N@RG/DE5UW8:A
MJ,2OJXZ+FBY[%4_;-5$CT7*O]#YM(.*Z\.,BF1724!T+)!2>XG9;6SVQ/>AS
MMW+7SZ&^!0G#+?%K3.<>N0UWN`5FYCV>7$@]<"DM+[7'M/4&8C%WX&ZM`Y\L
MN&Q_NQ[7`UC@YY[(\K85#OCD*<*Z:#HQ"Z+0/!<T\KM/6F,JH#EWCR_/#X;)
MH.X8UB/QAM7>H%$`]$$*STKH^V$(?6C5>ERO%Y9.IGM/P,ET[7>AH2RBW7MP
MCX6Y^G5MJNA+WBJ:&6E?,_-*C#4L@G^<BP;Y^SZ#XU$P*2CXJ`7G+OSUQ0C[
MUKFM(V5]*[?S+#!&:13<^/#AQ!23#X^^<TW?-MW82J!D-9VM>)-N<9!H[T4`
MF2:S59L[[DW?Z&HP9)'WP*8\')M:G'!],N"QUI`N<_"9>^\\DI9W,$2O]AKT
M\FR#&YUN\7*0'TYD`@GS=;Z_UQJ"Q?[LGS`#A4?6Y+/_H,Q00;H.6ZP::^L3
M[0^:)M)F/)B&N[ER)L(BF87'86EA-?9*5)V/PR@HB0(:R4C8)!,9/^&%U?98
M.WKQFHTC&];DHS:F*?-K+MO6[L_/\@E+OT7];<A\F<XN?03D186M,BQL'*;&
M*L@)@!\1+[YFZ9(5RU>`#Q'$CA(>N$4E$8`/3J@%!@Q/5C$F(R1VM#.;6_$*
M?IECY%TO#6][WN)9WG<3;,M6[M55(QBZ.7>$0)+T!W9YO_E7B4PB5<I=.[$&
MHJ_B8U]"M]AOC8/%N_*>J4KW)?VB4[@%N-#8L/.$I`!DNI2]8I0H"A9Y'D-3
MUQEHZL5+ABY>.G3QLJ&+SQZZ>/G0Q2N&+CYG:.VF3?F5(UO.6RS7+@Y/O>"Q
M):UC7_?[I=&RZ.QH>;0B.D=[$HEBLQ[/.HZ>1SSN?(`#]5!D<CI>Q)`/%28M
MIK\.XB5]GQ:^3[04WVA9^,+7_9Q>24L@F*SL9Y]0K0/G":2&L.%4T+JE;L6J
M!4&L6;,D#$VY$_=48$^1[BC7)ASDQ_$*Z3J3I*J_+`6X),\HSH%V>;0+MRH6
MY>(.C'DOTPDEQ@ILE^.5\1(D@L%#&TB8X\;3CQ:D^;TK]X2+MO]H-)V]S]TY
M!(>L2>&+1]_#'RTMJ;+[QTTC93)^#-4$FW_[UW.)=9VKR\>1#0!VCD-][JDM
MC%K;($;K`M:CUB](E=%`W"Q<B)!T-72Z,X^9GW^FP^G,;;IA-*'W`XF27<DQ
M+/%Q^&5$PI?J4A="/ASRL-`-VJP*_77I$P&OJPP'2([S!C<-C*-1K>Z_Q)/E
M!#OQA1[_S5ID-S/^X3L^J/TS$]9CM`C(G*D2*9@3^%4RI$1U&+L(O#PZ`3N*
M=3C.7O7TM$79F<?LR27=`^&VU':MCS\RU_J^Y_\9\D\KR?78^\Z1(D--,>\D
MV/Y_@9&M(@CMD_;(USIZ/#O%I!$;,S,_\C$F>[`ZJU8J;M&C'5=/F;7(._`8
MUE<<#GD9)$41.#;'WNW&K=2O%'OTB:=`ABU8VUC)0DUBR\-<E-`E^U>57:>N
M$(TB'/8J/I.[B(I_$G#?NY@\1S1E.2N>=&WHH5/H#X-$2NHYAJ-'10@U?H1-
M&^^,W"DM_@!94G=C1V2^5\:70$H>0V(S$(-D*I<'&\3+C"TZ*L$L^C?WV:-V
M()<M2J73IW.??75B4("I%X!K3?E#&!RML(%P[LDW@[(]KAE,($U8+*PI<+[F
MW_%]4`LQR_%8HFS:MM+@XFV,.J68Q5*I8R>+AEMCAY/I6&(\E>K^K(*Y0*)I
M.N;F#!^WN4)%-W_8*+N1!H*#Z)0#NU]&F/G#BK;5^([R!XALJK@5;EI2[[X>
MA1/6[&J9"V-_6[F/?*HH7;>%#Y-NG360'P5^";GZ'#2'Y[_QEZ-@L:!E,/?H
MD`I.Z+$>4P#!;&,\ERW>I$&.O``&[Q!X,?=;!(*KPRXL>V/J=%'TIX/Y0W&U
M7$'$L5J8>GOCP$8!,Z/N5YEL!:V,5XQN(U8:F"]]LEO'&`OS73/'D(8&:AH<
MM7@PP95L."R00<U4XZ9.LA[^9,/'';E_7>]-H`1:V:_?KVJ%J;KK%9IK.KI3
MAQF)`[P83\$&?4$-64U@R_SRI33KL\B10<.J)/*DE7WKH[1QT#ENUCJ>2?X!
M=;:%D:_?@PZP#[;P6)GH4[2^".6-"8K@QM;9LIE;324X$CK=?BT>7;R<GEWV
MZ(MA5#QX&(=7NJ)`X\6N]+SVQV)F"U$&*+]*A-;"5ZV[7''V'1OYS%;VWW]!
MJ;[SPMP+STNCV)^X`12FA,0(QDYIA\`OHY;=!);&O_^K]%>U$L%)=+]`34!@
M%/L"0PI#U03USLM5W#+"G'MWL#<E>1I320,'B&U0C-D$%NGJ2*F!O6[6_H"X
ML^2,%Y&#$P\<B3YB@QV];X)G@7NVJN6*GK!;YP/#]L3A-)#58'/<LWB@2`&V
MLK==8#7Q64.^#UR4T$E.9S\W14(-KNR15\*UX2<D++BW74!C,P._VE1)VQ.F
MB((A3=E;*C5"Q**):,1C@B2[3IR2$O`E7<<-SZ-.L^K]^]Y``@F-T;V6,6I)
M='Y[^#=Z[20CO5VRNU_3!-6QLZQ!HI4/FIK?S'U_G<CC**A11TRK\V9B$V8.
M+M?=Y`8)$UKW5.)P,1@9C7BJQ<^[Y$2C96+0,1'LBGD/8O0/QC0F=BS?9&\G
M$-I8%(/V.28(=L5T)FS&HY\YQ$U`1B]S.?+\X]2RF?ZSX;:A+]`P#CV4-J&P
M`Z&7\F)0)\PCP><A'\Y;_M,>(4Z+XJ0>*"O6S2G2J=QB7YC-D<%Q##5ZU(4!
ME@^#1T\TN7M@ZMT:=>K7X3<MGR.W&-D>:6$H>)\(MQO(>44+!RR46$X<]1`K
MN;OCH%FOU;T`Z?V"KC;I<<5AR@S><&ECOO\U%+AL95\PB6)?'$\LE^PS7HU/
M)6^:QL6SW!^1N1),S*;#.V*EN5>_EEO");?IX<9G'_?/$][X!&R<B@_#L\A@
M:U.6G&9)I9C:P=GC/M;NJ)Z"#SKMN0+3]^J6BI7#HWDBL\'<29:;`1^E5O;1
M$Z4?%ZY5U7.%WSR>"J1M.^\+CY^)?2@J'M5R'5:ZD2ZS[Y:7P(AUJE)-%VK-
M,\`F#5JY7VWF'C/H<$K4"7])?.:D6IUH!^^>@S]H;P'9"8^<.EWT&WXU(6;!
M886%;Q#YMC=>%5,RL2N,J<12BME<?GYS1[Q8N\=+MDV)0W!?&T*$7J9*8LJ)
MPZ?/D^;7^7#NW!_T;::]-^'40+:^Y6,D_#BWS&R35#/*#K7(<T=9B?7\P[.3
MQ%2B36$@K=^CD&#"/"\H(TQQ#J1]T<9$G;@)+4B/4B=@9^4J'GA.B($PYDGG
M^BNK^'TELF""^[?!WW=''7<Z>']5HOK8ND=F-JYCN,>)ZP4L<+0<PBTN'$#=
MEYG[_MA)$")M9E&&**WZF,>I;-P:DC4I46F^=,HE.P?C2VQMFN2[E19(ZJN+
MX5'S__8NC^$KR/Q3MUY(QB`F6(L1W%1.6_>;XC7,@+5R?[LED79_FTF5J^MT
M4AHPX;,DA<$!Y-R#EU""IXIG"0Z6Z5M.4@%F*+9>1R5,64-.J`5.CC$$,9U]
M[%K]'!"G0NR*\26/B_J=`EL6L1+$D*AUXO3&CAJ=PE8%-FOU,/OAF:(/4ON?
MQ]*TMLJ0V8(+$@"*/<'V\LHNIWE`FH/!$GQ>M5BFEL:<&W;4X7!J<#JY@EN*
M\\77((Y.T/G<>A'!$RSDL#(&&QFXC0D*]P6\>V+>.QB89,Y)/]D!^)E=(9AE
M=@CFA",+P?S;Y--.$\ENP:L>+;D.PQ`2GD:;O59P8BQ;.I3*+!J.]40%+"I\
M*5-J`2KHRN-ALR3Q%,7/91Y]_?[5:U9M!Z/LT5*[.\U"*<9+-V"I\FJLBNC;
MB3UNGCS1K70D1[CW`+:ZJ6NDIQ\IMD_<C-IU%0Z?OF,@XOTXMJ0P$%U6W.7A
MT(ESCGBPR__R\AZ!MEN?>?REK(O8JF]E'E[N,5UH+TQ!Q\1U,*CCP2SSM,=8
MHF,?5Q%G5#F/S8$RC]=`PC2GX7E$@+P@H<&$+?'@CP05@N7Y:,$++8O!FL`K
MHN'0U`X(F$FM2,\XZA?2T>,2]<]O7JNI<W*=.9;ZVXOE<]5.)E?^K(_@@!9#
M+U6DU#D[M'\$*Y;/^H>V4K;",$M7>!W8)-B/`26L\;0UN"$(YMBJ5@`:QBB#
MY8'69;)83-<L!+>V\`4SQ`.M3&)+NLQW%&V@_8*!LET>2!^26;CR2D)"4+54
M]?3",PPG\\+G=G$R]]1'^W@!.1`32#H5Y#0'H)7>5*+"S,!KHN-D7+=R-]])
MEW"Q#^,6ZI1^0``%F-KH=U9=\L10(_SJ2W:;/>KWQ3DD9(,A`8JK.__2AS<2
M*@'&AL_D&W<;N[[DNN56[B6K]</V=7W87ODP3()6\)74^Y)($8Q5+@_Z]7$'
MIZBHG`,:Q>20>,!I`=N_N6L\0;(LAEVX[[]&.VC-*<^K^+-B"NWD5B=P5NC$
M!9J,8*IN[#Y3\#!X96+O'0O6RIY\6VK-\#"A0O"*$9NI9M8U9@*FP(O_E=-^
ME"P^^38AY79,RK2`<^Y&?6R\.=74VF;?LLD)#/,M.J*J\LCEM7*"'//I-V2]
MB;<U%KLEP?KL3"\-_&7<(U,R]XE1>"<#L&F(.JQ<3M1>S:1SB]JL<$2#*PYM
M8%DPH")=3I9P>I[(#HN;@5G?CFH=@5`3!H9B>_LTMM=ANMA<C*DSH^=S-3.1
M4]0[]Y7_ZG+Y`HI&HPH'WW`LF=G8%K.QZ5RAD8/Y#W]ZE!GJ<8(H$$"1Z(CJ
M<'TUV@6Z374-9>Q.L$\`*@.2+1><-2$/+!$LW>X)R.RBB(C0:"W;'>E(/B==
M+4@1#H.NO^"A<)?G,&&OZ9([LVW-96LW;=RV]=5;MZ]</;HE:A]&OG$LGY1R
MI4M]X6/6/F-DIC&\`^8,IFSAPO9Y!,5-?D.]GA-H2EG"@+2$9KLD3UE/]I/K
MX-";OKY;TK<\UM"0N8RT/EYSWMGG\S7#5_!%^7S^5>:R-JIN#`'TP;"TB&6T
M)\OQDD7(K1:^[NNO33_AK+/T`U*_?8H?`:8!SF//^=IZ90RS8[Z(R@T0NF!F
M;,>.-G(,WK7->$1+R2-:HT4%/_E@NMX:ZSRV[A'V'0P0@TMTVAT6.N^CI[-V
M_.BQBLY3'Z+$+5PZG(@4R\HLR$PXT/<]!WT<NE:K/D@J:>S/\-!B8[OOW(F.
MN#N=^<*QIC4#;G8Z.D6WY("LBL7CY`.)[@/&S[NB,_DP=^'EFSGI4\"S#JX'
MB)`8;6X3`)6JS%;VNR\E^M1ZW56XW+P3+I+0"IGJCH2SU3''UP1E=]1-:$;A
M_?A'%8D6L0Z(6;;J[&8%8FXHMHG:GKC&&T!WODH[)1W)7'N=A:D'#[&[.%Y#
M83)3QC_E3V`EW,",LNFO8&)1G8YJ`IB_<B;?/I.Q'B-)/SGN+$(]P9A"E?TA
MIV,TA>#`(#B*01]CN!X,36QNH5OX/D3'+MX3GGO*.\C>)C%X\*RO^_?N)GK\
M8Y0M\]QODK4?W:<GYYQ'\.0<?_IEUI8>+;4RM<><*@?J41!,9VJ?;'<3Z)#9
MR`1E_-B(G8FX!U^?('R<.N[5]]THZ)GDH'?8Z1WM\`Q`+K+:4R"7/$4*A.Z-
M=PTWT=*3I(B@797@U450[('%22TBR)3_$&_/.\+Q%UV#W\QUZ%W?;)5\I2E&
MW$E7[@:)7QS$-0ZIR*Y2P89$AL%BAF/Z>JW\72J$\'2Z1?`7@H%(_F)%DKA>
M*BFEP=&<R9H.->95'9XIN]"#^H(C!@:\@,LV)S?N<B8/?^/^2ZD@[++D,UD.
MZ42U:U3]X)>U_G]`8#E8YL1,,%U>^=FV5_[,(_/*?_R'IQD802784FMG;P#*
MC4DK&FFZBQZ"%Q3`MG:J+F;GZ!I3KR:5M50\/5[OO<S[K&5.ZL*0>4S6EZUT
M\4G@1F=<=R',Y_,TED?'?@D=^U?@5X,OC5MN17Z1%;,#P3.=^=)WO,Y./H-I
M[LBN$QOSTYE4LF\F7_-]I![+_/"=5!:`4-$\\Y#"/RINI=U/2`;FYQ*0G@C3
MU&%&9W7FEZ86:(AY$<!"ON>]VR3':;N(<EF^4!66?(N@DI+37M%#M,_,!F>G
MN\V]+.%C;#/2DW)BQ$[MT`UUT!/H@`FX+_"54JS!M4B&Q1([3G2CHW*G?=/$
M!PM)MP@9(U5E1E[SNHW;P]QI?P\;("YRFT@F:D4U>=]%ZUBA8W`8.3H;O8*>
MM3IQ\2R8#(]:MEI:,?19I5A1FP-%,MG]!'+O5&>VXD\S77[@';,\B,H:G0/_
M7]M&@Q%F@&+WC:CC)?;:+V'58'I5'<B2+E9ALF/^#O]DAH14N:R6C_*KE/PN
MPJ*9,E%BT05\5,%=P:OZ\"\[Q=[-GV474`<3L&I#1JR))J`QV)2#29;O3$0F
M;57S*H<^4(80Q1R=R)P;LZ.E]!+>RR)3&_OR#!B,M;SCY2M>(P]R8A@1E4/C
MU>90LGO$8B9'WF$65<GC@18L1JPX^`1HO%#!.Y3BTH0>OCX<OF]_?B3,WK\4
M+:WI[/U;*<`%7A:C5&(P)R.W7D>3DH#,>K`167#LU]&.3)`%/WN7UXBY0UBS
M$5-PF>TY;6:$22-QFMC8M]Q;BZ3>JC7DHD$P>,XX1[IYW;MJ3SCT7QM'@U;N
MSB$ZN'""QK!"E%IP[KYA^FYX@PLL\K;5G+)MY=YZ>Q+L?^N.MF%;UXY=&#^M
M^Q7,7(+S.?^^E;[8>YRW1>LQB>HI_5:2![1;)'WOE4D`+!47HYY4>'M=FE*`
M=8G0AP55DA&2]1^GAGK2C8Y#A7[-JRHEOHF)_<N_8="5^XRB#C+#<T!/$C!]
M[#XSZ&8WVK.<QVJX8.8*8$@"@47$LW,IE%YFRF($1CG5RNS[`)MA[B0:6PVM
MN"M*^L/'B%303^/4W?$F.>4D(_KH7.#7U6*RWKC<E&I)L3V?;DV+0Q+M;\)H
M$M@K<*N!>WI_JKMQQOFA!16@`$G1=319E^`&'>(#@\/1I#AG5UR]C"%8E=X)
MF#0)S/<L9]F,.=#&Q'3FU[^R$C?D.]7]<NPTR`OKUK'L+"-<X;]&2W&"?XT:
M04QO'FLA4MP1"K(21%HKX;=R'[W9Z8H5[O(<9D.F$+=`8-FBG<0Y1R4KL.FY
M\^^T"Y\PSL,-NZN(]>#-#4]:8/JF?_.Z@E55AP"02;=HJNMPGT1]B<,$&D["
ME':?3S(7,:WPBU/U./7D,B:PO\0&A1!G0@/8N+Y5EUT!(X8U3,6/Z$4+V]X`
M0LPCG_^!_K(_3JWQ[&IHC-S]?*4&X1,A=Y":J&%]M18/B+[%D].'N9Q!XG"S
M]2Z^AWX'+4,K^]:_$D\_^B1W7+"[^?5AEQ&\KFN4J#B%S17IR`Y*ISDKB\!^
MFZ'RA^>--K3CL!7NMR#1I$FH!3'3P-.G)ZU!9680#.'6,>!+^6P[+M-EY"^W
MC?QG'9F1_WCX9T`_KR+T\YH?;D#.$:RX-,+<LIE)K-XR95(-M[AM`9?IGNJB
M>.G=JR`19K2D#N+7N)MT4A<:&:8.:B+(3G4CR=4UF,Z#1S(USQUTZ[F)YVM[
M(J>,/%$F%T`A>(P=6!@>C)-@J%N;9V)K95CV.J4C`L&><3D!'].@1W_ZX7#N
MG+?UIH#IF!VT[M?]F-.>[_EX7?`\9)+;+S7![T1Y:!,O*--CO`;BLMQ:P,6)
MMI;-O'>EM$TI*T+'23%CIRNTF4&>#0_*"('P759&SR/U+IILCPP:ST4GWM2G
M9E]W"J-0)8V%8"M.C\A!(ML,,;J2=NHC?FM,5_SMV[L8=<BK#&%,/L3D_>&/
MIJ665!YCQH2>RHQ>_#R1&8AH<0N6L2<8X3HW+I(R$HFYQ&[9J,^-LAZ:AE+@
MSQ%N\<08@L^N2NH)M`+G>33+U%-KHEAZ^"I,I93]@$M7.*@FC?=@$;R""S;F
MF:#0HQ+\.!#F<G`I&V*]`=]R9!]>T];Z2>V!B%.IM8MR(K$T=->327ISUV_:
M$QZ,C8(M5NCB@S.T/<RQBEU-ODA!+%9$H'6V$WLO5SE<"<OGJ3K3WE12<55R
MR]J5:C?M=2IA`+N^X5IQ+%*;>##)(F8;EQZK$P,38,!;6&;3LRB`)-DEIW;(
MA-16]ZJH0@*I,^P`>%L5;G:SA#![R2\#/R%@T$8,.+-[A0/@YW_#5@%GM[@A
M9H_\NJ;ZR(OF(\6G23"AL.0GS1#_-[58A2T-GO-?O6Q;4HE`)@CF(!1%&SM8
MRT#/Q=@V1J]]3B&YQQ=PKLBWF=V@2N&E5A%>:LT/U^Z]HR[])Q.5<6M*9>2^
M=+GNO]P7?T<G8WP<E88@U\4.TLZ2UD38'2VJ'=SRX(5\]1O;A#M&*ILI=4KX
M2KCJO'!N^5/D</S/E6H$:6H+YJ'LE2R;"_%L"4VX&`WT:CVP$P%[`-S+TP#-
MM8EE*WO]:1T*C@9"$4V[PI:UR<=2F6256TUE;[E?#DF=4ZCT/`_CG592NF'7
MWKL(0<S;43!8(53JYWR]MA8_KJJ^-W4[WL<&C"1>M,90R^V(!$V9(+2='O(%
M#U+Q2<?7:<2?P0QR\BWL7T?;$"Z)[,%8W$DY/)VH3?@][%^K&V<;5WXZN[6$
MT#[A"@EH+R-;1H25'(RQ8X<=_U!"&R5FFH?LUB\2S0/5'5$HC_Q;VC=P3,8]
MJ@R69"J1&L>)KL'F&^Y!-&FE8"AWV_,P(]6LHJ*@=98]QFU0.4NBAYK-#M)!
M+HA>'V?)[IE38"C$^$"RRG78PR\ZF4&_'.'KR&;#:A60!!-$P->?V6F63^>V
MW.=5DS+(!612SVQ;NX$X3(BJ1#+]!C_?%<69SM[^H=V1N%X4&NCAMC5\E1:Q
M0#)I?BG3EDC)&.=#$FA>-9[9O#XF+I78JR8X0$IF24]L[B/;H(E-"*)M4V^T
MVLI<>S(EM*M%<)GNO!9L'2Q4(:NHP_>.Q-)RRFF?C/IC>8PG2OO`+*))1L*>
MT`4R_!&TK$[5"RJH`6Y:&X`=%([.9EV.P=?`WBF"\?>2]QOP?S8<;J<M+0Y$
M\NF3I!MN&LO6NOH]ZE^R;\HBCEU*2CL*+W=,%L<"$BQO_#_:=ALT^,/3JV3C
M*#)>%0&,B>>(;I!6DHFIY;H5;2?$+U`5TJ?=A`W!^L"B;W*/\L&'47,TS4@?
MP,#<5)HR]_D744#:DDF!.UYWQYF&`[>%Z`Y3C\;T1S0K&+[!&)((/CPXX-&?
M^@W2TS`9'53>)DK.B8M6[K/Q[KWJ(.[C$DOR2$VO'%NJ(8E7./?D1^'LXU[C
MP`YAP%3RI^O"RWQYHD12?::^?X4I!]NVSW#++U;U9&K_00+-/XU8M<'`KH(0
M>,%#(V5N]<D+,U;V"(0JG!<XV70/1L31[++#29E?GD^ANSI:#;O'D)87?X?U
MT;X0N'`+^B+7WA>H2+2I)G:SP>A9,*^Q]38.YF'F?//GDT*77[ZD31XS]<C4
M9]-6)1`B41;,F/:_M7+4%NY67A1JP%9R],\E[5PW'I3,E:`PW,7M?J'4&(NQ
M=A5[*O;PR5?8/OF)1^22'Y7;]?3[Y*3`EY`"WT!X7U=+Q2R6_$2%W]I9GYS6
MXA,.]8&1"![1PL.TL??#70`;?B6)/E'?2^K587C`.AD-GIH&KV`$*I8?BC4O
M/"KW+5N?@PC/G;Q'L&A(-Y`;W9%&8GL-O,)#YH/C"YB\P9:U2-%S:!B@B$3J
ML)XT$25_+.F1)EXQ=>N@E@MY[E%B22%V_ZJV%*KXJ3GM:'``>[%F@D5LI=-[
MD%+K:1/QI%;\%O6(L";/FJ]99SWB*4\922N1</_;)]-[,Q,`NF<VH-7'^>O]
M]@:#D%`?$F93^"<D.%)P&$M;U!I`FGB?`3BB)9H$\H%IT@AIEYVZ5+8YS0U:
M4;@2TOPYU0-T8#^KRX'_F:I'8#>*D=V&;)XR>KSN_"-GAK!!==+PV;B23*P+
MOJ8\UK0&0J1$F/V[L'.I0-R`&[AS",,XS[EVI-K*7ONS#H>2-#X!6A*"1;>7
M\4_G$;_;+)WL&CP`T]E_?`)?,V)S*FCBOVR#BD/B=$<\3F4#9%YXGT,CF4O<
M)PBR9$R=V"FRID$C;)QJV!,7B@\)9H40^B`]YC@"FJXQLD*AJ%6T#Z$%$;)L
M--R+F3?,\3B@5?0"\PJ$-AHGM-8=:QJT=89!.ST_`6*KVU9VT/M(5VUVTM/0
M*#6*V8GIQFAR:D9MVCUA=24JK//"W);W$`+ACT/X/(T%(RL\6*;,\H?&9Q).
M*KHUQ#ZE:>/Z7,:<<6$TYAJEI2]/AII.6&'FCGNHXPX<H+($K3I'3E-3`IU`
MJI%(KLF,6O-.\H3CL@B[OB@`GP8R:Y%_:95?<X0H#0VCL=T:O31O?^UZ(EJ`
MFL5*4,/4L7`#!SFT*:LL^]-E3"^ZD^>8[&6O`)/H!$&S4DNZ-78V2\F]V#1!
MIQ(G;=+'"!#F(.5S.VAJN.FL*X%J*_OL![0S?)B[XI>C0B\`:AX;D<)!!WO1
MF*-<EE8L4A9M;`R]]"1E8#EJ%&_"I\I#E77M/R]PP`Q\W[/0>*N4"I-1>U>0
MCV8FIZ[&?W-@;T(;X&"2@8-0.NIE4U</Q'!1ZFT:4C3L5:C?IUFI5N[=#UK]
M/U.M*(T\;E8]M`O+4ZK;./HS_]SUZOHA.I!QR<@88.,A<S_>A0H337CU7WRL
M=COY.*^B?(+2&I0,;F:1!+UIADMA_,"_;YJ^G$322_0.2-!'O$^XA2?B],RH
MUM7S(I*8%2Q%#ICJC<*925*FC&#]CA#44@I!=78,F"U]H>[$PA]:.AQ=>*;4
ML;JNVHT3K:H,.?)T4!*Q(V=%SBQ!,$R+T5;NQ%L8Q9BJ1X=U&/GM&`$SV0#G
M[<``R!0CIR-Z>@&IV,YNL.H!P`IADEFEC#3"H]8(1&9IZM$"JZ0>BRGAD_9J
M<A@_3V[M=,#6OD#*F(7GQCP8CL<;-N.'*`\$%<Q)T(Y2<CV:^HE0[UO<S]D+
MA@KPA8/&J[;[BIXXQU@@*#3[EO2CW,&`<X/@2\@YA>%\>")"70G3E,AC?A.#
M+ET@X>?$[#,=&7NV-&T040BQ3U"B*@6X6+TG7/P"?XOT#,O=.63HG0(+9<$Y
M'C#>:R+'O,EHW!-:S%KLZRH$S#=A^;`6,X2U^F:!P&K.GG\4";\T\0Q8+"MO
MOVOBX$OOOBK\E`UV;7CG/HAELB^_;63C/</AG.M_C[9>Q768KE/P5L0/!?]'
M](!3%0PYE1JUI,`VS/[5']HL=G)7S=$H+);\3*`T3(@8M+>#YG%M\X$`P!W1
MJN%N_^P<VS][]I'Y9R<=^[23,<_`A.2+3K7AYL&<1S#.H(.5P;O<Q&7"2X*)
MH,EH)?N2F\W?L46(4\@W=W9=@#MG+=*1$BZ(NAE<:(^HRH=<<K?!5AC5=%MU
MT$1T(GD2TM?4ZR`@=>37RT7,)4@/<WS@1<0P@'E55ZJA=#L/SY9'R7U;8$/?
MSK<KS/W&;Z+E*QB:Q:N(.$K$>:,N[!E%`F+@YB*8S(R9KBL:N\<'&\7@5>3=
M6V[HKDJ0KT^,50LZ;3)EP1#<D6\@"*S=FPF*!"+S!''0G#Q<W(5W370=BAD8
MZ1#C%/QRV36$0$^QO;PT1*1'TSZJH*W<;#@3":X-VPU@C\E>KW"D_8ESC_ZJ
M/88]T3$-A/V.P3*MQ$FKXUF_O>A;^G0(-Q@_:=`O#6YS+VO/GE3;OMW8*8NB
M_:OW?O9<[,1:)$!7W<`\9W_P+F\W0A#QAD&]>@B&=,N#BWK/14),FSN_?(@^
M->&<KR]L#X=SOS]Y^"_67CC@V\U[[]=(?.>._Z<4Z8`4*00)8RT74C"MKFFP
M2'F<='M$L:9[\*0E_,>8US&\'.2%*.PY-84S$XU&;7AH:/?NW7DO\/.%B2$,
MS>'_RU-3Z-DH2<?.4:G1RHZ=A^P4?BG,]5_6U=AP^@5MC</#$Z^]OM?<2>P3
M.PT.F7Z#(-WCJTDS+"B[AYFM#C_#TJ^P@D-7AJO@`33Q/C:?36M6R8%1?C%J
M3SC4VH`R(Y@)=XD1ZCR+`0SIU,ODZ(GAI@`1)<L10!'2]#4KE@.[U84CW/#`
M2,_>LFV+0_BFJY70H?O,;R=[8QW"^:2#BP(*HU5@&Q<\Y+QR8-&0+/F*_1LI
ME\/5W^"]3.C`\%;&)B)F(*J>(,).KVZ8Q.K>.'+%<&4%&0`\7?4$R3SFU.'_
M'$-"C]VRPOY'WK3>J9>CE6Z]/A6^[)&W7NJ1H>I%*^N8M`_/?O)WTH]\%5SG
M!>6DZ\NV";_BD%FS)L"JCOPC;QLIPR>\W'U&W9T*5YQVU<M?%_[^R2?]^GBT
MOJI4MF'^G(<VP\$`_;+!*:PG`E,SY!;/P-@V^.`_A\-W?<=,>P1S'C>N#E^R
M<1&*LAA$6;05_HM%6?B73_YFU43=XTNWUCQ8\:3UU!KP'@A/!$8DRD):$&G_
MSE9YM#MRPA,7W[UY`C18+>8+HJFR7P^7W/;WV\MU;V=\J0>WA\,W;-P<.<UR
M?"F9+N&</>=<U7#,HW@A<27,6L+?A*C+.!F'6JG5Q%_GT<D8"6I$`A2^](PW
M;73+`5+^NRY]2;CXK<^]"*&R<'A7@M\&R_G2TR968C'6*OB(8M(D:+53H6V[
M??NJYG@9UJ;OJIMHJ58WJQQAA0<L^MSO-F",R7$I^;9V&K=L?;P)CPQ?^.1O
MU\`$1&MC\$;A#LP*3)CA5V+(JTZONP[FI>R&_2_\+>^":!TX;E3@%;[TYTO6
MN;`77#@3+CB/8*@7W?#4R>_P/HK`\FA8*[82D3=^F4:]R*]7PX'[AU9-P!X$
M)0I;MHI?<=;?K^:H=A%^A7Y'+7QIX4VR7]>[V#F>^N;(D+0>?G4G?``%F7`C
MK/<JX9)OKM]"7UXOQNM!4$43X<`W-V[QQ[PJ_%S?.>%4PK[32B-E=S)>[^],
M-A7C02;DVS=@)\(@7'C+FU;Z8Q'L7]B,X?`M;[W8K3*$>D,37JD*)^7,/8LV
M83'OYACL@@"$PDYKJ?:9M=\RX3K%<.EI5VUPZCNCK5X5/)YP>./BD6JQ[NYF
MH8)Q+G@2G-7PU'7/6>TWQT6$-(MFS%43KCOX"B0`<ZAR]_+(;5;'X<]=IO:Y
M:FH_/N>HA;<=]<9W??ZT\]">SOXX\S=_]YZC[C[P?G`CGMW3J>A95G>P_Y^#
MY>&<^?"+^?K+<PZ^Y+K!QT^:<RS\`O]S=*%2"`J+%QU\\>/7^^>;7\\O^^-^
M4(;?GT&_7R"_GX>_A]^^J'+&9[;,.?;@4OXMC@R_?>$;[M^RG*Y=8'Z[Y.`+
M4B/K",_G$?2W,L)I-,+QI5)JA%._^Y.73=K7-AIP[2G^QZZ]UWQRKE"IGWOP
MY"?FG#F<NM*#*T^X[/9+GF'>:RX2/R\Y>/SJ;_R?QIQGK?LG^@_]<L7!XQ:>
M/K`O]593</^QS[AI['S[MQ4<]>CUCUTY97Y+`RPZ..^AZ*8M<X[&F9676O&[
3.4<-/B?S7?Z?_PO+K9B4\"X!`.CU
`
end
SHAR_EOF
echo 'gunzipping file tds.dvi' &&
gzip -d < _shargzi.tmp > 'tds.dvi' && rm -f _shargzi.tmp &&
$shar_touch -am 1121195995 'tds.dvi' &&
chmod 0666 'tds.dvi' ||
echo 'restore of tds.dvi failed'
shar_count="`wc -c < 'tds.dvi'`"
test 77552 -eq "$shar_count" ||
echo "tds.dvi: original size 77552, current size $shar_count"
fi
exit 0
================================================================================
From owner-twg-tds@shsu.edu Tue, 21 Nov 1995 23:31:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 21 Nov 1995 19:53:19 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511220053.AA09679@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: nov 15 tds...
Personally I agree with Joachim is not that every package author
should be cobbling together makefiles/batchfiles etc, but rather
should be an agreed `tds registrary' file which really just needs to
Sure, I agree with this. And I think the proposed text does not
contradict that; it's just one (probably the best) implementation of
it. The main point is that every installer having to do a bunch of
copy's by hand probably isn't a good thing :-).
0.999 coming up ...
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Nov 1995 03:20:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Nov 1995 09:13:53 GMT
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511220913.JAA08760@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: nov 15 tds...
References: <9511212149.AA15762@r8d.cs.man.ac.uk>
> Personally I agree with Joachim is not that every package author
> should be cobbling together makefiles/batchfiles etc, but rather
> should be an agreed `tds registrary' file which really just needs to
i agree too. and i am not as negative about Joachim about interest in
doing it. its just the usual lethargy and lack of time. if some one
like Joachim puts out a document stating the standard for the
registry, people will use it, never fear. Its just that many people
will argue about the specification
i do think Karl's para *is* giving the wrong message, i must say.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Nov 1995 09:21:53 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511221521.QAA13762@spice.iti.informatik.th-darmstadt.de>
Subject: Re: nov 15 tds...
To: TWG-TDS@SHSU.edu
Date: Wed, 22 Nov 1995 16:21:03 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> 0.999 coming up ...
Arrived at TDS archive in Darmstadt, will be on CTAN tommorrow. --
But you might want to add the missing blank in `makeuninstall' on
p.13 before sending it to barbara for TUGboat publication. :-)
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 Nov 1995 09:26:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Nov 1995 10:25:24 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511221525.AA24686@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: nov 15 tds...
i do think Karl's para *is* giving the wrong message, i must say.
barbara, Michel, Sebastian -- could you or whoever will work on this for
TUGboat remove that text for publication, then? I did not want to
include anything contentious. I'd rather say nothing.
The text in question being what I posted the other day:
We encourage package authors to document (or, preferably, automate) how
the files should be moved from their distribution structure into the
\abbr{TDS} structure. It is also useful for package authors to provide
an automated way to remove old versions (e.g., \path|make uninstall|).
I'm taking 0.999 off my ftp server now until I have a moment to
regenerate it without that text.
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Nov 1995 09:32:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Nov 1995 10:32:29 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511221532.AA24854@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: nov 15 tds...
Arrived at TDS archive in Darmstadt, will be on CTAN tommorrow. --
Please junk it per the message I just sent. Stay at 0.104. I'll do a
*revised* 0.999 today (and not do it for ftp until it's known to be
stable...). bb found some copyediting things to correct, also.
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Nov 1995 10:28:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Nov 95 16:28:09 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9511221628.AA02933@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Is that it?
Date: Tue, 17 May 1994 15:28:17 -0400
From: norm@ora.com (Norman Walsh)
To: twg-tds@shsu.edu
Subject: Welcome to TWG-TDS
Reply-To: TWG-TDS@SHSU.edu
Welcome to the TWG-TDS mailing list.
This TUG Technical Working Group is charged with the task of determining
an implementation independent directory structure that TUG can promote
as a standard. Many of these issues, as we are all aware (and several
of you hinted privately in your responses to my invitation), have been
discussed before without concrete resolution. I hope that this time we
can reach a consensus and put these issues behind us.
Seems a long long time ago:-)
Cheers,
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Nov 1995 11:35:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Nov 1995 11:58:04 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511221658.AA26479@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: 0.999 #2
OK, here's another 0.999, this time with the offending paragraph
removed, and the spacing problems found by bb corrected.
ftp.cs.umb.edu:/private/tex/tds-0.999. I won't put into /pub until
TUGboat folks verify it's ok ... I think there's no rush on it.
#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.1).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1995-11-22 11:51 EST by <karl@fosse>.
# Source directory was `/u/w/tds'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode name
# ------ ---------- ------------------------------------------
# 77204 -rw-rw-rw- tds.dvi
#
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
shar_touch=touch
else
shar_touch=:
echo
echo 'WARNING: not restoring timestamps. Consider getting and'
echo "installing GNU \`touch', distributed in GNU File Utilities..."
echo
fi
rm -f 1231235999 $$.touch
#
# ============= tds.dvi ==============
if test -f 'tds.dvi' && test X"$1" != X"-c"; then
echo 'x - skipping tds.dvi (file already exists)'
else
echo 'x - extracting tds.dvi (gzipped)'
sed 's/^X//' << 'SHAR_EOF' | uudecode &&
begin 600 _shargzi.tmp
M'XL(`(-4LS`"`^Q<#7`<Y7D^WYWE!&P*#$D3PE_,-+832=;)&"R;DL@V.![P
M3RS)]B1.RNKNN[N-]W:/_;%TI"F9E*:05!<M7[C9V`69X*1@"&VN3>*V28!B
MX9`4VK1-.YUTBEN8_)@P$ZI,2U.(^[SO]^W=GB0RM$.!3*49#]+=[G[O]S[O
M_SX?_Y%>]-NW/73!AA1^,C]\VR7#8N\E3N!7`_^2W,#`VMY<KK>_?WTN=]FZ
M3^&*1:F7\7,:/X?3M51JXO"+=Z=2A]/OYE^/;%\W$=KO.SISUN:_?=9/G;/E
M`?ZW.%]Q<U?\Z6!C\17^9M,5>=]Q:W+(=X.\'[A"%AU7#D^$+W[@LU.98SU7
MU\.N#:6]\AK3$EY]ZEP\DW["C7U?FOF5O?>][\S44DA`__BY_7\V/+*ED3EU
MSY[P].+=CKO?M$MRB^L$5>G8TJ`'__R,<"I]^P@>G`W?OE?.)\+*X3V3][M;
M>H8W#ZVJT\_4V_[^D8G;4C?W/UEPC:)/"QPX>+\K7,_$8_MZ!P8&PC,??'Z[
M$QV(1"4:G1RJ"U?V]W=+TFE]ZN+M`Q/A6TX>F5ER[7/7UU)G0-PS8I'[FIN<
MZNW'GJJY9JDL?=Y=UP7NG<U_R&-E_)$9&9E9]O;EW0=;]W7E*UXMUW=L&2X(
MSSYZ7Q.K7-;=P(4#:^7H))XE_;+@S8Y<-95><0$VFWEJ?*\<\2"RTD=O_=ZS
M"2!(M?/@L:>$6S$]VDTC4]CL.S+P!!Y83N6=:E0+3[_S:+<T[`)]63`]WS5'
M`U]@$=.3!6=RRX7YH"+LR&?P##NJR6K@5O&YXPDY\Y874RO6)X7WS5S?(V.F
M7X;AA9F[CE2<QNF/KBB82_/2\"%#F%WY!TTL5S\"8%E$?7$C$QPM"B&Q;%FX
M8O0@;;7D8D5?%+K#S$<?K+K`P"R(`H0S?"6A[?AF7DBC2A()`QHP80N6);$Y
M4WB]8?9OIK?Z]-#VW?L,KWX7+VUZRTFS6@(IQJNN\#Q<@JV:E:IEXM<QX&>X
MD$/ZDK756_\"WSR,]6$M1EM)$)F7,J(#X>D;3ABF98Q:@JV3]#;S5N=//G4B
M]48HBOYE82$#QS<-AZ?7WS>X/<R<VM`L.YXO5PZJS=@%<UQNEF4##\1V((X`
M+JXH0CMV7JSJ#;OZGMEI"<,3>CN>(!@_-G-#(#S2M4?[\()2*?Y3*554()F$
M(<R<_^2I*\<[T/-S?=/^6*G'+WCO\<I>T"L*@6SB,:,$/*/N&Y:,GW"MX5IR
MHW#A8JNU$+DU:TFGFY0ZX"KO-0''+L<HR-5RIU6K0-/E;KEM,.PZ>K2O?\WE
M??A\9&@04-UP8@\I6,BQ2%C8L=!(5M@`O=[ZU*7K3BIGN^#C3^RZ/'56L<CQ
M@9S&R_6?V.38OK!]"B;!\(2Z\L+*I5_?U>%>7J[OF[EZN.+DY[?:ODOH%1`<
MH*")VQ;M>Z*OOXZ=3-#7S5POKKOJY+W#94%[<AU"L\@.>!P!).QJ[L65Z9M>
M:/;6ZXTE)]ZD_L(?<N&W5^BWB?#<W7_=Q@0IC"$!U'#,`U+`+\FVPT7/C;;N
M68#B=0;>%Y0S?K.?W6Z+L(5K6'"WZM'/KVF[6[]VMZ%@E)PRSMZ4)3W$]CRR
M7QE)/TPO__<%J/_/X&H#TJ]];1?%2"1:NT11D**?[PH1=DU\;0&&UP%(:QBD
MZ[@,,2SR%J-0,%54S#QXRP)&KSE:ER70NHS1VAR@NLP;OB"XEEK"-BK""U//
M?W`!K5<;F3@WK>'<-$P5J%/ML<0!P;ZDTQ!RCXN&`CGKRKMO6=O.66MTSMIF
MY%T'"'[B.PL(_A+:P>4M1-?HI'<-&X(-W'UO\L.E!51_J?&](H&ORI?;';NG
MJ/#E,<Q%SW_&N:K=)UI.R<GU/;;MZN')$Q<,7C-9']BQ?3C,U-<U$:V15T]7
M%BSB%4%F((&,RHVQTG=.WO#HCB$H?>)'"UWVZQ^\M0S>QO#T33^?Z?I'>7A7
M:@D<:8F>=%WQI:WX:DU_<\[D,NSZP88%7_JEA/QR5<NV!J`43-64-_/XPPN8
MOK98+=O]5[F^=GE[&9>W0T&E8E`M6T,EF__N=;E<NY2]3)>R\^#)?3]Z?NG1
M_6XM3&_[K05\_^=X)$9A@XS'B.WQL#]O+A4%JD.JILASF_'NW_A9+C&*'M3@
M[`0FCNO3BX6.UG'Q<X,+@+RZ8*YI@[E1O4Z@=S1PFS@&CHR8GA<PFJNWYW*)
M2>=&C>9@P:G&_I5\L9"N3R^4/*\*B.W1S$;=^&US7'[;X]B(=AV#:-DYA?[7
M)Q8\[G^C9M5_73UND+N0IDWM-ZUTT],*BGD>-:/?NO>;_Y^5K92XMAUP-JF`
MX^F!O"ND(<E6A4^O7/F=M:R]FP+/B7-R[>%&<U-R7,4O5F)FQ.2XLV#.KSW&
M[4'%IKF#J$[`]BU>`.SU"MV:E^Z,$A"&2S[SQ04,7QGMKVL'Q\T<''<)R_!5
M4=TBS7!A?:69N/AJOI:((TQ\XCD_7;7G`C,W0/2PBU*IB=M2/[S^2!.MTN\1
M<2Z=>GD_[TP0YXCZ-?5"L8#_W);ZRGON:&JRV<@(RCUY8))86FW"&7&_(-M4
M-I6^-94J%A<=2:6(JQ;3[YZF!](5)Q#->[M^IG@LA4V:QU*?.N_9'_/W<Z<M
MC<SN2:(HR>K!+1<ZR!-C4KC%P.H.,[N?7";&36XL=D_ZLE:-A(=\PJ]]=T]Z
M-<\7%2*/%5H\-"?P#+O@$2<&%SO(XM)PG<`N<"4[QJV*5>@-L\'X5K_-^"+>
MU+]]18PCM5>$55.BJ)Z&F&C2#8BZ9,L#INL'AH4KB`?D8`G7('&DDL7K#;NV
MGMIA"QG81=P?V,!;>F9!2'$F*C9-2'**C<S$Q7,4L<*3O%W3,GVBZ#$1[E#F
MT+EE1T(G!Z"6[H@DG;A8T\THRQ(;B_.LL*7M8#&[!*'W$;^/Z$[+Y5AD1#6B
M1IDV,:4L:?J]X>*WOH/88G2W%LH57F#!.KG\L67%L)F:Y9F^H,NB`[3-@GDF
MF6WDQP^#ZIF*5A(Q(^K>L\8CS483C?2+7577I/Z<.7H'%4>/^PHF\T6M4$0L
M-<A8$%X>9A]1]8`%[(+A%N:A%L[+HZ0^I;EJO=Z/T<A\[LYVH5PV`96;AU[+
MLD9?$7FPPJ_(NAN9+_^DZ#`[S-/,P\_=2?;BD(IE7`Q&NA0T[8+0?#A6Q5SQ
ME#5H06@Z#X,K/#H(Z'IW&5B52R(R4=>`>^0-`'XP!CS,7'[Q7*JC87E.3)SS
M%*2>PC3O*.ZC:S!'DOAXGJ\Y85J"N2Z77=)#8N%VVK1#RE9VTTH$L.3?W3D<
M=W_9):EFTM``DUFRB?<(TXP<=S]3"F%;%2:O"==N>82682LZRHN65`T7^PTL
MP\4^5[V9>:.'B&#'/8Q-JI![H@XF[<KA/0!MRZHP<^%_\O*62:[@T>-,-ANX
M//DIG!Q:11EY?,=0LUL>WS;4LYE^TP+@T]7]36#]Z',CMCF."W9O&Z*__VB`
M/'P/4'6@C#%/'M\^W(2'?-S5W+^RPV@KCJ=1J)@VD5(-F)7'P:$@#D3"<LBZ
MB?`*U8]&L!Q91)\0&Z/-?L7$03=O8I=SC69.SP&<B:AH4$>N'";VB`["9W;F
MOKF$3Y-(JC9Q2T?)Z4@:V/O\/%T=1SMV)FFK[/R\1;I9QU.]HZHK`"9'XM\Y
M-?>9+=XN[>,WA4HG-9_:5.C%J7002`/;9@2U($E[9`^5CAOS2=E/T*-EWW`Q
M#!A&^LEW;/5Q5513+E(65G6>+09,15ZJTH#IZIBH,X.V5*Q2,FSS1F;SFMK)
MF%ZK5S'C4&D[R)/6+8;TD9Y=H+D^S![N&2-BL[1I6.9!,Y0C/`^8R/VV$XTA
M4I9:5,V*8BW#&=A<#.5#I)N70@<!Y*O7;RUJ`6I8R@D:F2NG#9=SC5%!TC"P
M+Q-(\\/U2E77*;D&;TY"800DP@]M3A-WH6VXXN`?YH$3XK^.('%Q`CO22R8H
MP%2_;.ZM3YW_L>LTH_5BYK[&W'C-??T6<U77'+F$N:JG[DER56<N41S8F35)
M#NRW$6KJ4V<_UZ<K!=R7??,'YW!<LV]^5U-E"_@#9<L;5>#3^+'OT`US=-GC
MJ@),>D[1YT(#ZCN$):I&7NYG@C3B:T1^'N&;F)(=9SKR8'(&9$<BK&ORL8?Z
MI$;AKP)0H$&3:HXJUB%5PV7-2H1/#5N@-+$ZZ-J#Y*R-])WG+741L4N6`8UW
MA^F_^'-36[0GR!MTJI>;X"^N*`O;,Q%OYK&403<?E?F[[<*/5%A>V:)S-U>%
MZ3N^;\37>!(EUE++B@,4+/I#7R;JML]VV<K1I'T8B+$,OJP^41QW%BEO>/#!
M[,0/*%'$."4(Y!_ZXQ@HYJX7R>74M(JK"2+=J^63X8*/%M`*6O$*3U(\M![K
M#NDD_<Q=1:1/")>:]O7Z7M)0#J6?^001^]L214WR%\3E&P(5*H$<T(3M+S/U
MDY#D:I$3J-`+`*2P/#'&E1:N)`7$(K=B+BP)%577=?^E^F+W4&;F:QT;"K-O
M&X'+X\&Z?I)^1-4L.907.<6(<G%$E:P?<8J+$!OEJ(D$&]&B#B*1BH=18)O^
M!BT!#*R1V?$,V6*8>=\BE0P1OA73SF`ZO"=*KBA1:<#Y?J4X0%'*)D!,9&'^
M=%4<D77,A3=$L3=P(J''P"CPE#B9\MZ!/J]CU1K,2J+L1,FK6\9E%YUW2,2)
M;S%5&A$!S<T!87-N2/@[E0AGWZ]KGX.)-A7;NZBT;WIU<[E*]ZKNB&62^HT#
M)Y3(L=4]WH8PL^+3E+>$&NOQ0Z9],5XIKD:QYWO(\=GW/SW<1M2,9U>2"@2R
MBB2?F[Y3/@"E%`2=@5`V@:);3[<H,-*MB6%APEXSWSU[5EVG]_;3T_N2SGR(
MG'FY+"E*,BRT(@S4`K-S=Q2G!OC+3T^C#K2"`@V!,\_?,8LC,KGN*=1#TYMW
M;PTA`_H\4W=W,9JP4E2@`(M=3_CYWFYV\0_#(%^B9M!Y!;V$)ZQBNQY!I'_Z
M)&5"!W7[OJ0E+8_]I[.PI:H2#P&J`9WBP%:QB?7AXLE_ACT*CD-QU&8+;A\(
M*G3/#M#0Y8W?X%++VU@Q5&UKD!=)/K%"O@/,O_WI81W&'L$FPVSQ_*8Q(:^;
MF'IQ9NU$^$*Q^*5!-+NIQV^=AQBPZ*87^B>F%MUT>N:,,P^/7I4\Q%$Q<WU?
M7HX[N]?W-I,;9ZG&RB8"+Q_%0=:*4,)P.O:"*DRS1V]$UV^:U6QT*BIOH9R(
M%:TJ4[H*WL`0%1W+XOJ5`BL6X.0$B*I8F$R9SHKA,>1RZVG2P(^9!NQD9)#Z
MO8<_T[Q._<5>@%X8TN4/4K\$[4T73>UE'-$C';R$SZCJ/\=<>D#KS][6.L?*
MC[ATZ$H@+^8E2DIJZ5,/?>"8B97??\N#S5W\C:#/&]DO7CA[==Q?#7&_D=\/
MA:H[F]WAXLQ9)K=@R"R<3Y22=.ZR2YZZ9+:\I.W<R2^8,!HS[ZE^EWMT@\/?
M*)HR^/-^*:B=5>,6_N&92W]=_?#<)?/RQBXK\J_"W*6?YR[Z($-]ZDUKQ^(J
M2L4U3_`D)NZPJ5GQ^"03/H,WTRB#0@`TAZJXQ*?/XD0JF_3*@R+YT[Z.Y/VZ
MMJ.#$4-U'>]OO]^ELQ&G[O&$(=T\05"?.N=CURA!MJF)0B-3]N=I?A*YGOH<
M![$5^0D)R(Z"BLJ*JK?JB`:F'2>M1,KI/I2I;$A&_@A/;L]ZIH>OV48*8=H<
MU16KJ=VQYFW)["K4P`U\_=ZS'KHT<<KNV+]`<0[\A_RK/0+A_JM,$P)(2S&(
MVC`J[%2=_U+E/0+>NI,J@1?,L_)<B-,PQ*>3DG9<B8ZA%&QDF^<IP:GRY]$7
MSVGHNX[,3<;_QDW\,5]O"Y4V&7D95*,"JQ&E#1U5M<58TO;:.3$16Y_Y$14<
MC_]E^YD>S,0JJ*D`I*5N#N4Q;1220*QV%8%"4E3XP&H!K?7WWJ5.0'++AH#H
M!*[2D'!=.N@8]SFJ2'?XW:<K*V04G0^FR91N3&AO-*:*1`(VU1"1'7L4NRB`
M)7(5^AP\DMJ?;3YEKBNO/3Z\9_(;`UO"S)57-XL"*`A#!:&.FJACVW2ZLUV+
MM(\(<>.8-9V-$$5U6WFG%+>71CP*%./$NC=]JJ%./&<AN7$@@S4F#)IAX\7X
M=2\)1,A%"2D"6_D(I!BEOGCQ8[\_&&9._!UW\-Q,C)E>.3$%;%6Q-Z*A:*1_
M7*9Q5*=N(?[V)P8Y,JH"$7VEZN"I)H;:%HE88&Y25%>;E%N+6(V/-.H-1.5X
MBY.\;2Q8X"+ZPP:D)$K68Y=ZI9L0.XRM--J43'[8*N'+?#Q5H_.:K9&
M4+K?@K5U'\I^]0UFL9&M7CM;R>10;3@D;0UF'VE]T8*P0;)B2*K:%_::#LO0
M&Z8R1F^1T4)PH*2>OGT7>8;/.8U.E%KTR]P%U*R5MY>G<;/4(\3<H\-J,)$`
MWD!Q6A$]W+Y7*."V!T[9QS_"_M0#_=O0"ON):ZB69/&[;HY[`?:164-.3T$:
M'U%6^FQ-DN/ZMEA+3!D3NFQD=WR7*W1MK31-<@-*U/"_<(EQS8[6?%#&1YWC
M[ZE865H*8CFS==_TXRU3XV:V&G/RJ$K5),T=H@27:.H1\FW5.EF"/2(:#5R4
M"BU3@-7UU`VIAMXPY;4?5\F.W?]0IN?F)L2@DCH^VZWF57'_39&24V/4U#)Y
M\\WO2`=!58UG8X\G33:R$_?3>("LG#MCF-S\U(Z#BMK1&[[A_&]OX_B'KTW4
MW'I8G/W>PW.0JT14MU>,_10*XV75[)V&%:*1_GJ308QB"(UYAMC=C?0_=<W;
M29!MT2-XDD9:0<T.EVMU$6U2"@5'-0LU]')+16&6N2#P??;7^!V+R`>NUJU5
MB^L0CH50S<&V:LRXS8?8;75Q(K.<R.$YFOI?`ZA,T)[#PX=&O[Z#AOJ-S,HK
MU(`&3_I%FH=MY'X]44RTQ(Q$C^_TP+'H8`Y\.0YME'AQ2VLDJ5=G;VUD]MX-
ME^(`4J!,F/U(4P^9A9U'%N1<V<*3!LP`JNV$\\D9<436,R+%W>J<_L<IW(WG
M5S0,50J":CD$=_1OCSW`4[;,8Y--;L.%FO>TS`50UI21C_-3XB](C%@Y/`IM
MBP>-?/_XJ$Z$LW8ZJ_G!GKG_2&R;BR@W#E_\>@RZ74G#F2%=U&[L[5\UJSY5
MDX9=#LI3?5#TU#WQ0=%$54J-^4^:LX8.MW-CGOW56\>DH*^],B<+?NG1>LT"
M4_/50#+SDT\VVZBH5Y'7JU%#<X5<24K:-[?R(RAB_VK&6G@LX6G+5\%`=JS7
MO5[ZV?LYX$$\@K"5=;DI4P.J]D"2LG.Z'(\K=!;A*_5\K"UNJ]0+JE#\?5`\
M3SABHX$([K<0KH_OW"2;MM`5F;N?9P4/%VG:-7)?7&AS?Q_E*59'%:,:\>3*
M<DKT7B>*YPY1>SK"`2N.BP&'##92])O#ZYNQ50ZI654<\C(]EW"U=NFY%@-F
MM$V>R^=X8XZM"C_U4H'>GJ`6ZBD(F"N]N#O(4[NLT16_/U"%L78DA:[3*D1I
MP7LV+&V]I-@09K[S`%;@29%.9=#(UWXZO3KPW-66@QVOAMFX@D8O[<\Z_UIM
MF:,JH(9X^O1JN*]>D`:5\1LC+,.J<<R\Z'#5=/!]QE29FFS2W`6Z@\\Y'H(A
M.R?%)C2$\$S#H]X_S*;/1K)QQ3*H24V5:(K:'C.W%4A3@_\N[DL`Y*C+?$-W
M3PC(H8@N(**@+C,XTY.+!":*3$[&D(,<"!)7:KJK9XIT=[5=W<D,K.OS/L"8
MLJ`M,RJPN.Z"N*N-!S[Q>F06=!5OWD-]&L0+]>EB7$5=Y'WGO_[5W9.$M^+;
M7=?,3-6_JO['=_Z^WX?QDX#L#]4C=`KQUW2F"ELP6U.-6.W!K7/GE_JM&-6;
MOH\[_X9$L^Q#S1)F2U_#WT=::!-C?J[T-:K@F+-:8S#"B-4`A:Q">"&,6LV9
M^,R>EN&0%2S@T+T4S6>OB[QBD)XLNLA9HP@<>'>I.#38)9@3ANFJDINC^<Q.
M`\I8&F%V^E.X\UK9Z=F*0U8N+I#0U21."WDW-"P::RQ7IC_5EKQU/!E/6SGW
M_G1@\W4/DO9++$EC!5*(J#91=XI(SY)[U3T:^^)U+,%2HZWK3H#FKH!HZPYX
M++$#'KDC"WB<]YTG/^#Q12HS!Q%_,8IX*C/_V3^9,O,]-S[=/R5)(V4O/)%G
M],)CV@6GROILG]JPQJ92;QAL^KUI[Q6]4M:#3K0#K`Q,5.O#SH*)O>K#:\13
M9(\+3;`DY&`<^5:V/$EBRBD4_'J1A+@O.4F*WE4[8G68]SMJ-.:C24F=2%`J
M:&;4T?Z0)WH3DW"9>'GJ?/@4V*JW,K?NW5'UJV6IR#\+]AB96+@%R4^FXU\@
M5:(>L[6W#YW?Q:NMS;G";#Z?+:WE#?.&%![1M\*)/.3[@+505^T%?[;S[$45
MU+(6^(1TKAW7R@H6)WF<_)Y;3_S$=:DPZOW+C7<>F9C#_<M%^%9<>#&T/P,2
MJ1VK'W"^VGZ4RF.*FH5]ORFO1!-XTN%T0J)2/#+)*/*Y`DUE2F>)ZTJP&Y$7
M+AQS'S747D[E=^04.9[[]O`YI[Y^41[/SZ(#'QB=R5Q>UPQ[>;J5N;QM8A14
M-H,!:3;1,23-KHP!?T0J(S,?BE*2)G/=?%M]-2OC\*D23VT[C59FYR<E?[+K
M!C[7C6@:?PL"=8,3!`X#<)J(X@KP]["**_V@`?(RS#WO815.LG6,S:UI\[U)
MAI7G6!]MH7O`.T!OL")I&TJAQ7!W#*=\EP<3%DLD-)],VV(S;6&F\<'$,\DT
M?H@*M@C6'&OOLPD7P;$*IX9AT[J'4\HNP.!,YN9[4X%'CVV0.R?OYL1[.._7
M_PM#UW'OB+9\#CE8&_$NR@_`MX5'/?WM=WI1VW:!8,<5FL0-)D])I0#D(U&`
MG+;8X'@R&R\!AQ7L?\H`I]2]/!N_%W<E?W#49M@(*@S#L4:J#2[5T_.R%W4:
MIO;-9'4Y1:>&)\/V[>F@@Q![V<?%]*,\0]FI3C1A2O)%F&D<0-X++;#<J5>O
M=!@#U!E@A`?-2K8CR!=*$_KB;J2_305J\N'\SRS?7F6T$CJEJ3>31^+[M3+O
MVBC9T8XG2A"PCMQE55V"5#"H,Q:XN+9M4KP90M`%J2RFRL*RKD3R<A+_+(`-
M9R+?]%(I*4S3B4,B_YH=5<(H5=TE6C9C/FX"792I>6I>.HS*TW>PA!O:1M.P
M*3QZ-<E*ZEL,MC+O6^SF)_)@U6Y>CP.V%4=']&PX);,;G)WN-O>RS>O5M&5+
MBS_*F_"J-!Q%L</LU`]6[_)J`9DJHU$2O>2,`*UGZ@UDDCF/+\`7E8=G'KCI
MSA/E8+>-N#6H0MM[D.6CI4PR'F"REM`^!(LA0DAB!:RH:*+LC]-48+8+0TL#
MJ/"ZGL>FEU,&Q0\?*!$CF=]#/M*6'X)IL[/6PXU*K3W'(R7-XU>+";C*'AK.
ME]]LE#DC2LJ$-=)<7\#I&E@F$L9JF'BT>Q,WH9]-R4FG%NC[#N]RZN#7V&$3
M^MUP4//]LJ3?!W0O;N0`/UHR?IGW,J$O),!IB5D-6I!V!'__]`N^88S!I60,
M6BPV/_LG+46TC,'5#,`@Y$WN.9^A+:0[U:0(>,NY4W"Z.+Q/:)+<<]XF&GW^
MUXY2B1JWDSP]G#">SR"$H9NFCE)]>SK)_WXU:EZR%%&KD44WQUM(9H&L?PX;
M6]-20N@:QBA6!KZ%%:`@4)5E"&:,&)C0RE4_!((!A(#G(%H)@7#@WW@2`$:W
MUF/CQFM8+@FES%_5E+Q)>/2GOWJ1#R],+B4\^F/9!))5=4T@5,-.X@_M,^%0
MB>LD$=%$:W%`WYTJN#4K1=VQ(3?B6K:R@]_IA>VRDSZ$Q(*UT]0(?0/:M3"C
MKH.SB8@K$[?KB*K!Z'+@;-L&C<I5_Y+\85B\P_;@3';=,HRTH,$I#R%PN#U,
M&]S-L=#+N_E!Q0"1*=S]&0K0PRTH#U?#L96=.8FWBB%=3;):,WTK_]2OX;`E
M^47&/`A8?9>:=3S%^8%XVR2:4:AY;W]M`ACGYPYI;APASOL$XKR78&HO^A9M
M00GC%B0\GVG\RLK3.U9TU.Q<BJN`F*]*G#*9E:AMQ0[5_O!;N8^>R1+'SNF&
M?4_Y9M`\`2,@X8(]@UO]J'N#2>3;!`[EF])H;?P*>9:Z@/(U#'^QA=8NSP$Q
M#Q((-GS$:HM<P2XS)M]KOVYP,)`X/9-;^ML2>DD,\\(S'$\Z$2PHF:6XA#$N
M8=Q/FK25*W]OEJAZ\[6=[8%!F-?8F'IHR\HBQTORB^%_Y5.TT/<&,QED!!.D
MK,A)NB:XAOC$P.47&8^F8X%KQ["]8SBZ(GZ3A%G9+H:T)AKCN`1KI4A)&0R3
MXK1*#7H$Z,P:AVJ]M-&A#H^$+(LJKVD7<Q*N[.W4'(`?,=*LF;C?U41,C'0%
M*Y;:P8J^(PM6C'WIR0U6S"'&[CG-+X6Y/<N["'T>?ZQMR3)2VC6QO#F![S4J
M3BU20VM`=GTO89?@'N#!6'7RZT<Z$'#S7[IOK*IU".#@Y4Z[3$&>#AXDL&\J
M&A)`YYRSK:"-&62'RX^XU";B?C8H]E_V)"HZ],AFLO]\6@$/`,(A@C(13Y=U
M[Z%]R_N1/*UXMM:L%AKY2@E#?_O7SX*9ZU3+]#/&2>/`C]%9[/O;OV+W(S8U
M`;@VEK-`)@7LH1+8O1[EAM6X8#!GP*!4VF1UAC:1/P1"G3]2C3:.1_BI"1;B
M7T;>+"'DS;;P3]]8:FC:<G<,*TW;S%THP/;<^,R[K[-PS<<LLWTYMIO(7);8
M0=TGW#Y"#3FTRKE6T`OAO#WG7>77.^".A\:7P$*__:K1,'?,`BM0PM$%FJB*
MUV#KN5E%G`ALM!2$TY!WCY8Q63LQV<HXWT^H`9R;VZR2$,@'UBY&$-!F[@ZQ
M<?!$F*!I=?PD<FID%U?8<)@^LM)WJ`6>52"<?2OWN>NMF`U&BTS*(A#``R78
M%?;`0H?U"JVH;5I';0NCK&&DI!R"T)^OO4FB$-USC%8AJ-/KVJZ:?&2+L?/@
M,0XHP2*BH8<Q'LK))\'D)%?1_0)^76*W"EEI692:!/2E?8<3D\8T<&*#-BX2
MB:,"3.7ZT"";XU:+!<38INQ,@(RV((1H)('I?=--;<(C@Z#LFA\69)9Q,I!`
M`V=)$L$(%SQWGXX@)&A#*:B7=?]B^_Z*VW!P#!ABPX%0A^BO)F1J`]%<I&GV
MH$LZ!ZWY0<>@731@/899:@\S[HWS]*RZ\ETZR*&3&5W?>JX]7M$OI.>:4KG%
M[II>>X1E]@@,M;+>*+/CQ_P[]+G/>)0C<(Q\"$S`T0:5*_)7[NI(163VM%@N
MCR\NZ"4BE"=\*2T4%<1_'=Z-E[8'*!UZ1"#<:+;80--1GV\BF1,(;NH8'3?0
ME+B:\`[R_:W<`[]H>UK^QG52)5\$@T!UT1)!@T/DH85@H>-`TG).7/2*L.\]
MRQE[@78FA8I:V?E?PP$5-B;H$HI;<*FEY>K!8KQL1NH)K$3/,]\X"X+,J^;)
M>K;3\^,8&@<#F\2:/#<U%6U0[E_]@F!^6KDW_(@EN8@H)]HA*#R8@[,T.`$"
M@P-#YKVI"!159(Q3!LK9A"PEV$\$0(,1.D22*DO6!-TF>OWA<2?`Q"C8-HBX
M8KD(UUDB(@4>]M(T-O/V%P@Y[#_T)CX()_^JAXW:+].&.<]+KI]U*[@30'*>
M^;59V7,8+<.;1;,'L@L0WT@^+L8\U2,2"ZR5^\(_%%T78\)!D^,_`L"DK+D%
MW8C\7GF3#J&^X+Z/4Z\1S;]4S42;K0/[L#B3^V^/,)<&ET?#$_11D7PNK.Z_
M_4]PQ:+)&!R&V@WPMI%?9LNJ'^<_CZ&7]@"9^A6W`IYN7&R"!:&Y77A8OVRN
M4J71'FCU]7UYPB=C"=3NJWZ&^U0T#L$(NQA2=J/+U>T9A<>\/K^5H1HZEUI.
ML3*_Q(X1";P79,P<2\YQK""U-6H$+/>CB7KD5,S.V%3]=]H9N9_7P);PP!M$
M`$37RY'0D2-K,[Q8]G>IUS*J9M*](45VK=R-1UN[[NB^%\Y62HWVX$SND6"V
MB'%-D$3A@HW_>TQR/;%:?.W!V"@R_3?JGS8"V8J1*A()1EAJ&KT\.Y075QQP
MZ[B(*,!]`IN!#".LYL-2(T9H8-U6E_-TKNT\S3\RY^GETW^!3.\2`9LSH_&>
M&Y_V^7N[N01F.+__X#NX9%3PR8X)F%$$F:1,%UB7X@NYW'M-L93R"734VW`\
M@3=-*D.<9'HU?=+/U:!8G7$EWW8V/AH-9%N9]K#72>3"`4,,*4;@`K?41&MR
M=@<>U_80B1P[S\`5[XFX1RG;D7":'>Z5;YH=WO/^$P[\,#E+]BVP.&,SC[>Y
M=L#13R<WR1:LK[IG%C8^[6#,W<@_2(S@/^!GKUKR40'S.Y+5><J[.1E_RMO:
MCJ2L@G3%L)&'D26;45MXI%(T2(95R3;D/>(02IA]_F>)-9N?/ICXP&OHS09:
MF=?\58*IYHT!SY/1R^Q+EL&:N?617L`ZLQ&:H$./2-#+URN4ZU=6QJPAP/V]
M-JI=OU<_E`"H5D*>$B.=K]\CTZ@2`SX)\['ED;#/B<:1`.'+*YPB(F44:3Q'
M0#6P0+QHEV`9P%($Y'K6P:H[!#Z`!^^.,;/"'9UPV$KDJ'*A8]G*7?".KF\E
M1TQ3OOSV<!RGOD<1(I@$=-WD-2ML+HG;A$F-),<MS_''@P(XH%K+Y]7I72@X
MR6/G>=>;W;A].[LUG!?%8QMT!J8[9C5J4[!J1+(FRS6ZLP[.H`D+AWTG?(Y4
MT,>G+'7"6&(NW8!S'9%$PW<C[4E5)+C)=-V3HR9[&!]1!7F0%V/FQ>^<)7,Q
M:$RC;LE-'%BGN0#NH]6@:I7E-W,1(85MIG7_TLLT`_E>C,)-,.Z+XCBT<.LX
M;G39JS?CP8EZHQC)`1$[M.YR-;38M-:>E=D/<]=<H'E^KKV-80,%#0;"^-PZ
M:IUD7[/[OVS2)=:L4>B`HE)SO5:_6/%@P:1R:,8$!>LOS!ZXC>2%/!$N"1JH
M@7%RJ4*(=*]E<&NUHXC-CJ47@)\&D;N3J>3$;[5@JXOS2Q+!N$^B\B,;R:9=
M<IU3KF#W+3)%I\W!@+^SR:Y,`XS(%]\!%I2+N'L(@\@"J2;]SCA<!O;8WAI9
M(XIZLR[N)W<`AO;K,)6PS?J>=^JFS@B]@E5,G5%2L!)/DC33L"`)US)812?N
M,:%Y!NAN\JN6?,5V8A]_&2*R&%5PYZA9Y@U[PF/^ZMJM[:%N-&"<`F#0)ZF&
MBE4Q63@+A#IT?;)GU3;M,Y^QE^IN!M'5*C@H5([HA7"I""3?H"ADLFOS'=JW
M2S]C\.&F_S`JN(>SF8:I]5+.X\ZX6Q9-#-;8[D03CX$3>,UC6L4OX7BCZ`FC
M%7!8D4Z;J0X_3BB1L'"WZH,.G"+JB>E.'39H[R^D%]CP,[R5XH(<>)6X%`;F
M#(;%;-F9SBTKX-]-)31G7:>(;V:NCM&:(:<2SIB_,7&<U>7@[3"3^=KEEF'0
MRGSX\@F176DO5>P6_6^6MC'*MQX7X7.'U;6Q;OA_4S1=V^!0VH;]Z)G<LC>0
MJCGF:AP/?YF&AF!EG<-!$A$CL0'C2C34D&B%N:&C9\<VCFU;<UG41CQDHGG0
M`*6#^J%_E&W"'E[?U7=UABIFLG=_2H,("K@XLNA.BCF!SV\9XSWJI\)["!"&
M6`>:=;5@QIL>UYHAK`,DHUK_L6W[TW@T0>F=A?6=O63ZY'0-I@"3O`/_C<3R
M&==B^I1^RWYDC=B<P`&/29?$<@OO@##WRC=LHWP8:B\BKZD)DH9FG([6.&=Z
M\7$\[VU2%&/D(Y,*`'.O*6Y^)\J=Q"U#%6@P*Y-@Q)K:/1_H_CZO@F<5M]"*
M,V@+'3]`O[)<X,'8RO"NJ1:<6M#DN.SF&%YN*Z5%(W2L<2_,?_<J31)(\1$\
M!D785:LPZ$VUHU4*\6.XOPF*D3+;5ZT2O!8[/YIK(<O0_EI"X^T@E_DLD`;^
MWW5O()P1W2D-L#C;=V%Z4L;69`Y(,G0N,,?2).V#=4KPD5-HS0OM5Y7G#1.B
MX8*W/C8:YMKC%1>K$L&PKT2"35O'01H\%[G7/]N:O(!UAPG9X)][VT]BSM*^
M,@QW"76/.#6Y^_:,4;C%K</+E]1JH9,'U[D;G)W46G4`1.T7/>'JFHY]X;X+
M"D)C93&DD+1<-5:-.G<9R-F+>VPT>21M-Y-@>X([[K!6$DU)CSA2+]NIQ_@5
M+T#K.W//2@IOW_+ISHIA=BU9OW'6+-%L\)1E-XQ6.[BP.MQ,J>O&J*7N`$FE
M93[6Q[(I91@Q"A(?@:1K'1XK^VU>G?`:=5=0%=]ZIJ7E!%-)']8=M5EF1VV.
M/K*HS<3'_R)1&R[!6KOW]CKE>&X\^3TUCML(@2SS'UUYX`G':C+A?CM6$T^3
M5:(L#_3W$OH5D>)GZ5>XK_2:$A@=2=2F']&+QN!?MY:U#<M6*\UF\-$4N2ZZ
ML`7*B5JI$FD%[\[.F`Q#]T"[-Z9K1(0Q(Q&8+HSOK%P5X2M&;LQAFJ=2)VHQ
M%.&O:",D5N*+[[VOG9#7L);1H\[SP%N;,HB1;83$/4V0]`,.97\XI4IRE$>+
MOF+3F-*QXH(F+P1YGNAN5[F4W*N20V\5D`-C:WH\N+8SN;>F?!UD$1SN3LV&
MZ-V"HTCR67,E"P>))H/+GV*N#P^D]JCG@QKVW/0">MF3-/?[PF*XBZR!DM5=
MQ(L;D']&^2@6N[U?9Y<UVT)CJN]@,OR(@`]:F3]N(C8>T`+';W84A$O.70(4
M8"T2I"5=$MVH)MYI/RPTL<;8$2P3KC%@'ZIV@_/G%17IZ4N3\(%4P#]]7.#C
M-C[P?-S]F9\\W1'<I%3W24VJ2`+.;MGNT0CL7]BRN!<RCYV)7B+%+IOC9:]`
MP90-1\-Y"6%@ACG\^'?)J4D#3>CX[!7D?0_8OAR@'MJ*'JK+@B=QM(+G`&R3
M#9@]0_,#E>-6TI*>2V?[[*"GYRF;H0#ODBYP^',$*7J,)!.%Y6<[R#2>O@(9
M+\$B`-FM1CQ%JW6;B9-)UHC,$$A-#KKV+QJ@\GX761=8)6K\B>JB6MF'3K4B
M$@*5F_\VFD$J_JOC)?V+!YA5A+#:C!P&.4WQ$SXK8DSAG;3XV+7\62>/-32*
M)4]%CL?<%1\M^(K<(%`GB'B'.L_SAW9])CP!QG[OQ54$*M>Y6[C$_>#+D2PL
MH8=4XQ&/?X/W/T\IO$F%X@,])AW1WV"LNZ\E8WWX)`N;/Y0@XW7"!V,GZ"2%
MZR3'".?_Z3$J@:7(H,D]XL3#85="X))]I#FRZ`AI5^ITJGXCY644U,8/W$(*
MZH$K2%%*';)CJ2K4QQ'16$[;9[1O^ANS!1*C?]@QZS;+;IUB&1X<)URXOL<>
MP!,*XW)"X8'SC_2$]GA/9&\[Q$DM5$#$[&CW"[3.R`DP+1Z[0D_O\G.3S5YT
MCY.T]MT*D4,"X$^AC;&M]?B*NT3+BKT/YVCE[RZ-_'*S`E^4_]2:=N_SBSF6
M5N:3/^OY)@_,XS=!J%[R(E9I&H6?CLP1%[.F*YKPYQ4K5.#M5Z38N8HFL!LE
M4>\>5I0@._BKAVLPG7[=&:Y5$3$+.C<)Q"0E$Z6*7EZH##.V=HXK4=D.DV`8
M;C;\F@<#-QOU?*WD:/6*1#K`;OV,*;(PTHQ,3/+C]NFFIMW.Q@(8H;<IS^K=
M:X50#317^R$U$=;?K2OPY2$R$1I!F%W\_3:2'>`31VL$B_.FHM4#W:[`<ML5
M6'!DKL!T^<EW!>Y%J/*B/>'RZ@_6(@-[E=I&L*&&;L'0.=UN07;I!LN24^87
M*9A(F($0VER@Z)T-3B#2`\J*,R(Y#=Y$:![3QAV'<GO$\@,6#;0R_TA!M&05
M4505W5T>6@^$X`\S7[RPXL=%=T#@(I*@8$,:U<-NE+L2I5H19AZLHEH2;FY%
MH8H;SA^)!M@S;Z!WX$E(*OE:V4>O-31M!J9[YF4&?IE]U&D;;RA0/4<'/:%K
MEP\P1'@=O)[=%#YZ7BE`7O&+\!O$2<)$PQ[<)TS`T6J:`9/,!`%#$\-@[O3Q
M?O>'0!5+_")(R(B(<2%=^VY-DN9S;[L;KEJR<.',4;?]<['FT3E;MG!A#/\>
MH#\CWDBYNH)FPC"5C-7*[MA,64N;H3DIK=BQV='I8K.<DV!2^I)[TR<W^L)>
MS844G(%!:!@\_V].!!>]X!HN'\.\HC[9G*0('OM?Q!1M4LPF(M%`!KQ&U(W,
MWT84FZW<LG]$]8_EGABJ<">4QXHWC$89$:ZC/(D]MF$"*(\UHGOT,SZ]R1!S
ML*'0ROSV0;;O19,2)Y>2KR)0O6I<8:GK*W<#+X?WM]/4H>&\>YZ-2WC,;/K%
M$D[6S%VWV&`YO$P97V5[9+Z3EXH)V")8-`$+=L&#-L>40@2+/G/9)"5(J8\8
M-,RZC*VGQ$O=M>JKK+`#GR#;_<%`1-?FC69AD\)[#2<U';J**SF/!$;!-<EI
MSK]*&0I4YJ5?,<PNNY#!)8S[5P+0,G<5"##;5F$'2O8&2P0EXM]*,$P>02LV
M2*C2(>PLAN(:*8.6KNV,.$8"OGM/Y5S;B?&+BH_&5?&)13E@FN"7U:J`O6:'
M>^CGB=*?<7C+;*WX(8UH+-:5/[J0+-:;/NTHPXY(>54=6C^=%JPIXW5!:[9`
M6?H[WC4[$93`GMA),)FK2F#"D/VZ]4_;@Z9)UAN3%5G]W5^(;+!I>SK/4^Y]
M7VFKI-*CSGD0BL=N7D^1+#C/MURG&1IC%M918-<-B,V!K_WI3T4I"_[),6A?
M)MNR\*9641&F6$R4>P8&25BN_68#[*>8)PE=H^._+,14\,2N>6^I!9X*!G+F
M.45G;XY6+5C,<ZK3FT)+IU<<TZG'_+Z=X-I!M#SRM=Y:68,S=KC@PCXYR>CR
M]MU)/RP^GX3-YIDK\<?VV9SLXI!OT6\$%GC4K<]D'OXH2#(41(.MS.,C9$Q$
M-6\*#A@A-MUZ+'_'X,-/I,#%E#DP,;U>'\'5X"Z5P1=JX(U!W)0"L0JC/&+J
M+Z"HF)*J(B9G+A<9HXO*E`K141RF_$01M=V:"XGER[33#)$'Y40FJ-;<CW<K
MV)J2GL-;1>E/P'7V<D1"#<^+#+Y"0;)*Z+)*T#O,;CG0I4(FE[5!>3<FX;N1
M>I73&]6(>CD(^PA6,)*EEJV]WP-;<F=>SI+U+EWCOO]I;<+""$R/MVY$P2L1
MOK`J=UPB?&U)\4E0829)V/.:;:;>":WLOBF91&N#450@,G7W3<97E^I-K32)
MG`KAN+%CQ>!,]H.?GY2>2-S_A[BB]DW5$S0MFUZM[)6K;!`T<L=)5)?5`Q>[
M+HSVK][[F?.1"OS*"XD*G$H;-45+I&I6JP=P,XC#CZ2"/*]$O.@-HEQ$6$0T
M*<6$:!A$:++&3EQJ7GTUPDWOG-]>^+&1]N(7Q.2NPE\PL5*)FA7\ZZ(!)>>`
MG0%;,3PJ]^T[/4/\U:.H,?/HVPCA"H(@PAK/V)UJ(",C_`W9QG`H<%B]0LRZ
M+P[P]2H(G7_*J08=C0HU5H4:)UT(2NI[;-]>]L;KR@5^J*"TF-%GT%*-M
ME<LV,2S<(O+1W7W`\H`6DP=T*>Q`I^P5I=!%0]VV'T0'Y^T_,&2T;_]FVVRW
M('D%V3O!)-HQQ@Y#7(;2J8*0=HI<S88)*^)T[7M6%;,`E/&#Q9]*V*)0WYU2
MX5JJAE!C!BH'R)L1"<FDL?0OJY9Y+K[=,/>*JY'!R"$EZ2E;C]I:IM:UE3FX
MOLVXPGTL]Q-##^6I56<84X>A+5@:&"U:&()34&N@'W'N-8L6PL?#1&E)+]VY
M^)HE6O(FT#;R;K1&!E=B<7ZI53&=5*6::85I$"LP/Z!&.&G45O9+NVE/<R$:
M,J5PV23LN9^]A.TL.-NPY2@RFH)]JH(.#-=:Y%8Y=9XDGQ,Z)RNPW<I^Y(T)
M;=6DG/)IH4P2UQ-,D'/^.H4(D^\'N7)O2(&=1#(QTMR>/.4%##@&B`*?DYN6
MADQW(GKT@/W>,!7PX&EE02U/CX1'W_F_'8;_N%T.N_!QE-F%#))Z##)HDFU*
M3##_8[XA&J$MUV48_>%AWDM.L^%+%!W[NFEI.$MELJ^+'9G^3SPP5N(>(&P>
M=X59SK/#+,<<69CEC;N?U#`+,8SNH]Y<K>S']G'&V%&J*IE0S)%2[0X^@*MW
MHGX*%SJ-I!YV(++<?=4')N@$F_K+'T03SL1,=!9;F1^LZUA]+0R';3V-<9]F
M/=GQ<`+75\:HL@@<N-^_M'M;X/XL*HNC8%*9]B+E7EMO6Q!(AS"UP+[2QW9/
MA-@-UA&LN[C18$??>OH]+S,Y;.:8V\C5A`UD%3GXO$>O]R^@3D?4^J'L3_B+
M%MZ'&_!3GQH%,WOW;MJ!^5]\D3!+-YZ\^`QAP`>9V\K\_$]=IL?S'[1+OJE'
MC60E[?Y-IE\4>^KF3_@I!"^:!!,09HI(LCDO;M-7;M^N#%B:I<[/@!2\R#8O
M!.SO[HZL^DF['*;H,]@H'V\5TJ:YD_<=#J+6M\Q5BW#SG$!(\@LZO"&G9U%G
M!R(R3:8S6RG5*+.WY_U//?5$NPCVSX'+LVO\!9<79C]_"F7&/GAM"@B';[[/
M?O,?5MM6U8JC=)0TGYQ!P#1'[I9W'GP^[3UM.[(`]UY07K3P*S!BK./=/<XE
M4?Y.?@6AU]ISH^(Q'0IL"+`9#PZY].Y4K8YU]OE>'_3_C&WN&HGQ.3K0X1<Q
M4*P.$:3W0J-VKK+(`_$%Y1PS/9">TLWAO+>\9=/6;<GA[*SMS5S]%<HJC_X"
MG&"/4!]#(*:57DUIR@PI(2\51H!>ZD]6HXO\\?%8,*N9Z:-2)9/1^FK<;$R>
M'=CTO[>J/+49@!D'R'$HNX^FD(>R`R6.2@J9=_`%UPT]>K+9)T<7*H6@L&CA
M5S<G@+VVA3`2$U1#1+H_[3IGD@%2WAD8Z6D%TDRUW!=H+\J]^!6FCMMB".\M
M+S[0*2^P!FXN>?&!N>5%YK&_FEM>F*\Z]P]M@8X85KC<ME>,1@V\GZ,-6#)/
M(A#)OMB_K;HL`>%HG?#I<=,EA4QU>:<VXQ_5E_!05C>9?0;6"ZPQBKI14P2?
M<(12!2$YNC1`C%LK,+LG3QB^2\,U#&*E)O7K5,K;)U6BS617_H8DV@4[NB1:
M:FYWO\22:(0@-0Q_(G9J5.=8LG\:]Z?PY,*_92=0%X/[+V=F/_P#F&>_^6:Z
M1MV"+Q.%7.[W/T88[8;-C%Z.!+0<5=Q*E#*UT:+\@-1OP@D&BZ'(K2CPM3%Y
M*X+M_X<XM$_>$Q2'/9^"YQ0.*4('M@\1=."LC`5LLQ2\,8K'J05Q;LT[.M\I
M]_(?M?DD(['861FU0VQ,N2,SJQYUQG\(!`R(PO?>XUC9NXAKT+C!%8$H^!*B
M)^L,15OKAO;<;N7OZG@_>7+;%.7*U'*XDW(E!'\P3!U,KJV=1I!5SC+_SB6U
ML3)\W(L/#OQKL"RDO"K^IP][5I[W321R.'''%S%,=FQX8^:VVS!,]LYK+[/,
MOD,S/JAT-++U2&0CUP/C?QU".IK8N5Y].%G:%N&!Y<9V_8]PPQV&N:+HP`JB
M3]D_FX<!V@/*2$F0>W!`K1$)$DLIUC)?'S3D^ORA[,#<R9_JENN'>:TT_#<?
MSO^7WR=MC4]^VR&!D'-)2)FO?K&K3:R#;7<>D9TLSILHCP9/+%=TXQ=W$UB=
M;_N6QQZ9;]GZWE^4P$I4@0U:,WK@"+<(&Q#:S!?V"*5L23N0&4?[1^N(:7/D
M%0/[%Q+$A]]43TPFW_CLI^TW0F494U42;WG3<!Q8^&AV%/]F?B=TO>`K03?)
M,&TA8_<)I*%&PNQOGTO<,-B3J>F4@\&9S#M>K;1VK)-%0%+3(./-3S2](O6!
M''P&(EO#W)7O&JO.9,^<U0D=Q"%1-<2I-NC*;@?N/.4=,+I+'4])G<9^/:8B
MA]CNM!M;7HZ<>J47`R>5&T&PE&Z8OJYS$EPE'%4DQ+[].&=3O_W=MF'YLV*G
M@6OCNNT^]!8Y1*_Z(2<!@=MMO!!%42Z[9<-QB<M#H6GRXDD$4@933C_3MUB0
M=B[V)MG3B7HJ^@44VP5TZC#ZAC6ZX;P?O!H%=SYOR<L>5[0R!]_7-F%#S5E*
M(!-IH[Q"SPW$$P6"S%,:()<R"5YC19@]>6&Z^\#1`SV*$Y,>M16'Q`\G[(4C
M8�I/+D]ZRCI%(1_V[J<`0I@6`K%*.&\*P?:5SPA@XZV2.U@*7>V7-[LXV^
MC-!UK=S/WZBXDCFF&*Y@?EUBIYV3TG,P[+OD:>D&&U*(1LWQ6`E)P-,)-$>:
M[NSN:+C:AO0I.9?03`1V>4I/8LI967]D!+KT=+8&/\\BO(SN3;KYKMW]Y[@"
MD=US$;E5VFW2LO;&D"]XJ<^D[UX%,T9;"]$D=X,[.X@)%XDJ%A<5O=SH)T+M
MFL+!A4==?Z,F=CN^!-N])T(;/<8A*P8Y:/<0W;\V_-.C/QP%-^V2]MEPX%8[
M&`D&;[WJ!F=+GWD4:5.,Z>_YM$;%TC7[+]JVX6(D8;+9MWI/.'%@8+WY)\EY
MVO^_DBI%6$"K(M6((@IMY\.^SUW2/X:_%Z[T`Y\L>]C6JZL5WX%/FH93*=-1
M<X3-!AYES0%3[=>@<D88XKRS`^&YH!3'GTO76OUJWG8A4IAUF):=)%P=C52&
M4GHF9OH5;@*!"5.TYTE`V*2!N!*FP:'=U(G)A#+_<H>$H$?"L32/TI!%/-B2
MZ[H5@>DE`>[*5[_I4,I'FWKQ"4Z'7K^YNXLN21N/'H8YI+/3RV\NW'_I!M!K
MW[RTC7N_F\IP>%<ET%@JG8ZT7*R<VD.B=%,&FG14#WW+=3*#,]G@6.PIS='S
MP3@56^)?41M?^J?I=DG?P3QPIKXTHEYM7%]"$E]8'KJU$I_L_L!\DP`4=;\M
MS2\2*1PT*Q5'2WM31O:/#MRR:*%M93_ER*SL?QCY"S3Q74I4HEOQY9$W=-IB
M#1TE3X.+9=R&`@5)RRF)97*L4!^-[+F13&:+B7!X#[SN&[_PE<.XI.GUV2/E
M6^'SKGPOCG.$@R#$U]C[>]#B#H<.M&:Y6%Y&P!]2ZLR&S26>P$!R.UKIYO:D
MJ++'P^!MYW!VY6ZE:O)+71U_S`CHICV!23,N+<_;$__FQ.&!'YQ"A1WC(_I\
M??:?[?.%<#)Y7/JL@1MCA8'IM*FAB.C09`Q&[NDH'=R>H40][)=.EQ\F;WP<
M2PY&9@O83J9MIS5)7;"R9(3D5OERB9TKO!MEAXUQC-KHRLG0YUWYCAY`PY[3
MJ8DS4Q=@7E1*-7C$E0?>TKL498YAD]>GR@(=M%#1`3=<^=K9;IQC>N9Q-!ND
M>LAOGIM^,1FWM_CHXF,<)$/5@NU&0LF8/,I0X.G8O;)#*6;73DEECNT3/'&8
M+4KNGN.441:FP_'789*DTW_]^"6#<KXR/3^4$NF8GYZ)&@JQI/,S_X4)JAW!
M!(7=$_3GE,42Q$X>;#[.Q$Y[Q-![9Z"L.2V9$3>LW<:I9J9OZ-PBC7;J5/1@
MGCS$H;##O"9B+C#;U*$0GLCD!:7>24>6FTG=<$VK8B-Z#&88^83Q-!G5M@8.
M:P`D:YAF%9Q#^!$U3&KV;!UV^*W'9=G=H^0M<7$(;7BH<PKS`*Y>YT#<S4Q'
M4B"23;+-F58#).EF$L5W[J)0E/'_RX)`>UBU22A42T%@GT:IG;<$/;6]2/E-
MZ/S(\8PZ#B=.`'/6F!'2%#<\G\QR8U[)8KFQ)I+I9,PX]&-Z,^D`:2(9A.FH
M]W!D"]SK(QDQTX,0,DHX\[!L+C$4_HOKPNQ:\,)='L8BV\,X[L@\C`_?]!=@
MY5@J7*J=T6=JCXQ1+++E]MY>1^?CI.O?>5CGH\/K2#NC8#^V1_;<>N)+QT3L
M..B=6@X%_*SV8;CCIM?KC_F2\RH,F&S?#G>4JL1[?K.Y@Z1:<@?]F+HC*'?<
MD;J>8MQR[57^M%NO&[%HW"2\]#`&?Y<RQ7O&&U/PZ#RQOLN8\GUZ-?Z(>TMN
ML.I`L]%/#E$'FCS.+Q<GW'I%!BCX]9TUIU:W55.GE*:O26WHN:*4B<A1'DM5
M(@,]OU>)Z'M6"G<9#/8=4EFO4<PY"'*Z@P"'M2CT(;B^]A6)[I/XIU[+')QI
MQ2R76+8"?@9L%7`RY3[^0?81_W#%HJ'S7F$NAUG#H+4N])$%.SO>TNN<-K9^
M2?99A-6'S5#9BP<R*]F.N).<JCP$?S`G1P)(^OS.X&HR8J%A!F@3K9[AI`:9
MOW_5MO#QD0^.;HS:%:]>EX:0UOO`N96;[0AM(#MU%F<0CU.#.?@X-FOF"".R
M>C>&8ZF&/[%9\!*BZ)-+UFW<3@9>$E)EI"BALNPPK'8N,*/8(J=MA;%L$D);
MZW<<DW*CZNX.SN'@Z>PY(H&LCR$]+EI>%Z->HNN.P.:DMSI2DW.?924J\;JD
M17J[8CAZI33N^SN5=191M_)WW(Q#X]3?"Q12UP)9'@L-4X/-IB,XU9(WT75'
M,L_PK^2AF#RX>Q1/S3HX/B`EQJH-F8QB4V#\T4_`2.LZ4>W!./T$L`'E"60-
M5N4(%_@GT.5G?NE1B<>-[@D7KG_1=FSE5US%S5"PM4_-PQKB/3<^X[/O30$G
M6"%*^2:8CG6D(31I)Z6?2&<UP6#&CD?P`?BWN?*;O7K\TD.?>HW=QQ*)'J?<
M@A"2Z**/A+E-+]>V3@T_]KDIJPEUD]V$8)HJ-T/2&@5'8_PV<3],UBO>`D9`
M*WO%#SE?I'6J\.]\F'MC8S3,7O$#80WB3!'UWDE>C(JK`H7AV]V2(Z?<\"=<
MC`)K3P)F>L$%LAH/CQ.!+R=D872DGJ[8?=XH^I(8)LJ404]J4\#9:@?=W09X
M.W5,)TJ_&[9T)N$)56;W5"70!\J1D7#^(Y_'UF@%HH[%+HM5'\D`F"\)LW*<
M^VH6DH9WE)PD4ZZ5^;OKDNK$NM;HF_GAEM@T=%'*=2=\:O10Q%NI?G[2J5>0
MM_QUBNN7&[0'$!$(.&53RD4Z19J"T%PV2>OI"R>-[X,>8?3%MI%[_)$9N9_.
M/.E@%5C)):DS\O$+.\Y(=_,*D]^T?)29['W7].@^@^TQ.,,Q,!+V+7F?Z<;H
MU:7YU2"WV4L(<*4A)=&3T4*4W5)#ZUX.WS3$2NAVI=A68HKM5L7&P*<OU4_?
MK.5!K<R_EWLWMN>6-VFJ8RWJ1)Y-]G:1:#.W#\-)S-^D8$[QA;5FP;2.E#[P
M-H.$E1`D3YDVK]1;$:V!A8\910_EW#??OOF&V^L@C4ABI+NY&IP,K>Y#-S'4
MXZ&_[2R<[TY4@T`FNB7:!]54=1>1?E`CK]S12YC.07%F**=-SS3NBIM[UC"A
M@'O+;,69$D"G@9P#*?)^+AK,A_/OWJ95V60_$ZV&>QQ5.\-^]!&KLWO2IQYF
MFD[T6[GO751AJD]<4`Z`D;@_-)<N+K9]H`=;?1>^83+IYXJE8SBV=`B.#%67
MH7U**#5T#@,E%4R47V*4.MK)P:W`+J3#;,@I4FS8=%@TH[=_;.NF]M#YRY8M
M;.7F_53`?L(SZHE$H%(NIX!=(.G#:0\S2D2\&,K/KUH]M`6,R4T;VLARU7CM
M:)B;=U?0'`_<!O-Q):OJN@W#GXA?5YT0'5+V*IXV%*)6E^5>N6?:0$3$X,=%
MTGG2\AO1^XJ=<+M-@9[`$W0(6[GKYQ&S?HKY-AB<R3UT&^YP"VG+>SRYD+JT
M4LY8"F-IZPW&HHOA;BU2GBJX;!RZ'H/5+61N3]ASV_)5/W&J4`*:7L$"=S//
MS8=][SIYC2G/Y<0ROCP_&":#^C=8C\0;5GMJ;,@'*78H(9B'(?2A5>MQO5Y8
M>FWN/1$GT[7?A8:R6&#OQCT6YNK7M:G<+'FK:':T?<WLR]$17@C_.!^MQ?=]
M&L>C2$<`_C<<Y;XS_^-BQ"3KW-:15+V5VWD.6$HT"FY\^'"B,<F'1]^QIG^;
M;FQE][':HE:\*;<X1,3L(H!,&]2J36SVAF]TM<"QF&5@4QZ.ZBM.B"@9C5=K
M2!\T^,R]=QQ)4S88HE<#"'IY-A"Y@!713`EI!#F)5.F>$#/G!WJM(9B33_\9
MTR-X:.IDG_Y'I2T*TD7"Z,7A+Y*M3YPT6(@HC;"#&;B;RSHBK.`X\WBL>ZO&
M7HE*QW$81<RP961&PC:.2$<)+ZPADK5C%Z_9.+IA33YJ8PXMO^:R;>V!_!R?
ML.3;U(&%S)F9[)*'0%Y4V"K#JKL1:OV!!>OX$?&B:Y8L7KYL.1BX0>QH-;Y;
MU`IW^."D[GW0D#@58S)%8D=[A[D5K^"7.8#;]=+PMBL6S?&^FV!;MG*OK!K!
MT$T((^R&I#^P#_G-OTED$JE2[BN)`/W^BH^=\]SB@-TU/G!UJE-EV(L'1*=P
MDVKA6&'+'BO6R70I>\4H410L\CS&3:XSN,F+%P]?O&3XXJ7#%Y\[?/&RX8N7
M#U]\WO#:39OR*T>WK%@DURX*3WO)(XM;Q[[F#TNBI=&YT;)H>72>=LT1Q68]
MGG4</8]HQOD`!VI`R^1TO(AAQBE,631T':Q`^CXM?)]H";[1TO`YK_DEO9+B
M\YE)ZQ<?5ZT#YPFDAE"U5-#&I7ZZJ@5!K%FS)/1!N9/V5&!/D>XHUR8=)&_Q
M"NDBB*3DO"S5H23/R`FONQ6D7H"MBA6CN`-CWLMT0HE.`1NZ>&6\!%E*\-`&
MXH-;77-7@FN]_2=CZ=0R^-9PR)JI=KG2-"F[?\*T^B7CQ_`@L/FW?SW7_]:Y
M]'D"2]5AYSC4B9T:EZC!#6*T+D@R:DZ"/`X-!'7"A8B75D.G.RV6^>6GTSX1
M.-8WC"7<<R!1LBLYP"*5YOPR(N%+=2E:J+LEI$U`)C>X0=LIH3,IG0S@=;7\
M'IE;7N>F45LTJM6?EDB<G&`GOM"COUV+U%ME;9CQ]G_2#H\))2]:!&3.5(FQ
MR@G\*AE2HCJ,7=2H-^D$["C6X3A[U;/2%F5GDJTGT7$/OW&)[3>><&1^XST_
M^0LD1U:2Z['W':-%QD%B4D2`Y_\&(UN>AW;R>NAK'5V(G6+2*HQI@Q_Z*#,1
M6+T_*Q6WZ-&.JZ?,6BR*?P3!_X>#!08)8A_'YL"PW5J4.FIB%SGQ%,BP!6L;
MRRRHC6EY)/$:4[)_5=EUZHH?*,)AK^(SN<^E^"<!=V:+R7-$4Y93MDE7@1XZ
MA?XP1(R9GF,(9%2$4&M"V+3QSLB=ULH$D"5U-W9$YGME?`GDBS$,*X,Q2*9R
M>:A!I,'8^*<2S*%_<Y\Y:@<2K:)4.FLF]YE7)@8%F'H!>->4W(+!T0H;#/M.
MN1F4[?'-8!(YK&*A](#SM>#V'X):B%F.QQ("TL:*!K1M`Z@I_RF62AW;+#3<
M&CN<S!42XZE4]V<5S`6R(-,Q-V?X^,T5J@CYXT;9C300'$2G'-C]',+,'Y>W
MK=9L%-Q&V$W%K7!3R'KW]2B<L*!4:S`8F-K*??B31>D++62-=.N<4>8H\$M(
M).>@.;S@];\>`XL%+8.^HT.JAJ#'>LQ/`[.-P4:V>),6+O("!;]91U1`W[<)
MH56'75CVQM7IHM:N';04"OKD\A8.),+4VQL'-@J8&76_RDP@:&6\;&P;4:;`
M?.F3W3J&69B,F0EP-#10T\B=1=((KF3#88$,:J8:-W62]?`G&S[N2$SK>F\"
M)=#*?OT^52O,(UVOT%S3T9T^S$@<?<1X"K:0"VI(N0%;YM<OI%F?0XX,&<H?
MD2>M[)L?IHV#SG&SUO%,\@^H]RJ,?/T>=(!]L(7'R\3MH<4O*&],4`0WMLY6
MJI?\S0E?#/(BN'PY/;OLT1?#J'CP,$BL7#J!!C-=Z<KLC\=,9:'T1'Z5V):%
M3%EWN8+`.S;RV:WL=WY%>:@58>XY*](0Z\=N`(4I(3'"6%-,//#+J&4W@:7Q
MG2])!U`K2YF$G@O4H0)&L2\PC"4$=:]W7J[BEN'/W%B"O2E)(I@R#SA`;(-B
MS":P&$%'2PULO[SV1T3L)&>\B`21>.!(]!%5Z=B]DSP+W%54+5?TA-TZ'QBV
M)PZG@:P6D!.>15)$"K"5O>TEB3J(UI#O`Q<E7(<SV<].DU"#*WLD/7!M^`D)
M1>MM+Z&QF1Y>;:JD)P?S%V'3=JW)2L7MB?4R$8UX3)`!UHE34@*^I.NXX7G4
M:5:]?^_K2""A,;K7,D8MB<YO#_]&KYUDI+=+=O>KFJ`Z=I8U2+3R?E.0FKGW
M;Q)Y'`4UZMEH]89,;,+,P66ZF]P@H>GJGDH<+@8CHQ%/M_AYEYQDM$P,.B:"
M73'_?HS^P9C&Q([EF^SM!$(;*S;0/L?<Q*Z8SH1-Q_,+APKGR>AEHD&>?YQ:
M-M-_,=(VM?4:QJ&'TB84ZAKT4IX/ZH1)#O@\Y,/YRW[>(\1I\6_4`Z5LNCG%
MB)1;Y`OM-M(+CJ-&C[H`JO)A\.C))O>W2[U;HT[-)/RFY7/D%B$5(2T,Q>\3
MX78#.:]HX8"%$LN)0P,E+KF[XZ!9K]6]`+GG@JY&WG'%83X'WG!I8W[@512X
M;&7/F$*Q+XXGUO+U&Z_&IWHLS3'B61Z(R%P))N?2X1VQTMPK7\U-RY+;]'#C
MLX__UTEO8A(V3L6'X5EDL+4I2TZSI%),[>#L\1]M=Y3VP`>=_DS!D'MU2\7*
MX5&V+K/!W"F6FP$?I5;VX9.D612N5=5SA7P[G@ZDL3CO"X^?B4T2*AX5&AU6
MNI$NL^^6E\"(=:J,2A=JS5/`)@U:N=]LY@8HZ'!*U`E_263;I%J=:`?OGH,_
M:F\!V0F/G#Y+]!M^-<$YP6&%A6\0,[0W4153,K$KC*G$4HJI1GYY<T>\6/N;
M,^>9HZP6N*]-M7XO4R4QY<3AT^=)>^9\V-?WH_[-M/<FG1K(UC=]E(0?)SZ9
M"I$*&MFA%GGN*&6NGG]X=I*82K0I#*3%91023&C1!0*#+#R#:5^T,5DGXCP+
M;Z)U_=C[MXH'GA-B((QYTKDXR,H\K42*1G#_-OC[;J_C3@?OKTH\%%OWR,S&
M=0SW.'&]@-5WED.XQ84#J/LR<^^?.MDKI!$JRA#E_![W.-.*6T.R)B6J&Y=>
MKF3G8'R)K4V3&;;2`DGQ;S$\:L%;[_086X&T-'7KA60,HBFUZ*I-6:]UOZFL
MP@Q8*_?6+8FT>VLF54NMTTEIP(1LD10&!Y!S]U]""9XJGB4X6*:S-DD%F*'8
M>AV5,&4-.:$6."7&$,1,]I%K]7,B[&M/K*,87_*XXMPIL&41*WL)B5HG3F_L
MJ-$I;%5@LU8/L_\R6_1!:O_K>)IS5>D;6W!!@HZP)]A>7MGE-`]8@S]4@L^K
M%LO4=)<SQ(XZ'$X-3B>7%TOEN/@:1"`).I\[`V)FGX4<EFT@R[[;F*1P7\"[
M)^:]@X%))D3TDQV`G]D5@EEJAV!./+(0S/W/>=(Y#-DM>,7#)9>4H$TB:%.K
M"HB)94N'4IE#P[&>J(!%A2]EZ@!`!5UY`G9R-/$4!7=E'G[M_M5K5FT'H^SA
M4KL[S4(IQDLW8!WM:H3L]^_$!BR/G^16.I(C3(R/?5CJ&ND90/[GDS:C=EV%
MPZ?O&(QX/XXO+@Q&EQ5W>3ATXIPC6.GRO[Z\1Z#MUJ>><"GK(K;J6YD'EWG,
M9=D+5M`Q<1WTWG@PRSSM,=:/V,=5Q!F5=6/GFLRC-9`PS1EX'K'S'I=P-,*6
MN/\G4M")M>-HP0MGB/(HX"NBX=!4>G[,I%:DH1DUL^AHP(CZY[>OUM0YN<X<
M2_W=Q?*Y:B>3*W_.AW%`BSZ6RB7JG!W:/XKEM.?\0UOY1&&8)<N]#N`,[,>`
M$M9XVAK<K8*;T2<!:!BC#)8'6I?)8C&7L+"OVL(7S!`/M#*)+>F#WE%1@/8+
M!LIV>2!]2&;ARBM#!N&H4J6]9S[/$`:?^<PNPN">^F@?+R`'8@))IX*<Y@"T
M<F]*5)CI84UTG(SK5N[F.^@2KD1AW$*=T@\(H`!3&_W.JDN>&&J$WWS1[@%'
MS:@XAX14)21`<7477/K@1D(EP-CPF7SC;F/7EURWW,J]8+5^V+ZN#]LK'X9)
MT`J^DGI?$BF"L<KE(;\^X>`4%;4@7J.8'!(/."U@^S=W3B1(ED6P"_?]YU@'
MYS;E>:L8PH*-2D:QL;_<ZB3."IVX0),1S".-K5$*'@:O3.R]8\%:V5-N2ZT9
M'B94"%XQ8C/5S+K&3,`4>/Z7..U'R>)3;A/&:,>D3`LXYV[4S\:;4TVM;?9-
MFYS`T+*B(ZHJCUQ>*R?(,9\!PR2;>%OCL5L2K,_.]-+`7R8\,B5S'Q^#=S(`
MFX:HP\KEQ#O53-J*J,T*1S2XXM`&E@4#*M+E9`FGYXGLL+@9F/7M*"41?"]A
M8"BVMT]C>QVFBTT4F#HS>CY7,TTV1;US7_G/+I<OH&@TJG#P#<>3F8UM,1N;
MM@H:.5CPX*?&F#X=)X@"`12)CJA(U%>C77#%!+HO(W7^/@&H#$JV7$#`A#RP
M1+#T8R>4K8LB(D*CM6RW2R/YG+1<($4X`KK^)0^$NSR'V61-"]?9;6LN6[MI
MX[:MK]RZ?>7JL2U1^S#RC6/YI)0K7>H+'[/V*:.SC9$=,&<P96>>V5Y!.-'D
M-]2(.(&FE"4,2$MHMDORE/5D/[D.#KWIZ[LE?<MC#0^;RTCKXS4KSKV`KQFY
M@B_*Y_.O,)>U475C"*`?AJ5%+*,]68X7+T3BK_`U7W]U^@GGG*,?D/KM$_P(
M,`UP'GO.U]8K8Y@=\T6$A4?H@IFQ'3O:2(!WYS;C$2TACVB-(MY_]D_I8F`L
M0MBZ1ZAA,$`,+M'IMUOHO(^<Q=KQ(\<J.D]]B!+W%^EP(E(4('/@,^%`W_L,
M]''H6BU)(*FDL3]#DHI=U[YW!SKB[DSF\\>:O@&XV>GH%-V2`[(J%H^3#R2Z
M#Q@_[XK.Y,/<A9=OYJ1/`<\ZN!X@0F*TN4T`5$H&6]GOOY"X/>MU5^%R\T^\
M2$(K9*H[$LY6QQQ?$Y3=43>A&87WXQ]5)%JL+R!FV:JSF?3%W%!L$_7D<(TW
M@.Y\E79*.I*Y]CH+\`T>8G?EMH;"9*:,?\J?P$JX@1EE0_YO8E&=CFJ"YKYR
M-M\^F[$>HTFS,VY[00VKF-^3_2&G8S2%X,`@.(IIOX#A>C`TL?.";N%[$2"[
M:$]X_JEO)WN;Q.#!<[[NW[.;N-N/42K'\[]%UGYTKYZ<\Q["DW/"69=96WJL
MU,K4'G&J'*A'03"3J7VBW<WN0F8CLV?Q8R-V)N(>9'*"\''JN%??=Z.@9Y*#
MWF&G=_1J,P"YR.J=@$3G%"D0+C+>-=SA24^2(H)V58)7%D&Q!Q9ALH@@4YM"
MI#)O#R>>>PU^,Q=)=WVS58^4YK]PIURY&R1^<0C7.*0*L$H%N^48>H59CNGK
MM?)W*5_!T^D6P5\(!B/YBQ5)XF*>I,X#1W.F:CK4N%=U>*;L*@1J6HT8&/`"
M+MN<W+C+F3K\C?LOI6JERY+/9#FD$]6N$33?+VMQ^J#`<K`&AVE*NKSR<VVO
M_*E'YI7_Y.^?9&`$U0=+(9B]`2@W)GU2I",L>@A>4`#;VJFZF)VC:TPQE91]
M4F7O1+WW,N^SECDI6D):+%E?MM+%)X$;G0G=A3"?S])8'AW[Q73L7X9?#;XT
M;KGE^856S`X$STSFB]_S.MO,#*6)#;M.;,Q/9\;#_ME\S?>1%ROSXW=0<0!"
M1?-,D@G_J+B5]@`A&9@\2D!Z(DQ3AQF=U=E?FT*582[:!POY[O=NDQRG[2+*
M9?E"52C<+?9$2DY[10_1/K,;G)WN-O>RA"RPS4A/RHD1=;)#-]1!3Z`#)N"^
MP%>^JP87RAB*16R'T(V.RIW^+1,?+"2M#&2,5`D4><WK-FX/<Z?_/6R`N,@]
M#)E%%-7DO1>M8X6.P6$DD&ST"GK6ZD04<]Q4>-32U=(GH-^J$XK:'"B2R1X@
MD'NG.K,5?YJ&\0-OG^-!5'/G'/B[MHT&(\P`Q>X;4<=+[+5?PBH0]*HZD"5=
MK*I9Q_P=_LGE^ZE:3JUMY%<I^5UL.K-EXFNB"_BH@KN"5_7C7W:*O9L_QZ[N
M#29AU8:-6!--0&.P*0>3+-^9B$S:JN95#GV@#%N'.3J1.3=F1TM=(+R7Q?0U
M_N59,!AK><?+5[Q&'N3$""(JAR>JS>%D]XC%3(Z\PQ2?DL<#+5B,6''P"=!X
MH8)W*,6E"3U\?3A\W_W<:)B];PE:6C/9^[92@`N\+$:IQ&!.1FZ]CB8E`9GU
M8".RX-BOHQV9(`M^\4ZO$7/[JF8CIN`RVW/::0>31N(TL;%ON;<6@[I5",<5
M;2E@Y:H]X?!_;AP+6KD[ANG@P@D:Q_)%Z@^Y^X:9N^`-7F(!+%=SRK:5>_,'
MDV#_FW>T#16XMI/"^&G=KV#F$IS/!?>N],7>X[PM6H])5$^YH9(\H-V_YP<O
M3P)@J;@8-4S"V^O2,0&L2X0^'%<E&2%9_PGJ]B:MTCA4Z->\JO*UFYC8O_U/
M#+IR$TS4069X#NA)`J:?W6<&W>Q&>Y;S6`T7S%P!#$D@L(AX=BZ%TLM,68S`
M**=;F7T?8#/,G4)CJZ%]'XJ2_O`Q(A4,T#AU=Z))3CG)B'XZ%_AUM9BL-ZZ%
MI$)'[!VG6],B.$3[FS":!/8*W&K@GC60:KV;<7YL004H0%)T'4W6);A!A\BJ
MX'`T*<[9%5<O8PA6I7<")DT"\SW+639C#K0Q.9/YC]]8B1ORG>I^.78:Y(5U
MZUAVEA&N\)]CI3C!OT:-(*8WC[40*>X(!5D)(JV5\%NYC]SL=,4*=WD.4_52
MB%L@L&S13N&<HY(5V'3?@COLPB>,\W`WZ2IB/7ASPY..,TV]OW5=P:JJ0P#(
ME%LTU76X3Z+^Q&$"#2=A2KL))9F+F%;XU6EZG'H2[1+87V*#PM8RJ0%L7-^J
MRZZ`$<,:IN)'].(L;6\`(>:1S__-@;(_07W;[%)=C-S]<J4&X1,A=Y`Z?&'Q
MKQ8/B+[%D]./N9PA(ABS]2Z^AWX'+4,K^^87BZ<??8+;`=BMYOJQ!09>US5*
M5)S&SG]T9(>D#9J516"_S?#,P_/&&MH.UPKW6Y!HTB34'Y<YRNG3D[Z5,C,(
MAG#K&/"E?+8=E^DR\I?91O[3CLS(_]UY?P'T\RI"/Z_Y\08DQ,"*2R/,.TLN
M;YDVJ89;W+:`RW1/=?&/]";23X09+:F#^#5N=9S4A4:&1H(ZW+%3W4AR=0WF
MFN"1M!8HZ.`"STT^6WOG.&4D,3*Y``K!8^S`PO!P[W;'=';$OK^P['5*1P2"
M/>-R`CZF08_FZ2-AW[RW].8GZ9@=M.[7_933GN_Y6%WP/&22VR\UR>]$>6@3
M+RC38[P&XK+<6L#%B;:6S;QWI?3T*"M"QTG1-J<0<D)OSH8'981`^"XMH^>1
M>A=-MD<&C>>B$V_J4[.O.951J)+&0K`5IT?D()%MAAA=23OU$_DRIBO>^K8N
MNA?R*D,8DP\Q>7_XH^GW))7'F#&AIS+=%#]/9`8B6MR"9>P)1KC.776DC$1B
M+K%;-NISHZR'IJ$4^'.$6SPQAN"SJY)Z`JW`>1[-,O74FBB6'KP*4REE/^#2
M%0ZJ25<XJN-WP<8\&Q1Z5((?!\-<#BYE0ZPWX%N.[(-KVEH_J0WZ<"JU=E%.
M)):&[GH\26_N^FU[TH.Q4;#%"EV\?Y:VASE6L:O)%RF(Q8H(M,YV8F/@*H<K
M8?D\56?:.$DJKDIN65LF[::]3B4,8-<W7"N.16K3]'1G&Y<>FQ`<).`M++/I
M611`DNR2TSID0FJK>U54(8'4&78`O*T*-YO)/\Q>\NO`-\+(=`G`F=TK-`"_
M_%NV"CB[Q=T:>^37-=5'7C0?*3Y-@@F%)3]YELBIJ?\G;&GPG%_\HFU))0*9
M()B#4!1M[&`M`ST78]L8O?8YA>2>4,"Y(M]F;H,JA9=:17BI-3]>N_?VNC1'
M3%3&K2F5D?OBY;K_<E_X/9V,B0E4&H)<%SM(VQY:$V&W6ZAV$)^#%_+5;VP3
M8A.I;*;4*>$KX:H585_YD^1P_/>5:@1I:@OFH>R5+)L+\6P)A[48#?1J/;`3
M`7L`W&C2`,VUPV(K>_WI'0J.!D(13;O"EK7)QU*99)7[(&5ON4\.29U3J/0\
M#^.=5E*Z8=?>NPA!S-M1,%@A5.KG?;VV%C^NJKXWM>+=QP:,)%ZTQE#+[8BA
M2YD@M-<;DMD.4?%)Q]=IQ)_!#'+R+>Q?1T\++HGL0:?;R8<[DZA-^#WL7ZM5
M9!M7?B:[M830/I_W=T![&0DS(JSD8(P=.^SXAQ+:*#'3/&2W?H%H'JCNB$)Y
MY-_2OH%C,N%19;`D4XEQ-TYT#7:&<`^B22L%0[G;GH49J685%06ML]6O7K,D
M>JC9["`=Y(+H]7&6[(8N!89"3`PFJUR'/?S<4QCTRQ&^CFPVK%8!&1I!!'S]
MJ9UF^4QNR[U>-2F#/(Y,ZMEM:S<0DPD1EDBFW^#GNZ(X,]D/?FAW)*X7A09Z
MN&T-7Z5%+)!,FE_*M"52DEO9<P+-J\:SF]?'Q*@2>]4$!TC)+&G8S$U.&S2Q
M"7NQ;>J-55N9:T^AA':U""[3'=>"K8.%*F05=?C>D5A:3CGMDU'S)H_Q1&D?
MF$4TR4C8$[I`AC^"EM6I>D$%-<!-:P.P@\*QN:S+<?@:V#M%,/Y>\'X#_L^&
M(^VTI<6!2#Y]DG3#36/96E>_1_U+]DU9Q+%+26E'(8V.R>(XC@3+Z_^/]H0&
M#?[@S"K9.(J,5T4`8^(YHANDSV%B:KEN17O=\`M4A9%H-V%#L#ZPZ)O<HWSP
M8=0<33/2!S`P-Y6FS'WNN120MF12X$[4W0FFX<!M(;K#U*-QZP::%0S?Q-3,
MG00?'ASPZ$_[!NEIF(P.GFD3)>?$12OWF7CW7G40]W&))7FDII&++=6082KL
M.^5A./NXUSBP0Q@PE?SINO`R7YXHD503I!]>8<K!MNTSQ.>+5#V9VG^00`M.
M)\IG,+"K(`3.>&"TS'TH>6'&RQZ!4(7S`B>;[L&(.)I==C@I\^L+*'171ZMA
M]SARQN+OL#[:%P(7[H]>Y-K[`A6)-M7$;C88/0OF-?:%QL$\S)QO_EQ2Z/+K
M%[3)8Z8&COILVJH$0B3*@EG3F[96CMI"+,J+0MW!2H[^N:1MU2:"DKD2%(:[
MJ#T@E!KC,=:N8L._'C[Y<MLG/^F(7/*CLL]^\GUR4N"+28%O(+ROJZ5B%H5[
MHL)O[:Q/3FOQ28>:E$@$CSC+8=K8^^$6=0V_DD2?J"DC-9(P1%:=C`9/3(-7
M,`(5RP_%FA<>E?NVK<]!A.=.V2-8-*0;R(WM2".QO09>X2'SP0D%3-Y@/U6D
MZ#DT#%!$(K7_3CI<DC^6-/`2KYA:25`_@#PWT+"D$+M_55L*5?S4G':P[\->
MK)E@$5OI]!ZDU'K:1#RI%;]%#0RLR;/F:\Y9CWC*4T;22F2#_^XI]-[,!(#N
MF0UH]7'^>K^]P2`DO'R$V13^"0F.%!S&TA:U!I`FWF<`CFB))H%\8)HT0MIE
MIRZ1;4YS@U84KH1T)DXUJ!S<S^IR\+^GZA'8C6)DMV%"IXP>KSO_R)DA[)Z<
M=",VKB2SOH*O*8\U?6L0*1%FWQUV+A6(&W`#=PYC&.<9UXY66]EK?]'A4)+&
M)T!+PO[G]C+^Z3SB=YNEDUV#!V`F^X^/X6M&;$X%3?R7;5!Q2)SNB">H;(#,
M"^^S:"1SB?LD09:,J1,[1=8T:(1-4`U[XD+Q(<&L$$(?I`$:1T#3-496*!2U
MBC;)LR!"EHV&>S'SNGD>![2*7F!>@=!&$X36NGU-@[;."&BG9R=`;'7;R@YZ
M'^FJS4YZ&AJE1C$[,=T834Z=DDTO(JRN1(6U(LQM>0\A$/XTC,_36#!2EH-E
MREQ_:'PFX:2B6T/L4YHVKM]ES!D71F.N4?K-\F2HZ8059NZ$ASKNP`$J2]"J
M<R3<-"70":0:B>2:S*@U_V2/11&\08&Z31$@'9FUR+^TRJ\Y0I2&AM'8;HU>
MFK>_MN00+4"=3"6H8>I8N+N`'-J459;]^5+FOMS)<TSVLE>`272"H%FI):T$
M.SMYY)YO.G13B9-VD&,$"!-D\KD=,C7<=-:5W;.5??HWM6UYF+OBUV-"+P!J
M'KMDPD$'>]&8HUR65BQ2%FU\'+WT)&5@.6H4;\*GRD.5=>W?7^*`&?B^IZ'Q
M5BD5IJ+VKB`?S4Y-7XW_YL#>I'9GP20#!Z%TU,NFKQZ,X:+4VS2D:-BK4#-*
MLU*MW+ONMYI3IOHD&GG<K'IH%Y:G5;=Q]&?!^>O5]4-T(..2D3'`QD/F?KH+
M%2::\.J_^%CM=LKQ7D7Y!*5O)1G<S"()>M,,E\+X@7_?-$TCB4&6Z!V0H(]X
MGW`+3\;IF5&MJ^=%)#$K6(H<,-4;A3.3I$P9P?H=(:@E%(+JI+.?*WVA[L29
M/[9T.+KP3*ECM02UN_I951ERY.F@)&)'SHJ<68)@F/Z7K=Q)MS"*,56/#NLP
M^KMQ`F:R`<[;@0&0*49.1_3T<:1B.UN5J@<`*X1)9I4RTJ6->/N)S-+4HP56
M23T64\(G[=7D,'Z>W-KI@*T]0\J8A>?&/!B.Q^LVXX<H#P05S$G0CE)R/3K.
MB5#O7S3`V0N&"O"%0\:KMIM>GC3/6"`H-/L7#Z#<P8!S@^!+R#F%X7QX(D)=
M"=.4R&-^$X,N/4["SXG99]H%]NRWV2"B$&*?H$15"G"Q>D^XZ`Q_BS2TRMTQ
M;.B=;!HKSO&`\5X3.>9-11.>T&+68E]7(6"^"<N'M9@AK-4W"P16<_:"HTCX
MI8EGP&)9^<$[)P^^\*ZKPD_:8->&=_[]6";[TMM&-]X]$LZ[_@]HZU5<A^DZ
M!6]%_%#P?T0/.%W!D%.I44L*;,/LB__89K&3NVJ>1F&QY&<2I6%"Q*"-!S2/
M:YL/!`#NB%:-=/MGY]G^V=./S#\[Z2-/;KDB6NXP(?FB4VVX>3#G$8PSY&!E
M\"Z+^Q<O"2:#)J.5[$MN-G_'_A5.(=_<V74![IRU2$=*N""BVK_0'E&5#[GD
M;H.M,*KIMNJ@B>A$\B2DKXF(/R!UY-?+1<PE2(-M?.!%Q#"`>557JJ%T.X_,
ME4?)?5=@0]_-MRO,_<9OHN4K&)K%JX@X2L1YHR[L&44"8N#F(IC,K)FN*QJ[
M)X8:Q>`5Y-U;;NBN2I"O3XY7"SIM,F7!,-R1;R`(K-V;"4KZM=>$D(*Q#".X
M"^^<[#H4LS#2(<8I^.6R:PB!GF#O<^G61X^F?51!6[G9<"837!MRX6,#Q%ZO
M<*3-<W,/_Z8]C@V[,0V$S7C!,JW$21_>.;^]Z%OZ=!@W&#]IR"\-;7,O:\^=
M5-N^W=@I"Z/]J_=^YGQL$UHD0%?=P#SG?O`N;S="$/&&(;UZ&(9TRT,+>\]%
M0DR;NZ!\B"8JX;ROG]D>"?M^.'7X+]9&+>#;S7_OUTA\YT[XYQ3I@!0I!`EC
M+1=2,*VNZ?Y'>9QT[SZQIGOPI"7\QYC7,;P<Y(4H[#DUA;.3C49M9'AX]^[=
M>2_P\X7)80S-X?_+4\?BN2A)Q\]3J='*CJ]`=@J_%.8&+NOJNC=S1EOC\/#$
M:Z_O-7<2^\0V>,.F&1Y(]_AJT@S'E=W#S%:'GV'I5UC!X2O#5?``FG@?.Z.F
M-:ODP"B_&+4G'>+=I\P(9L)=8H1:83&`(:-ZF1P],=P4(*)D.0(H0IJ^IMU;
M?JL+1[CA@9&>O67;%H?P35<KH4/WF=].]L8ZA/-)>Q$%%$:KP#8N>,AYY<"B
M(5GR%?LW4BZ'J[_!>YG4@>&MC$U$S$!4/4&$G5[=,(G5O0GDBN'*"C(`>+KJ
M"9)YW*G#_SF&AQY;.84##[UAO5,O1RO=>GTZ?-%#;[[4(T/5BU;6,6D?GOOX
M[Z59]BJXS@O*24N2;9-^Q2&S9DV`51WYA]XR6H9/>*G[E+H['2X__:J7OB;\
MP^./^_6):'U5J6S#_'D/;(:#`?IE@U-83P2F9L@MGH&Q;?#!?PY'[OR>F?8(
MYCQN7!V^8.-"%&4QB+)H*_P7B[+PKQ__[:K)NL>7;JUYL.))7Z0UX#T0G@B,
M2)2%M"#2FYRM\FAWY(0G+;IK\R1HL%K,%T339;\>+K[M[[>7Z][.^%(/;@]'
M;MBX.7*:Y?A2,EW">7O.NZKAF$?Q0N)*F+6$OPE1EW$R#K52JXF_SJ.3,1K4
MB`0H?.'SWK#1+0?(^N^Z]"7AHC<_\R*$RL+A70E^&RSG"T^?7(G%6*O@(XI)
M!YO53H6V[?;MJYH395B;_JMNHJ5:W:QRA!4>L/"SO]^`,2;'I>3;VAG<LO6)
M)CPR?,[COUL#$Q"MC<$;A3LP*S!IAE^)(:\ZO>XZF)>R&PX\YW>\"Z)UX+A1
M@5?XPE\N7N?"7G#A3+C@/(*A7G3#TZ:^Q_LH`LNC8:W82D3>^&4:]2*_7@T'
M[QM>-0E[$)0H;-DJ?L4Y?[^:H]I%^!7Z';7PA84WR'Y=[V);<VKJ(D/2>OC5
MG?`!%&3"C;#>JX2+O[5^"WUYO1BO!T$538:#W]JXQ1_WJO!S?>>D4PG[3R^-
MEMVI>+V_,]E4C`>9E&_?@&WR@O#,6]ZPTA^/8/_"9@Q';GGSQ6Z5(=0;FO!*
M53@I9^]9N`F+>3?'8!<$(!1V6DNUSZS]EDG7*89+3K]J@U/?&6WUJN#QA",;
M%XU6BW5W-PL5C'/!D^"LAJ>M>\9JOSDA(J19-&.NFG3=H9<A`9A#E;N71VZS
M.@%_[C*USU=3^]%Y1SWWDJ->_\[/G;X"[>GL3S-_^^[W''77@?>#&_'TGDY%
MS[*Z@P/_&BP+YRV`7RS07YYW\`77#3UZ\KQCX1?XGZ,+E4)06+3PX/,?O=Z_
MP/QZ0=F?\(,R_/YY]/OCY/?S\??PV^=6GO?I+?../;B$?XLCPV^?\[K[MBRC
M:X\SOUU\\(S4R#K"LWD$_:V,<#J-<$*IE!KAM.__[$53]K6-!EQ[JO_1:^\Q
MGYPK5.KG'SSEL7EGCZ2N].#*$R_[X"5/,>_5A\3/BP^>L/H;_Z<Q[VGK_IG^
M0[]<?O#X,\\:W)=ZJVFX_]BGW#1^@?W;"HYZ]/I'KIPVOZ4!%AZ<_T!TTY9Y
;1^/,RDLM__V\HUYX5^;[\#__%W\UY0R4+0$`
`
end
SHAR_EOF
echo 'gunzipping file tds.dvi' &&
gzip -d < _shargzi.tmp > 'tds.dvi' && rm -f _shargzi.tmp &&
$shar_touch -am 1122114995 'tds.dvi' &&
chmod 0666 'tds.dvi' ||
echo 'restore of tds.dvi failed'
shar_count="`wc -c < 'tds.dvi'`"
test 77204 -eq "$shar_count" ||
echo "tds.dvi: original size 77204, current size $shar_count"
fi
exit 0
================================================================================
From owner-twg-tds@shsu.edu Wed, 22 Nov 1995 11:38:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 22 Nov 95 18:25:42 WET
From: GOOSSENS@CERNVM.CERN.CH
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: nov 15 tds...
To: TWG-TDS@SHSU.edu
On Wed, 22 Nov 1995 10:25:24 -0500 K. Berry said:
> i do think Karl's para *is* giving the wrong message, i must say.
>
>barbara, Michel, Sebastian -- could you or whoever will work on this for
>TUGboat remove that text for publication, then? I did not want to
>include anything contentious. I'd rather say nothing.
We (the TUGboat) team will take _nothing_ until we get the green light
from you. And in any case, final copy will not go out for a few days, so
other small errors can still be corrected even after you give us version
0.999, Greetings, Michel
================================================================================
From owner-twg-tds@shsu.edu Thu, 23 Nov 1995 08:08:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 23 Nov 1995 09:08:39 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511231408.AA27983@terminus.cs.umb.edu>
To: goossens@afsmail.cern.ch
CC: twg-tds@shsu.edu
Subject: Re: latest tds
I see, however, that the dates of the files [in pub] are Nov 15.
Please get 0.999 from ftp.cs.umb.edu:/private/tex, rather than /pub/tex.
I withdrew the thing from pub/ because of the problems people found.
As far as I know the 0.999 in /private is what should be printed in
TUGboat. If you find any typos or whatever, please let me know.
Thanks.
================================================================================
From owner-twg-tds@shsu.edu Tue, 28 Nov 1995 11:58:58 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 28 Nov 1995 09:58:48 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511281758.JAA01102@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: version 0.999 released
Did anyone catch the typo four lines up on page 7?
texmf/fonts/source/public/pandora/pnr10.tfm should be mf
--
%=======================================================================%
| 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, 28 Nov 1995 11:58:59 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 28 Nov 1995 09:58:48 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511281758.JAA01102@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: version 0.999 released
Did anyone catch the typo four lines up on page 7?
texmf/fonts/source/public/pandora/pnr10.tfm should be mf
--
%=======================================================================%
| 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, 30 Nov 1995 00:23:47 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <199511300623.BAA06112@aleph.bu.edu>
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@shsu.edu
Subject: A concern regarding texmf/doc/{html,info}
Date: Thu, 30 Nov 1995 01:23:40 -0500
From: Matthew Swift <swift@bu.edu>
Hello folks. The TDS draft shows that great care went into it, and I
would guess that you have already recognized the problem with the
<category>-directories texmf/doc/html and texmf/doc/info, namely that
these categories are reserved for file formats and not file content,
like the others. Suppose I want documentation on Metafont. I will
have to look in three places: doc/metafont, doc/html, doc/info.
Now, I'm guessing there is a temptation to treat the html and info
formats specially because it makes things easier for the programs
which read those formats. But does it?
Good html should use relative links, or full URLs for references on
other machines. So why couldn't a group of html files that comprise a
tutorial on metafont go into doc/metafont? If the html cluster covers
more than one category, shouldn't it go in doc/generic?
In the case of info files, GNU Emacs 19.29 anyway supports the merging
of multiple "dir" files into the (virtual) topmost node, so that a
single "dir" file living somewhere in the texmf/doc tree and
containing relative links would dispense with the need for the
doc/info category. Using texmf/doc/dir would allow shorter relative
filenames than using texmf/doc/info/dir (i.e.,
"../metafont/metafont-docs.info" is longer than
"metafont/metafont-docs.info").
Are info files now readable and with readers other than Emacs and the
GNU standalone info reader? If so, this would confound the solution
I've proposed, of course.
Regards,
Matt
================================================================================
From owner-twg-tds@shsu.edu Thu, 30 Nov 1995 04:57:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 30 Nov 1995 11:08:49 +0100
Message-ID: <9511301008.AA04421@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: swift@bu.edu
Subject: Re: A concern regarding texmf/doc/{html,info}
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
Matthew Swift:
> Hello folks. The TDS draft shows that great care went into it,
[...]
> Now, I'm guessing there is a temptation to treat the html and info
> formats specially because it makes things easier for the programs
> which read those formats. But does it?
I think it was me who proposed the html/ directory back in March this
year. What I had in mind was that you can convert Texinfo sources
into HTML just as well as into Info or DVI format. The only difference
is that for a medium-sized manual the same source typically results
in one and only one DVI file, one or a few Info files, or a whole lot
of HTML files (when using -split_node), making it necessary to employ
a separate subdirectory for every manual to avoid getting lost among
hundreds of files.
This was the idea when I proposed a separate top-level html/ directory
for those manuals by anlogy with info/, which used to be a top-level
directory at that time. As a result of the following discussion which
I can't remember in detail, it was decided to move the info/ and html/
directories below texmf/doc/. Personally, I didn't really like this
decision, but I accepted it.
In the most recent draft this decision was relaxed somewhat so that
implementors may choose to install the contents of the texmf/doc/info/
directory outside the texmf/ tree, e.g. in the usual /usr/local/info.
Unfortunately, since WWW is so new, there don't seem to be established
standards for a corresponding organization of HTML files yet.
At my site, we have administrative accounts "tex" and "gnu", which
are organized very much alike. Info files go into /opt/{tex,gnu}/info
and formatted manuals in DVI or PS format into /opt/{tex,gnu}/doc,
where /opt/tex/doc is just a symbolic link to /opt/tex/texmf/doc.
For HTML documentation we have resorted to using the home directories
/home/{tex,gnu}/public_html/info, with links in /opt/{tex,gnu}/html
for ease of installation. Another link in /home/tex/public_html/doc
points to /opt/tex/texmf/doc/ providing access to all kinds of
documentation no matter what format.
Keeping an index.html file in the texmf/doc/ directory allows you
to organize the documentation without any constraints imposed by
the acutal directory structure. With relative hyperlinks it doesn't
matter whether HTML files are kept in a separate subtree from the
other files. A user can find all the find throgh the WWW front-end
and doesn't have to care about where they come from. Another user
looking at the actual directory tree, won't be irritated by dozens
or hundreds of Info or HTML files he can't read directly.
Back in March, Phil Taylor argued that he didn't see the conceptual
difference between invoking a DVI or PostScript viewer or a HTML
browser or Info reader on a certain. However, I think the main
difference is that HTML and Info provide their own navigational
front ends (using index.html or dir files) whereas for the other
formats the directory structure _is_ the only navigational aid.
This is why we can lump all HTML or Info files into one directory
whereas we have to care more about a well-organized hierarchical
structure for other files, in order to make it easy to find the
relevant information.
So much for my personal opinion on organizing HTML documentation.
Other members of the TDS group might disagree.
Cheers,
Ulrik Vieth.
P.S. In case you're interested, you might want to try this:
http://www.thphy.uni-duesseldorf.de/~{tex,gnu}/
Unfortunately, the index.html for texmf/doc/ is very rudimentary.
I once started to write some INDEX.html files to navigate through
the hole texmf/ tree, not just texmf/doc/, but I didn't get very
far with that. Apart from that, what I've written needs updating
and/or rewriting by now, so I might want to start over completely.
P.P.S. Some other TeX information which is not documentation
for packages in the texmf tree can also be found below:
http://www.thphy.uni-duesseldorf.de/~vieth/subjects/tex/
================================================================================
From owner-twg-tds@shsu.edu Thu, 30 Nov 1995 12:27:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 30 Nov 1995 13:27:32 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199511301827.AA10281@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: version 0.999 released
Did anyone catch the typo four lines up on page 7?
No, no one did. I've just fixed it, and updated the files on
ftp.cs.umb.edu:/private/tds. Version remains at 0.999.
As far as I know, this is the text of what will be printed in TUGboat.
Take it away, Michel.
================================================================================
From owner-twg-tds@shsu.edu Thu, 30 Nov 1995 17:55:13 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <199511301752.MAA00921@aleph.bu.edu>
Reply-To: TWG-TDS@SHSU.edu
To: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
CC: TWG-TDS@SHSU.edu
Subject: Re: A concern regarding texmf/doc/{html,info}
Date: Thu, 30 Nov 1995 12:52:54 -0500
From: Matthew Swift <swift@bu.edu>
Ulrik, thanks for your careful reply.
>>>>> "Ulrik" == Ulrik Vieth <vieth@thphy.uni-duesseldorf.de> writes:
> Another user looking at the actual directory tree, won't be
> irritated by dozens or hundreds of Info or HTML files he can't
> read directly.
Why do they need to be "read" as opposed to downloaded? In this case,
there's no way to predict what file formats are interesting, so they
should all be provided.
Why do they need to be read "directly"? A significant and increasing
fraction of all documentation is not plain ASCII text. Many people
now, and most people in the near future, will be using intelligent
browsers to browse the texmf/doc tree. When the browser can't handle
the file format, it will launch another browser, based on filename or
magic string in the file.
The fact that texinfo --> HTML conversion generates a large number of
HTML files is unfortunate, but I don't think the TDS should bend to
it, since there better ways around the problem, I think. Intelligent
browsers can decide to hide ("filter") or ignore certain files.
Alternatively, would subdirectories be acceptable here, such that the
file "texmf/doc/metafont/metafont-tutorial.html" would be the top node
for files living in the directory
"texmf/doc/metafont/metafont-tutorial". You've already got this level
of subdir in the TDS, e.g., texmf/doc/latex/base. The same could be
possibly be done for Info top nodes, assuming the change is
cofigurable in the Info browser. This would keep the
texmf/doc/<category> top level as terse as possible.
A number of intelligent browsers exist now. For example, I use GNU
Emacs dired-mode. Or sometimes Netscape. The one launches the other
when needed. For dired, I've hacked `dired-guess-shell-alist-user';
in Netscape, you configure e.g., metamail on Unix; NeXTStep has an
intelligent "open" command and a file manager/browser which recognizes
extensions; Mac browsers distinguish file types with the file's
resource fork; Windows 3.11 lets you associate extensions with apps;
etc. And there is one browswer, more or less intelligent, available
on all platforms to run the right viewer on a given file -- the user
himself.
> Back in March, Phil Taylor argued that he didn't see the
> conceptual difference between invoking a DVI or PostScript
> viewer or a HTML browser or Info reader on a certain.
> However, I think the main difference is that HTML and Info
> provide their own navigational front ends (using index.html
> or dir files) whereas for the other formats the directory
> structure _is_ the only navigational aid. This is why we can
> lump all HTML or Info files into one directory whereas we
> have to care more about a well-organized hierarchical
> structure for other files, in order to make it easy to find
> the relevant information.
I agree with Phil Taylor. Yes, you CAN lump all HTML and Info files
together, but there seems to be no advantage to doing so, since we
have established that properly maintained "dir" and "index.html" files
permit Info and HTML browsers to use the relevant files wherever they
are. Given that it doesn't matter to users of those browsers where
the files are, I suggest the files be organized by categories
according to content, for the sakes of all other browsers, which are
thereby enabled to include ALL documentation in their scope. A tool
that only gives me access to a subset of what's available (e.g., an
Info reader) is not a tool for that critical and difficult first stage
of research that I think the TDS is in a position to facilitate,
namely, the stage of finding out what material is available to help
solve your problem.
Ulrik> I once started to write some INDEX.html files
Ulrik> to navigate through the whole texmf/ tree, not just
Ulrik> texmf/doc/, but I didn't get very far with that.
Your efforts were trying to achieve the same goal for HTML-only
browsing that I am suggesting would be achieved for a wide variety of
browsing schemes by sorting ALL documentation by topic and none by
file format, namely, the goal of having ALL documentation available
via a single user interface.
Writing an HTML guide to the whole tree would be wonderful and useful
not only because it would facilitate browsing of non-documentation,
but also because it can confer MORE context and structure on the
documentation than can the TDS. But the TDS can and should, I think,
provide as much context and structure as possible on the
documentation, independent of file format, so that the greatest aid is
given to the greatest number of interfaces.
Outside the doc/ tree in texmf/, file format is, for the most part,
integral with describing the file's purpose and content. Among
documentation files, on the other hand, file format is largely
irrelevant to the user and almost entirely irrelevant on the practical
level of enabling good user interfaces.
From owner-twg-tds@shsu.edu Fri, 01 Dec 1995 12:55:09 CDT
Sender: owner-twg-tds@SHSU.edu
To: "K. Berry" <kb@cs.umb.edu>
CC: twg-tds@shsu.edu
Subject: tex directory structure draft version 0.104 available
Date: Fri, 01 Dec 1995 10:52:28 -0800
Message-ID: <5355.817843948@castor>
From: Steve Kelem <steve.kelem@xilinx.com>
Reply-To: TWG-TDS@SHSU.edu
I tried un-gzipping the file you included in the TeXhax Digest V95 #16.
I got the message:
/bin/sh foo.gz.sh
x - extracting tds.dvi (gzipped)
gunzipping file tds.dvi
gzip: stdin: unexpected end of file
restore of tds.dvi failed
tds.dvi: original size 77596, current size 65536
I then tried picking it apart by hand.
I created the uuencoded file (the one beginning with the line:
begin 600 _shargzi.tmp
It uudecoded ok, creating _shargzi.tmp.
However when I run the gzip manually,
gzip -d < _shargzi.tmp > 'tds.dvi'
I get the message:
gzip: stdin: unexpected end of file
So, I think the file got messed up before it was uuencoded.
/7\'7 Steve Kelem (408)879-5347 Steve.Kelem@xilinx.com
\\ ` Xilinx FAX: (408)559-7114
// 2100 Logic Drive
\\/.\ San Jose, California 95124
================================================================================
From owner-twg-tds@shsu.edu Mon, 04 Dec 1995 05:23:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 4 Dec 1995 06:23:25 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199512041123.AA12403@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu, swift@bu.edu
Subject: Re: A concern regarding texmf/doc/{html,info}
I agree with Matthew that the html/ and info/ directories are unlike the
rest, but I think they might still serve a useful purpose. A
dir/index.html file in every doc directory would be just as painful,
wouldn't it? You'd have to specify all those directories in the
info-path ...
System administrators will put such generated files wherever they want,
anyway. We cannot specify an absolute-for-all-sites location.
There has never been a requirement that html/info files go in their
respective directories; it's just that we reserved those names for those
purposes, since some people seemed to want to organize things that
way. The current draft says in about fifty places that directories can
be omitted if a site desires. I suppose we could make it 51.
(However, I would not want to make such a small editorial change for the
TUGboat printing, but rather save it for 1.0.)
If the draft said `put your html and info files in the package doc
directory', along with the Texinfo source or whatever, I think people
would complain.
Summary: If you like html/ and info/, use them. If you don't like them,
don't use them.
From owner-twg-tds@shsu.edu Tue, 02 Jan 1996 15:31:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 1 Jan 1996 14:13:45 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199601011913.AA28365@terminus.cs.umb.edu>
To: knappen@vkpmzd.kph.uni-mainz.de
CC: twg-tds@shsu.edu
Subject: TDS location of DC
I finally got around to getting the DC 1.2 release, and I found in 00inst.txt:
4) Copy the tfm files to a place, where TeX and the dvi-drivers find them
This place is traditionally given by the environment variable TEXFONTS
(or something similar, like TEX_FONTS). Within the proposed TeX Directory
Structure (TDS), the proper place is
TEXMF/fonts/tfm/dcfonts/
I believe this should be TEXMF/fonts/tfm/knappen/dc. Confirm or deny?
I'm sure there should be a supplier level.
Whether or not `dc' or `dcfonts' is used is up to you, I guess.
`fonts' seems redundant to me, given the directory it's in.
Similarly for the PK and MF paths immediately following.
================================================================================
From owner-twg-tds@shsu.edu Sun, 07 Jan 1996 13:22:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 7 Jan 1996 14:21:51 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199601071921.AA11695@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: tds copyright
I've been working on the documentation for the next web2c release, and I
wanted to extract some stuff from the tds. But, technically speaking,
the copyright prohibits this:
Permission to use, copy, and distribute this document for any purpose
\emphasis{without modification} ...
I'm modifying it (in particular, I'm deleting most of it :-).
Does anyone object to permitting this? I sure hope not. If not, I will
try to work up a notice that is a little more liberal for discussion.
================================================================================
From owner-twg-tds@shsu.edu Mon, 08 Jan 1996 03:48:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 8 Jan 1996 09:47:50 GMT
Message-ID: <199601080947.JAA25817@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: tds copyright
References: <199601071921.AA11695@terminus.cs.umb.edu>
K. Berry writes:
> I've been working on the documentation for the next web2c release, and I
> wanted to extract some stuff from the tds. But, technically speaking,
> the copyright prohibits this:
>
> Permission to use, copy, and distribute this document for any purpose
> \emphasis{without modification} ...
>
i think one needs to modify (mentally at least) this to mean "you can
rake out bits of this for `official' projects which the owners (TUG)
support and endorse"; realistically, web2c is a core system for very many
of us, from which TDS cannot be divorced
s
================================================================================
From owner-twg-tds@shsu.edu Mon, 08 Jan 1996 11:04:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 8 Jan 1996 12:04:18 -0500
Message-ID: <199601081704.AA24253@terminus.cs.umb.edu>
From: kb@terminus.cs.umb.edu
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: tds copyright
i think one needs to modify (mentally at least) this to mean "you can
rake out bits of this for `official' projects which the owners (TUG)
support and endorse"; ...
Hmm. I don't think the (lack of) worth/TUG endorsement of the project is
relevant. Instead, I think we should allow any
extraction/quotes/modifications -- as long as it's not represented as
the original, of course.
Something like this:
Permission is granted to make and distribute verbatim copies of
this document provided the copyright notice and this permission notice
are preserved on all copies.
Permission is granted to copy and distribute modified versions of this
document under the conditions for verbatim copying, provided such
modifications are clearly marked and the modified version is not
represented as the original.
Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that this permission notice may be stated in a translation approved
by the TeX Users Group.
================================================================================
From owner-twg-tds@shsu.edu Mon, 08 Jan 1996 11:16:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 8 Jan 1996 17:15:42 GMT
Message-ID: <199601081715.RAA03840@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: tds copyright
References: <199601081704.AA24253@terminus.cs.umb.edu>
> Permission is granted to copy and distribute modified versions of this
> document under the conditions for verbatim copying, provided such
> modifications are clearly marked and the modified version is not
> represented as the original.
>
i dont this quite covers the spirit of what you propose, which is to
excerpt chunks. how about also:
Permission is granted to use portions of this document
in documentation for TeX-related software, provided
a clear statement is included that this represents part of the TDS,
and provided a reference to where to obtain the full text is included
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 08 Jan 1996 11:18:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 8 Jan 96 17:18:45 GMT
Message-ID: <9601081718.AA27273@r8h.cs.man.ac.uk>
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: tds copyright
Karl
> Permission is granted to copy and distribute modified versions of this
> document under the conditions for verbatim copying, provided such
> modifications are clearly marked and the modified version is not
> represented as the original.
The intention here is presumably to allow yourself to do what you want
to do, namely to paraphrase the tds document in the web2c
documentation. Unfortunately this would allow people to distribute
documents that propose different structures rather than just modified
descriptions of the same structure.
While we can not of course prevent people from proposing alternative
structures, I dont think we should be seen to be encouraging
it. (Multiple standards is worse than no standard at all:-)
Why not just leave the default conditions as they are but (as tds
author) give yourself permission (as web2c author) to use the document
as you see fit, irrespective of the general distribution conditions.
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 08 Jan 1996 14:10:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 8 Jan 1996 15:10:32 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199601082010.AA25901@terminus.cs.umb.edu>
To: TWG-TDS@shsu.edu
Subject: Re: tds copyright
[follow-up to both...]
i dont this quite covers the spirit of what you propose, which is to
excerpt chunks. how about also:
But it's not just taking chunks as-is that we need to allow. I think
people should be able to take the text *and change it*. For example, I
want to delete some parts of the summary section, add some others, and
make other changes to make it work best in the context of my manual.
Permission is granted to use portions of this document
in documentation for TeX-related software, provided
a clear statement is included that this represents part of the TDS,
and provided a reference to where to obtain the full text is included
Requiring a reference to the original seems ok, I guess.
But I still want to allow modifications.
The intention here is presumably to allow yourself to do what you want
to do, namely to paraphrase the tds document in the web2c
documentation.
Well, that's the occasion for the discussion, but it's not just me.
Unfortunately this would allow people to distribute
documents that propose different structures rather than just modified
descriptions of the same structure.
I don't see that as a problem. (Presuming the modified version is not
represented as being the TDS.)
While we can not of course prevent people from proposing alternative
structures, I dont think we should be seen to be encouraging
it. (Multiple standards is worse than no standard at all:-)
I don't think that allowing people freedom to change the TDS document is
encouraging multiple standards.
The primary work in creating a standard document is not writing down the
text. If someone else wants to come up with an alternative TDS and
promulgate, more power to them.
Why not just leave the default conditions as they are but (as tds
author) give yourself permission (as web2c author) to use the document
as you see fit, irrespective of the general distribution conditions.
Because I don't think I, either as TDS or Web2c author, should be a
special case. What if Eberhard (for example) wanted to excerpt/modify
the TDS document? What if J. Smith writing a book on TeX wanted to do
so? I think all of these are perfectly reasonable activities that we
should allow.
As long as the modified text isn't represented as being the TDS, I don't
see a problem.
================================================================================
From owner-twg-tds@shsu.edu Mon, 15 Jan 1996 03:25:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 15 Jan 1996 10:23:23 +0100
Message-ID: <9601150923.AA02045@macbeth.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Texinfo/Info/HTML version of 0.999
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Hi folks,
I've recently discovered that I still had some of Norm's 0.98-based
Info- and HTML-files of the TDS draft lying around since there was
no suitable replacement. This weekend, I therefore tried my luck
at hand-converting the 0.999 LaTeX file to Texinfo, which basically
involved nothing more than a lot of query-replace-regexp and adding
@nodes and @menus.
I belive that the result is reasonably good, taking into account that
this was my first encounter with Texinfo, but I might well have
overlooked some subtlety that could have been done better with more
Texinfo experience. So if any Texinfo guru wants to look it over to
improve on it, you're welcome. If not, I might just as well put it
up for general consumption as is. I'll upload it to ftp.dante.de to
incoming/tds-html.tar.gz anyway, but it won't get installed anywhere,
before you give me the go-ahead and one of the CTAN people here takes
care of it. (Joachim?)
You can also find the Texinfo/Info/HTML versions on our WWW server:
http://www.thphy.uni-duesseldorf.de/~vieth/subjects/tex/projects/tds-draft/info/tds.texi
http://www.thphy.uni-duesseldorf.de/~vieth/subjects/tex/projects/tds-draft/info/tds.info
http://www.thphy.uni-duesseldorf.de/~vieth/subjects/tex/projects/tds-draft/html/tds_toc.html
The HTML version was created with "texi2html -split_node -menu",
resulting in 36 files altogehter. Although the conversion should
be automatic, I edited some files slightly since the copyright
notice ended up as an unnumbered section in the same file as the
first section rather than on the title page, where it should be.
I've checked the HTML output with Arena beta-1c, where it looks
pretty good, especially when using a style sheet that turns
`var' into slanted typewriter and `samp' into bold typewriter.
With Mosaic, however, it looks just plain ugly, I'm afraid.
But, that's a problem of the browser, I can do noting about it.
So much from me after a weekend of hacking,
Cheers, Ulrik.
P.S. The WWW pages mentioned above will be temporarily unavailable
for some time this week, since we'll have to shut down our machines
for a day or so during the time our computer room will be painted.
Of course, I won't be reachable by e-mail during that time either.
P.P.S. Perhaps it's most convenient if I'll just append a gzipped
shar file of the Texinfo source (~28K), so that you can generate the
Info and HTML files yourselves if you have makeinfo and texi2html.
#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.1).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1996-01-15 03:05 MET by <vieth@zarquon>.
# Source directory was `/home/vieth/public_html/subjects/tex/projects/tds-draft/info'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode name
# ------ ---------- ------------------------------------------
# 59801 -rw-r--r-- tds.texi
#
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
shar_touch=touch
else
shar_touch=:
echo
echo 'WARNING: not restoring timestamps. Consider getting and'
echo "installing GNU \`touch', distributed in GNU File Utilities..."
echo
fi
rm -f 1231235999 $$.touch
#
# ============= tds.texi ==============
if test -f 'tds.texi' && test X"$1" != X"-c"; then
echo 'x - skipping tds.texi (file already exists)'
else
echo 'x - extracting tds.texi (gzipped)'
sed 's/^X//' << 'SHAR_EOF' | uudecode &&
begin 600 _shargzi.tmp
M'XL(`!P[^3`"`^U]>9,;QY'OWZ\^1>^+C<<9!09#RM>*<NQR*)(R+9%BD"/)
M?NN-90,H`.UI=,-]#`9BX+N__&5F78W&D)+7L1$OUGMXB.ZN(RLK[^,O1;7M
MNZRS=T6UK,V3UG;+HK15OK%9MVBG_M>NZ$J;767/BL;.N[K99^^ZII]W?6.S
M9=UDU_9/&;YL#;^>W=JF+>HJ>SC]XHLOZ+=BB:$R\X1>WN2=>7=]]?;ZXN7K
M%]]=/'OY]N+YZ^NW?S:?\3!NBL*VC[,S6L7Y]']=90L_<3L^\=0\?_UL..(3
M6RTRG9+_EG486A'O:)NOK/YYS^:>T"0?#MD+WM^3MI_)!S_H'I_<YF5O/^B6
M#^9)WG=K+.W[K[,?Z^:FJ%;9UTW=;S-Z.7>CC4UV=OWCUQ?7S]Z=T_ID:;?M
M3;'-'FZ[;%OV;?:(MEJ6QGQ5;_=-L5IWV9.Y^Y/&?/3%%[^>9%_\)IOMLVYM
MW53?M[0T6<+4F#>VV10MK[RKL[ZUDPQC3+*<X+,H"+S%K._H_-=%FRWJ>;^Q
M5<=PR*M]MNV;;=W2RNQFN_ZP*VBGA$";>D&0G><=`,`#N2=+:S,:9VT;2XM:
M-7G5V<7$;)OZMEC8!<V2=S)557?%W&;Y=FMS6FY!L"I++(T089IE+SN,X[][
M_SYO3=$^>.!GLG?;QK8M/:.E%IMM6="?N[S!E'O:]W6R'_H[O\V+,I_12>)<
M:&]/VOF'>9?3#M9UVYFS)XU=?GAKRYR6G-'?M(=J;EMZG-/7M#2:Q!*D_*/S
MJ7E3VKRU60MD^UMO6T"DQ8K:?K5R_R1(V`U-3@=`^)1OMA^ZW>J"4/W)DW;=
M]E.[Z`_XAMXC8'=YF>G;V3=Y4V9/;4-H<YD]^M5OLJ]H,[8Q?R"\R-[6^8)^
M?E/N-P20]21[=95E#S__U6\?TJ_?O[MZ0F#\T68[6]+2K8)W`W#0[9'[$6Z%
MN[/F254O;'9=;R?9RZIKZ@4A*^UBDIW1G3S7_Z)+5&\_0A_X_F3_@[S_@[S_
M`.2E/WIB(#&&/GZ<#?Y#+WQM*]ODY?$S]P(A^D5I;VWI60X8T>/PPKM^L\F;
M_>D1OJ_:K9T32A'@Z?SGT>?RPDN`'BMGE*/3;/MTBI<M;@!=G3R;$>^U#:'"
M_M_<&_3"\;D.IOBJKN0JU$T[`@>375Q<9-=TRY[9CDZ'AGJ-6_XMW2"P*WIJ
M3`Q+`\C0ZTT-C%OR!25&)4/+?+>T(2#("&",4;`;AM\L8N9T7>9KFC+>7%WS
M(C!'UUB;#D@O?%O/":ORQ:(8FY!>>-;3!:(+;3,GS<0OT6T:.V.L[54^;^KV
MQ-%BY!<$UY//\<+KNKI8TDO9J^?75R^^>WTMTHE^@BD(X&_H7HP/0B\\+69$
M^>Y9PS,E`_DHDAO#:S2ZV&Q6=)M\VXY>AA_RLH!\-/Z:,8KJ9C@I'PL1!7\1
MC#E&>GSUIFXZ)E)CYT!?C=X$?'BUJ+?\TPBNO:H;IGKM242BEY[?Y1B;:6F8
MX4(7.><=M++T3WJ5=]//"*VR9\^_^OY=YL^('OQH9Y_/L]]-'XZ>&FUS]#Y[
MA`LB[3$J\QF>>GZ$#4=O"C:$GSU:X$"R;K^U65G/8TQB`!,I`!\DEE27/0\<
MOZ6O$%JWX^@EL@23Y('4S;)$*D8H:9B(B$'_SSR9K_,MH)12(!4(P/R(L^QL
ML^SIJV5)RLM,-\.:"I&.=M]V=@/Y8"'B1-VWM"'B94NSM35..R>)`@(/(=>N
M;LJ%Y]+VC@Y\8TNP+\5>AD4/5EAEMT73]<1]]@8LJ-[2VJ,IP>R_JVS6TW[I
MO0HTJ"6>G]GEDC`5Z"S;>-`:67E1%AW)+VO:$&D0$ZQ`Q0H@#)CUS-J*!`P:
MIUK18MZ_9XD)PD.^!Q,N*G#9,BLZFIP%!7Q%9]>7X!$DBVP@(+1%9_'H%JLE
MB8<Y!^U8OK8+P]+&RCJ6"G*_;0I<<2<XR6T<2"+$V!>VG1.W`7[38-4B;Q:Z
M33.JYD!6H1M].'],7X0[O"X(F'2+]RRP;9@63PS(4RL"'@ZK!F"&=[6H%G9+
MF(8E*9HH"HANF&57K<EI2+Y\M(MMDQ-6$1MAX*=[RLNV=A)/"R"W`N5Y34!H
M<I8N(3>UG:-..B7/10`EB.3NM/S-X[,AT5.W'DZ6@%>L*DB3-3#QA@4Z.DX2
M2VU317CULC+;O*%5]V7>3(0LVOFZPC8&BB84R7,:GL3(6RR)#XJN`"&S(:PG
M&!#AP5*^>W>8L.BX:2\6=:O_J-O+S^G/[ZOB3GZXW>`1'8'YD4!=[UK^M>H.
M*I6MZ1X(VN:+35%!#L\A>HA8#DZ+BX+KE\WH`,T2_`//6(1KY@7MP%WOY&0)
M_A`.<[`#.2:'8&-",8$>2+#@21B)HM-1A$@6F&'%!C>#5X,OE#R0.$[`!D3U
M<Z]<8%4D'^&V[CMPG&S9U#2N"2)U7U5,-W3*&!\8JUFD[O;*%Z<@/!NZRT`\
ML[;EULW9L^Y#Q)-1OV"VX0B7X@4-M<JKXB?61@I&5Z9D1I02FKB#$$@`?DRR
M<U:!,[>T,2)O.7%;DJ1OJGI'UW_EY3JF%L`T)I<Y(V4$")F8%KW,]G5/RV%J
MEV^(D.4-*S2LC^A@I/.0WK1I#6V9>8Y88UHLAJ57@@YTN`K42B^6DVGI/,TI
M-2:2^?\.N33P*<>;1@:;Q*,,E>"$13UI+?]Q-(J[]4)5QYXH)27L!D?X26B,
MGFVNDI!RP(M&P='6RVX'^&_S^0WI[,HY\(NGZHS7Q`)8528:WA*OW!L:;D/P
M+AC3:3`<"EVM`C_FE25N64+KO(*<T!"=6Y4Y07T"0@)$;2VP6KD406=#MV5M
MJ[:X];?M"M+8K36O;<=$[<SKI^=9+L\(L_MRR=>[RZ!Y=HQUGLD`3).,;ISA
M?RI"8\8Y::E"3STL@_JK@&0E>KG7R0A_36(BX,/#>`HI@3%>(4A-H?QD2V(1
M0F8Q27MT8G@Y3`NH$UDCM;GJZ'(1ZA)2+TE>I#&(U..J,"DCV&6V;.V.^3N=
M3,)\:%<OZ*8DRS1\(0/'9D$'JQ%^L^D)<,1[B?S,BHH9?DQP^JKHOL2M,XP"
MP@J(^HGRE+-BWMI58U=.7VJS,R)N%4!8$*>1W\X=E=-A%>5DLA:TDCZ?9/6<
MSH;'+?>\B[RB_4=:UM3?M.1299/QFS=^O:)/,SZJ!(;$LK#D#Y<'X7K,6HU;
MHU=%V`125Y!V
^+$>X#[O[-UF><G2Q\$)5D5KL#0P1M`L701PE)=,@AZ,
M*W*N)+&!7.-=KTM,QU;[_KV*A`^RE<C"!+N-S:OVF'W1`5;SLE\`GYV&Z1;\
M[(>7Q*::`H;H24:X0\(-07R2V6X^%63_*W`E#&J4.A-6M+9<JM!']Q4F*CUA
M6M4025EVH4\(MCW,.[14*%[`.8OK:QR!$FP*9KG%)!`FD>@V.2%0SFC+9BE@
M:P1L,=31R@\PG.\^?)O#D/BY/3C\FV2[=3%?BU(06"J);UL5(_CFAZ7/2V)[
MM%$26@@S&!;+NBSK'5L<]EO`8TM#1L?;/H8QE(`/LOQDUM/J._DA$_L7P1FG
M=C#?RA_PIY#.U=.Z:%-R.`[KA#Z)JL*`I3]W#;[C/Z<F&?G);=Y\($FDS.<6
M$L7A8-Z&?XW-PU\H<`XDLQ60B8D.8GNY[%X);+4BX3I=3$%'4\S!=UEGR?FF
MSTA4OK%0"427$T#X:QRK;\=&E2&[3-0[;Q3BXW:7VRD3+0N']`,A*0F/0&5:
M-@D_*[:8)J08*GHD$?SWFYB.!8OQ-4V.EA(IQ`X^GNZ-CV',*S8`J_P<\3-(
MRS"6$!4G4EWUFYD*X>D%+2IE%B8YN80F0B,1#+M^\<JI.G2#+R%$ETYZ-^)/
M5(><G"L=84TW!'<JTC!)V8,>T@H%(`"2?(&5Y2F]>TSX!B0%]X/BTXFZV<$-
M0&KV#C*(KJ6Q7M_GGYU0-.%_&GFKLJ)H$;_LMPN&`3%BN.4JN_->2U8E/)VB
M'89Y3$O85RXP`"P@K&!CU9X?0O/>U+<V&!18GR3J5/>-[-$V#;%C^HQ$(XR^
MJ6,9;@TG`KLW2%<')_$0%>$:B-*"?P'IA&237$Q#3,*=^/%K.B)+T+(Y$0>W
MMK!T^"<\U_:G3IK#4YJ+)?-YO7):1<[N"<+V`H)-J29B''J$+F"Q,ZM(":BZ
MJ?IJ1K^!7$$+9RL$RY"[HEUCD\YZL:A_LI48:!02K+6##HGD4:FV!>%IXI?!
MRU,!*2R&9P=W(\+C%D5@Z-:MO!L;A#(B1[`&`!G+&E>23J]9.I9`.GOPM;2T
M-K$]P@?A5',2E.F()XP(`Z@`*P?`B[@@)J#S9X1AF!I@H3LN`2&X*Y98K82$
M8Q<@]SL+P;D],12+*;0I\&=G`N';Z,^%%,-B8R]8\]KPT$2Q&#,O"&Z5-6K:
M`M5F<9"1;ZB=,_C5KR5`$:-4)A+/GM>1HHD[#OJ0%&4L@FUF7J%U+C%]R&)T
ML>K=6DB`E3U`UJ:!&5<WVX(AX#0B"!<LFI:64<_,^H88(4X*@H+8Q@;WA>:!
M9.507EQDD5[C5#B=MSV&1<UB1TTJ#$,"2A7PBS41.O_$8&T\^:;=LT6;YIH7
M)(;M)T<CLXB_R6\L=J]*G&6A5J`L*Q;".<F"7)A[PP'V0E(:8:Z7"]TY$"U@
MFTR>!0M^X#)B!I[W#8!0[AT'9D2/]E,X_8@H;?B826M9UVP^$"=L1,]P[&S,
M$^V3/A\'4,*)PF(NNOJ"\%1E#B4\1.V=)860W'MJQ4IEJSG18*;2#L"P4=&Y
M>0P>9["JZ*8N"<<A&J<U-K)%`@Q3&I6FO8RRJ*UHL.[0".![.N([_DQ_!*#\
M#F,0S(0P?WP+X*8L,.5B6C9GT#C9C'*_X^1P'G2S8Z%D(!!-3LHS1T++<*PQ
M%6@'YL2TDXVAWL9*GT8`]-/-]B;2T0[9&2#HU"@^#G<''CPXG^+HF4AL+!^4
M9QM@H$;T<'>I)EZ74^+)FJ*>>%@`],HMH`[VX!%A"C*&Y6[G!Y(GV/`QE*-X
MXW.A[#D/D9NR7K$-EW4W=POGZM!)I/OKQS!\O1/%O-P+!7.NF6"=]^N$JV[M
M[9"D4(']7GA;N8@HN#!@"%V`N6Y85"G^^$N,!5W6*)WV6G;?-I=80GE)1]C8
MP_&#P\0<O5L6,[$HN[?I<HD11:7^^;HNYM;=(CZ&Y,QW!!1ZIR4*P_<']EB"
M84,:.`1V4$K"^9(`(6HTK#G&VZP"B(CL0P%M5<2"ID'_9!RI0:^@/C4#+=R<
M>2T\HK;.LSM1%ZXHWN>1YNU$=-:VOQ33G(BWK/,0>;E5(9@-`20Q)]8I8H$@
ME[2)B@4!YPLP*;\`EPMR%L$(GALG3K*LR2,0[0QW*[A>@C_H+$%<IN61L$$C
M]%M2EA>6;ICJZX`>W%R0=.R**,6&;G*@*D<T9$2)ND<A"B1E,-"`T,[S*B:S
MGJ\Z23\2U1%LHW9R\_Y]F0S[X,$T>P[Q64")\PN*!]^S?#ZOFX6BBO#9>L=V
M/V<Y@`@K"`=17SV+M$?`7H;E."@G"T,8(QK>T%JJNN+E/'A`+S/?Q2D*CC(6
MSW$CO$(0D,%I8K$)$:]$)PO,$S=:M`8W=Z9PT(G-T<0[=F3/Q0GJG3L+1S\$
MB-ZE0A.9R``43)]B@_&*!@-(K_[&TJ0DFP/_TC-IQ9<2#9@R`K8#9$_A_6%L
MET-A@\F7$'3$I"O".[M#<4,L(7B]-^PS2DW@CSDJCG@4JTEJF;GRL5/EWNM0
M$A$1V:(\-@;7N[OV([;&B#"2DDZ;.3AP$LEEK;2#1X44_;8EE.SAYV[QRE.B
M-W3C_05T!^ND)>?246-_"BUWZ2&\;01CQ5\LCAM[6Q`4G%UF&O8?B">NK*/@
M0NK9HT8:%BFQ)(4T!6##$AKS0>/WK;-$1BMQ#!T\_QA:LN!]C)ZPA8\V<#@D
M^@6AQKSG0#J=(5CW="/$4A)R0:*\;6YM.^`+$<?1G8D_D9BH>L,#!L>2Q=$G
MS'+S!4Q>\'=&RHS<JHE)>7Q)JEY/>YXN"!K>B?DTG]G2DRX$)?/+:JULI_/E
MZF#<R^Y7]SZ1H>\K"7,<7X.JV.Y]9^1H$.A7>8S0R2-SP?5:!$X?">!M"@P`
MV+'=K+2T.3'G8'7B*1,J)>#`,`A#-!&S@5K<6(Y.]*&JT<5$Q(43&W()4QC2
M#3#9/9UI(<L20[M?#+'JZ6KJQ)0WWQPX**KUH:C\\RM2P(BVXJEP:]I305HY
M#P.1M/GP[+;8LK<@8L!B@N-C22=50(JS2%RFIRW-0LE\=(67^?1L^)P2<VAV
M5BPA!!$WA":T(4:=K<IZQMN'Q1EZ\?F7[E9#I"B)N]%N((1\RO@Q'=.H@B//
MR66WV1ZB67`):_'[BZ]\,";=`M+]2W$(S.K;9(5[#?X0!EL`Z\)]/2/98YUO
M23"/5G))E()(AXD5R/#DLMW6=:DNGO.A??MU+6S:14"Q]VYF$\KF%#YF)D'0
M&95KLA$EZDBR&?G2F&?>]2=XHUCIC8#"Q>[H*HEA+S6+IV$GP<-$MPE4KX\"
M]X1_U6*8/)K+\%QJ.O06-0^7)<(2P%RC.5AKAOBBH4ITAPO"N[W$-)"86\"R
MQ&I&(?R^Z+RHRMZ@O_5JZ,RR/VB(E.E2\OUQ<TS"!X@'S>WVI&-'L>TU0!_"
MM1(SK/.XZO(@A!%4V-3*[G(Q29A$S<9(T>40%N^U'__CI0K^!U%$(3WI\!QM
M=CP(B353.YU$[F$7C*1Q%L`-@-.,X\XTDTAQB7P]>/[9"JM;]@VNW/0<YL.^
MG41Q:#)!$GK%^)#HKQ-68$TN5C>U:SCTF9&.4+&J!>O5$#J1180FY9N?^B?:
M'CX!-FV^J\=M9LXHHFOU*S7'*TT5]>RVR(E*PA3?*+5G;2'AG<;Y.01EV`NS
MK*M@K:<C<V)H=%O/F-?HAN>;YM'#Z?;F<#X!E!+QA0_F.$87_"4-G&V-J"=B
M$^]9FUA;+[;/F`T/0SH='_4$[PHQA,/H*XD/8J6T)/:]V/L=M8C#V(J521S[
M8,,L:V=B5%EX8L:$C+7[LKAA,V*-4($^J%]T?]RU_)1;Z:.KXWO)W&,+T4Q\
M/`PNX>3G@TM[SZUR'O^7E8L2=&8;B3QM:F*<&[[UJAP1*RGRBL.E.!BFAW/S
ME83O"4E5(T/6EM"U8K%(G$JQ'+WMJWDW)?G<H0C)27E5RB\XPA:,B:U:&N#G
MR:Q9DH3$MF'/M23*I)5X&(9[H^E]D':)U-P*PU<%CZVF`J(C_`B90&-^7HT5
M3^-Y@Z_W1,C]]<`](,P[R%RJJ;!1RKFR52#Y*ZD3(81CQ'>8BF'UIA#-I*_@
M!"3-,8U*N2KA=EBM4\<R71T$.I!4A,!5R%(#LX*7E%H]@?K>X%25-G>)Y@NM
MVAL1F6(;]NXXLX#<*9%]Y)R.I*U#&O,48AQ!IM(H5;&I6-X',VF1$XLV#L:@
M?4-+A@!4>Z.3B6R)21BEQ&(Y+Z23;SBV:.S4U>"(C"<8(04+1E^-7!).%/?1
M5XW]6%P&V(B)$CB52L3\[GP0<"&7GS_"GQ>IHUP^?>'DQ>3+C>UR?"(?GU6:
M!W(^2`31,4ZDB8R.BBPJ&=59&-.=Z(]'W\Z*F8>`6"23[^2GHZ\6]5P^88_&
M(LDND`^3C(.C[\7-+4/(W][W*$93,"286N(8-!>'I!^P;A%L!:18<8;%P3]?
MU<P?(ZHM3RYW_-XYTTD.%E*5;M'=A:_/A"B?'`1'?B<;XX>ZI23">%F[NRB#
M@;>!D0EMB9R;T`RC\`S=Z9>X<JIEXS/VR:O[L9"$ODC&GB(HT`QL1D05BFK*
MHI)W+1%#J$E>.E;&=`L3PZY<I71RZ_/L_7N-3<`'+MZ+TP!%EY:1.6T`#(-(
MIWKD`TD2<54-U`.H0JSEQ5[.2#D'$VL-?.*Y1BMF\84<"X!*Z>GA,$)D$;,H
MX&D?Z^1V`]@X:"EB3%SP1XM=:&0'M`J?XK"P%KRX[45#=G0G<K=EGJ*8`15\
M$9MG*SU7]HK`Y=[M$.X_6'<0D*&+^@OJP#?%KXK/&[N!)K'H-]OT/<&$Y89(
M@"&D!B5F`YLCQ!QFD?*D':3B$4,09&EK)>KZD_*B#K'4K+%%4&B#H6YX>O+=
MV#GKW7`'7"T*$M[AA!NS6`$B^D%84BP-@H0,`J9=,/HQLFR6G4>5!1MQSCGC
M0BS&)A%(_(N>Y,<_,+6./5N.#"=A(3!M.,=;"[1PD1P<]^X<>1SG/)#"7(S;
M_P^IBL=1<K*KB2S^9$SAN##IC2@RB$\8DY0+00KQ,@/HL,HQ]?$F_%2Y="'1
M"S/;ISJUH)X:0T6CVTDTZ7MYX8'$4B9AUFXQ0E3I0G)<3X[/ECVDL"=SVO^'
MO^!V'RZ8\N@4Y^R%$'PU619H:FPUOTRLY9=J(=6/3JI3T=USUG?#'$$WJNKJ
MX*[0!8IO@7#+A"MYAZ\6%F%>FAC=<QACVC2IQA-.1Z!Q*6SA0T1R5L%]>)C3
MHZ]ECDGVG.<^5PJO!XS@-1E"O1#B5S%I+(<[6"G<$23&`7U/S/T<Z^(7X];K
M%LH11)%7CO609%E8Q8C[0];Y&'PG7\!K['RAL2&JC:6#B4%,5.'PNLFA8])P
M.QB*I4H"!MA@>7(7PJI94%!&;F0)$]'>P9%([]#9-R*5J"X`4VWD!*MG+:GR
MXD$I.,]`@KEEO.'1)_Z6X)T9`X6$U<;X2\?1MPGV!H.9<HW``7PVC%RRC,D"
M%L;<CT-1.8U"CLP<(7I%EV6:(#=DL;;;,W/XVEDYU3H@$?LDN2D<9?J^U9W"
M#K*2@(.%D/@W)1O50]"*%^,:AJHX!2(<4GCZ\'B<"2P+#5)GV`4=7+5>*C6Z
M>3'#PE^<S!MDX6.AT0MN,$[%1JO.MATXQW1@QHQ$4I]1D`3*2S2(G-3`0S.%
MX"&BX,!,?CAB@55=B!E/;))BA=]`,>*LO,PAL@BX+N=MGP8?2L;1J5N81L!U
M:QO[*QW.Q>Z'HI+HDKHA,)[[V+:8ZX/?1P'(/E96HSDG1NP$',I9170)T6M8
M@#@8KUZ]NW"A?H/0(K>5`856FAP=U-$&6-=VX<'&K8RD>CO/<9_#I!G'+VWH
M*K"A*6`4NS^.1#KGOQ6^XI2@A'D.K]T,KLY#E(:S:/(=LY"7E4__4A.C9U4<
MOM"*'8A1W2=`L7<!6T?62E6;O+_C5,5]%"'>N?AN,?&(K6RFULS%/<[J$.PH
M0;TV7P1[8L*@6??1]"Y_9,J[2&J7,/SA[5/^Z?Y;B1&\`J?>Q#3)ZS^?_/HS
M^R3ZJSJ=]SWCWZE;%Q'O[!MQM]+'3JDQJU7_*4M`+U^_O'[^IX,$ZT`:TMC1
MC8O`'\+0::OJ&C62(Y0F^H73*V$(D'F=.WK1-X['SOI"XL9!,<:$Q3`0[SOR
MA:?(O]YO:?T.+O(OT5ZVG(->.9>SCB9OR(&Q,0T\M.&B!N*Q-@PEQNR9$Q85
M5**H,/DC*:-W>N4@%!"$QXB3D$<96EH]2?!<.]Y/L<%%\4QV(ZE_GM5.?)SB
M\VJ>;]M>]"TH#^_$5<[Z&P[/V5F-$&=8&3F[HF)+:4=J-YNC!9M$5&:K/0LJ
MP]`3DRAE0ERPT58,W?DB\8/0;T00(%_"58DSG]5W$"FUID`E6X=O!*;CC478
M?=%N)(QC+>G@T=Y;K]0[<P!1&161HF(4D=;))_X2$;JTCB6I.?2[15Q!<PY@
MS.R^KA9B9ITCI7Z0<OID^H\_Z?MXM*;LCU@-[N'=J3VS:+VHEF8M*P$7.WY$
MNG$4U2!K/WQLO,VZD6A'OM,)6Y,8'(QWP13>3RLR>`&O8DO?:7I!(.)Q/`^O
M^T@.&7./J.9Z0KF>>`WW(SJL%O%Y$=R)OT!U!:G`QP;H.!$GHHN;TNP`>K"$
M=\'9DA#=$N2$KU\X8LE(%5GV?5@;9S<O7!4I)9$5)R;*5D;U5PD.87:#):C^
MZF.ZPA,L[I?HLSPJ2QT<?;G?JJA?N=R#G\D4=;Q/X8CY<J.BV=6BYL`(FG1C
MB1W-D409ZRY+?=&%^T9N7I=$%[^_O='W@<,XWI-O.GMOYCP9P?@]1$A-KY3D
M),T6/D]'Z_R.O"'$;VEL=@#KD?MB]^$:T'_D8JK.U+XMU&<PTZV#B);9D6].
M*P!7FH0\8:(Q=/4)^6P'&4A>*ZR\9F`4^^E`U,OKM2[.VF*?-8F&BV+APGYJ
MK4-X/BKWANA$$7PE=";*Q8W.9,3"`KSQ$G".XBO&.8=1@NIP_K/Q-UK0)^'P
MIHV%NJL-T#.':0W&@)Q+YV3OZGEAN_V#EM4#.=TY33X(&/T[=;_T!LC^=1B4
MD:&#(6KHI#TI-L8K$06!>:GNG<B2F(+,V:-S#ARR2,<+H=NQ/A=+9X`&Q_$W
MV=GGYY)=A(`Z(Y%@1/R:O</NY#L^QW-)L_#:O0L&`#DG.ID3&NM&1K8ALP)=
M\;JS:]#.4&$@%',Q^)!C"05"--M&=++D7FZV#G11,.1%%)>HM9;:89&(8<IC
M9D+B"*Z;YL%&5XI'X;MYG#@^1JR9T'N"[=)N\L"AN,3,_OBRS#?^IMB^)`SW
MQL=BPQ[57T+J936?I`#1_-F9AI.DES2Z0+_[C>+'PBZ]VVM.HWQP`2,B7%T'
MN7$"TOE#7:)&S_/#\"*(U?5C$[,]2.:-8O!99Q<U2?GUD=+V#S+<)/]Z5W,1
MC@JRE_4NI-/2@GIG99.76P)7W>27VPH!5,2A!F_3+^[5^>92PJQ&W@*GNN1[
M>MEW];:@`?NNF6Z7^4#F>%$W(6K54Y1$AF*D52ZJ%8V,'/(+%\PY9*(M':'/
MS],R1R8J<W0>537X>\LY'GM;XA$G(Y][/XQ(HRA]'<NG[C454V-IQ&?G<EJ'
M2[!&?-J\';HF.=L.#C'C=#V$'R$P1?@E(D;MXPPT.Y;E%O86)7?/)/X1`6[G
M[/,3@Z;<;EH5YXF)IO\E4V\MWN8"I%3%DL5/L15'$GSYB1`$%M$1+V6WCM\@
M("R$8>KRI%A/4B4G*8>3R>T1)0.68<1Y&><4'ZO?N^0T;_5"T#,.[6/DFNJ=
M(I94,461%&Y.[4OSOJ+]*\.B5W[U\.&3Q:;ZL-@6K`.8WT8_G(N'GPTYK.M'
M0[#O(:XLIN&['AC&KW%*BI$639/(4C'0(F9B`BUM;D.ZM#.WB&[M<Q@%7U"[
MS+MPO,+8H=!%EP8Y7A,&@M<A`P3ZHUVYQ'PY8&C(&C&81)@E.&*B8$)OAHJ2
MUD6H!.9P#8$0O9V=:0$N=CI)OD`9E,*T`,_Y9#ASB)KQ@_CZ12-QI'2$""4=
M)-3SA5C4DGPL(=$F7>5$<1A0"=';D2+)"!Q+T;.].48B]9]O"UK'98ALI4-X
MJG;D;B11SY&*X9)VFG6GWYE2JC>V<Y)`10;78Q4=`4'`.ZOAJ73FC/%)1CFK
MVVGP'"TO-HLO#Z?9S_9&M%+@\L?T50(!_U)5%2FOZ3BKY2\=YV<KP3Q%K(%H
M@IK259?S%"C5B'1UY^6I5;LD#GD3'+]_71)'9FS[ONTC3]A`AL/9>81G2N#N
M&YM;(\L4)]Z(S>>%ZJW@)#@O=I/H+>2(YMS?';Y[7KJ.@Z"=>2Y0Y;KOB+\;
MV7([&9KU!6"R<F]O$;=.4LY0$=XI9>WG$5@<F(X"ZZ*S/!@7V-B>X$=,:(Y.
M0ZZ6/Q'\\_,O^`3\#P>QA(NDL:@[3LH%$5E/-%5@6]SA&M#/*&JZ]F[M*!HU
MO)*1T%V2(-T)J>[;J**LKQ'IB^@*DZ!52#I8G>@0"3V7]Y.D5U_DI*IWZK4`
M'UOYRQK`I]EFJ'J7EW.U-D-K<58[AV^&&%*WIN6C^I!SY'$!38@#`@\MB1=-
MY[&5O;<2S&$$=0*E\*1*BDL$"+8;J0*SC.I8\B6(3ID5NI"SUDN@W;+I7=!N
MEF\XDJ_E8FZ^.C#8<@A!2&I`B"XC(-Y]$-/BPP-3VZ@R7/"3',F=L91QSF5!
M(I[GZFMP.*.3D'+BXC_]Q`ZOW8=__LMV\W#Z^3\#:^:T)E5.Z"68;C<]UT)Y
M=.Z`$1#V*-#\Y3"5(]_[3`Y2F%&011-\5'>APW4<GIE#"*H;,&,I\DK;*8M9
MPTJ[MX$E'1W<J#*<<46<E'G:14CU&A.:L\E`LCX6GX\_B]QTJ$;CT2F4@\X4
M2]HU<IK"IM:Y5#6"'3M?W.8$MY4&W5IQ%MS"'[CRI:6Y-`*T$X>9(B"KI.,+
M,45D\V3Y*<YOSYV;BDUPCCAY_N]C4UQ)"2:O($_#9(FWR'3('HG4R?4@.O.;
MBXM'#VE_!`R?JL,??WYQ\:M,1&87F.SR3;R,E"0T+8YSZ[!_E7>FY^@+(+@J
M=%`Z=B#90PJ4=`TA$YN;XA"@`>MJC3/OV$J";(-7*1$Q0UF"M=S:O636JZ[R
MV,0A"KS/B:CI@8JX$HH1:#QK54<("XRU!MFS,!E6@UKG>;MWB7+EGBLX,DTY
MTL]$YV=HBR<2)\#LV[E.@Q(4R*?4;B:]6BV&9;C'0@]9\%L,/&]:6)@%.:Z0
M+20]CQ<ASOHD'/F,+1YY%[)=SH=ZU4=T;2=]'Z]*RKA)_A,=+2VO">=NG#[P
MDD.E)R-0Q,$M7%`'?+>2+<D%C@=+U/@WSM<EX/-41QMWQ=`':Z"UXTRZ0)Y.
MNZ%\L9+[0BV#/^K$0,:\`H$93<?BBKCXQ#M`V7,A,L/@"?@:^[O7/6S(MRSP
M:>CU424"GPD*!F1WF<NUD-D5%(M:4F))+^@Y,7/<AS8F[[NXWH\$58Y%3!R9
M+X.FIS$O:=JTBS[>LE'_OS148TPK&`9K^'SR()]'P;)YZXMQ"JJR+0M+=*_/
MZAJ";UK`0*+`@,M!LT)_(_ST#W$*Q$[E(;Q;YUCFJ*K1V*#1$W'W\?Q4&MQQ
MM9^3=^UCX<HZ$MTEE]\C/JB"':P7"'_"ZEUAB*CF"MV0/];KBB[$;$;:5T(/
MOZGZ;OV@]:M!F?GVJ*.#"-(JVYX(WC"14UREE6F\V/C.*V%RF=<^%-_OT@?C
M^T)TYM-O)8+K_TMNI5M[*)"A=7HT*8TK)"!9O(*YC`E)*`WFA32)9&&!:MOT
MG.!'P.3$>J0L<N`(RP/.\IZ&/$CA'=HW)NNL+[:P[+EAQ'\C-7#@B:C!B5N^
M/41$S/_D8J3J.]RB;1I[B.(D^'&8%F:2<+`0X_3JS2`:;./Z>CA7FD39T)W(
MD=<IBV9'BU*2?SC1&:#3QXG.,&E.KHL;+XJSB"^7ETP(.GY*N49[STHG)L37
MY>JHS[=@E=X,KX'E7(:778UR/'EJ+8M@2ZBF!"SLU'%N,4?#1",%.#=:P2XO
M32BL>HJ(.M*9Y(G$PLE'2*=\;XS\]R!;\]/(BJ3GX+^&A&7XQL=(SW6(#2QF
MA[1:8)2#N<@)YA#D->9@BK?/72V@*,"P[>)!EKYGB/\..9^^UO*G$3Y=0R![
MHR3&?"J)R<X2=5!D/AUE(896J:L5P27*C,(&?CF5&L!3F`^#Z(A8\1$QH+W-
MCFD55O`/IPXIS#^--HQ=EL$ER8+D\9%;DGRH$GNT&E='+BE:FR3^/I9D8%+.
M^[PD)'5%,H+U!+2`#3"KGK0[C2+BN%0'HHG8#*-D>%>2NPY]/_"&[Y`CD92^
MZI3K,85J"]`&<I"98'],4_\'O#.VMHHQI;4QE4W3G"/R89)XNSQJ/BQVTAR>
M$IA*H40#?FR?BM,*U,N;U'HYI`%[N3/>C3J_:6U"=UP&R>%R.IV>%GO\:X>A
MH5\M'4BU+^9'ARSI"W1Y"T[1MC`F:NN0J`S\(!5.'%%Q(MCYQ'>5B!]J%F04
MU0]]VY^R>O="/0<7D;6S,_^1*]24?9IDI(`H[I6$?HR*]T2>DPB(G.W$7#G=
MNR1<!`(=42NI`J]4D"TE'%^1(%D<D#';FY#M\2`JQ-`,91<]0D=:A!:6D%'=
MZ'&-823IUMD@B\B=SJ"^YQ]K`D&QR=[-UTV]H$6$\)1084,`<.3:0,\JMR2(
MZ1>1Z20BQ71>R_QOAP>H_)G?%@N:L[+M`[WQH`QW0C@&HW<;OV&,P?\.^QU&
MJB/?T$482R`_05@3+:*OLNSL)7Y1&H88OV&->13BT$K2C@B0HM2J^<KCG\LI
M##4\'K1:*QI&Q3'F\@F\Q:2\)6$(0=)`M894TD@J%-Q3B006EV'WPN2%E#BH
MC2LUS5\,"IL<B5R^VB<G_7LK^U+:`R=Y];X!T^6)],MA40B"_@^O4+H6#=-.
ME$6YO-VTEXR=SK@RO(1I=I:SW3IF(C&S<8,=H_B2I#9(V4+$/+MJ@BYU/DZ1
MT";40O`D*\\,&`]?FK,6B_78<+KSZD')DOYS&EJ-:"F>XZ:L]Z54AV(]ON_K
M5=;>H,N%"[/P)#<I/1/PCWNI)#Q,A>=!L)**1!%XZ-4I7AZ^>23E\8M3IJCI
MN\>)1TE40A`!SW4(R&CI$'&:0#KA[U4,^=?H@R!5NV0$W@.I"2?V$/H3_>)=
M!+'5QYC.-Z()?-*N1#S^65N"_'&<W-^.HN<A,@`Q"HD<0:-([,-PE.,:.[(T
MQ"+\:_IV:%B;`N3&[_SW,-HE7[E0,35ON8BQ97TR_(/%<3<@#>DB,W38`)\D
MEV*P)(W"]*/HAA#2P>.,!+<.8GF2CZ=PJ/^^JBK^F">.0V\^93>_3\FL[F:\
MX^8$I/DXP$C*J6`P;QY/SL<;/:/21T?W^PC=/Q'A88CE$8ZQ.QM/[DD&"=;<
M3\?\P0ABH=?=LQDRW7UJ#&5--#:!_IW;W_[,[?],FJ5+34;^619<`LNR&Z$2
M6CCWQ;6O6S!ZN$*]?J^2:7KQ3Y1P.8&E6KN%1M-HX<&"TD)3XHH;'2BM:J'5
M@T0G&]OG49%0.0%AZ,F&8A+"*M0Q1/SM_Q3V(`D^)T::NCO[<<XP?G-HXR2=
M)\-(F?)XF)$:[5Z^'2TV73>CN=1*QH_0]B-WTU6[#F5XEM6R;77!FEIUF;*=
MD=*ET<V9:L9N_-%8#F^ZCBB'U\%*TF;C88Y29]T8)WPOGW9X]VPH7:,O:4$B
MYB\$MZ3GGP\-$!JD?EI:Y<[QQS'HIS]@$Y>799U,.F[52CZ\1VY-1=41A0$*
M52K!$K&Y9%C1'T=2C,\/DAA4J+<A:6A9<3$]_98IRNBW_&3P;5O&WQY1'?\:
MV]O\=W^M][9I#A^1NT\R(SW@[H[F9BSQ@AM_@C^!',DF/I;?P%_6Y6)EF\WE
M\63SNKG9YEM>\QBYC-$Q-3VE-,!7@4EL42=W>K):P4DVNY3JO]YF,T([!RKS
M*1[,(.+&ILZ:3J^J86<PJU:L"4Q/7W-<=XJ.;:2HC"&'/`FY4?S/?W]T\2__
M(6="`(*Y+3V3TS8?M\9B"!D.Q&:1CVF0MSREM3Z<!$2T0[]7ZDP?56/+QQ.]
M`E#@CYGNT-#$XZ$7\_!5-OSD,_24"^V:-P5:W4GA=D'N_&]'<SB+51MJ>@!D
MN!J=UN)@<Q4ML=N4QTL,UBHG$W"-CM'W5E5_R&*+%$<`L2??&:_4'$'#'-$2
M_D_4].,4>SU]Z\NNLKOV,X\OGSG*HCN<^JX2QS1LU2SE[;]'BG,E!,6`>UK1
M<#P>L2?3L7)\P,0+J2UNFS;L8%QRUV^WA(9AI!Q"2_CRA-#GV$:\$KY`5R@.
MU=%)Q,UO(1;I7?(#DWAU<F`6O<*:YOKO`=]5+CIFZ4EM=5G1MGU2J)E-/MQL
M=%'<C8PPWE:)Q+P&Q5%26WMPQG!0<,4[1OQ$VLUUK)_.]:"%F;VS<\V`=6CR
M..05U'66]C#3BJ9U%):9^_$F&0D!F1C(79H)_3V-"T-SC1\39FU3(^^PO1#:
M9-0KRT:\)`L@ZN$SXY)9XC&BX5&,;1/92J,&B>Q]2+KRL)TP[I(D4/J>>VUQ
MH(,3[#@F(NZ,PMY7D(W'B%>5)G/<:*&J#1HPH!>E(B0&<MUNW;DWFJ>6;IE;
M/O%0"\FI,:NZ7D@JV3IO-KS>Z"TN[,P9<YR]WTCS4,"A9\;%?8R2)L734YAP
MJO!H(C=K>ICZQ%$$51O6/U83<]%H^>Z)^OU<)?C2+CO?PV^LO&ODAXFL\UH6
MU=Q?%M5OZLVI]F-:0#CJRNLR(>PB-.&:<%$9R65G1XJH52'"TG?U<JF$8QX$
M/@A.B-)PZ*C^?WPA58A_0XJ_I*"/]+8>$^*//V#A?8PJC=`9+](?#S-.@]Q5
M'GBVB"YQ%CRC3Y5$>9O034ZR#%U8!),L]DQSD!>'.\35PJ&_PB7>(7W.Q`4=
M.36`*S.+)$G"T;)@+_;6UF##NW7M2[AS\U8Z>]V@(XMIG:PF:?<797W0;=:N
M.)DK:F!"5;MHV^T@V3WM<,&%'`D5;P5US+",&U\/H`5]_O+==X>++W[[VX<N
MAD1+"7$W,H[DSN?HU^"/R[EP1=SPSKJOGEV\_>[5H95B_$B`Z*1^`<!NK39G
MQ`:JE>7$C$WA\CZ(4'!_AH&7BJ/V.2FP7N1[A#5F:3:59TOW^'U?N##JM*)4
M*]T:HQ"JJ+/T7AJ<L!=*LU`8_:3G++Y##PNXO:2C7A+^Y&<5K'-M64+HAQ^3
M0/4\9+FD0Q,><_'-,'3V+-V`_T!&KZ)QTRX:W.\YG2>JP20*"@[]($'K?D8C
MKLRKP\6%_/5_(:/P7P_];U]HR!\KV"TI>817WQ(Z-UR[C\Y!*AYP=VQ);YUF
M9]<.S5SF==1+9%/<V<4%OC9Z;:5]2))3%G*$Z7<I<,#F<M=>T]5L%Z*JA>(&
M13>ENJ"(#)SS&M())26+;XGZ0\]#4SQ"TH+XHDOR;@?9+I#C\4O`',X+1EH!
ML6;X1CGN5'MM%\LH;JN)/D*=4=2=H74DPL>+E]\^?WWUZOGT$'K#39__Z3IR
MU5]YAD\$?P:RTFB^'2_NT<7%KS[_W6]_-^%%L50HF21N'P'I)WZ7"\G$;.F*
MS>MR:+SVBZ*%?/DH6LIW.&2Y).%N:7:NECHA7%G$I0*[N$6$.=O4?473G\<5
M6T)NQZ"#*"=(2JE0#MFP)(DA*XISL%)BQQ>\&(W#^?;SRV]_=?GMKR^__<WE
MM[^]_/9WE]_^R^6+[[Z;/KUZ^^4C>NT1<\?/L^Q76?;K+/M-EOTVRWZ79?\R
M$B?HUN`I-4\LI>OX"K2,!P*3>W.2YW=1F8M!ZG6\J"Q:%_XC:QM:\8X+=#B:
M2Q>![B-.._2N$4,,J$4"1"&D9D-8Q"2TW*Y)[T<*9J`B'"CM",+$]ZT?X*@D
MAJ"D,;<!E#O6NB`1%3Y.Z#DOM5`.K7C&]`9-R/[MI%,\4H5&!^1FCZ'A3MX=
MY;)GLT:";E?(O:(CSKFW$!>$=7(FT:Q&HB^X\>8<$3R=]3*(]R/$XO$@C&ZV
MUT`*F4QIY;)1,YE/:.+$5L[`@G*@Y2UI+9KD)Y8J'B/J%H.]Y>T-%]E$I0+N
M1J_Y"$'BT'`]KD\L#9=9#%#RBPSFIK<DPRX:NK%%]>!!*NAX#2:4Z(_*G%PM
MTMK<!%Z1/E&1_MX.YFQA_BS[I+X%)ZS1(Y-//C+K245['(V\L#N<RJ'2L"\N
M5Y:(WO4H)V4WM'D(:;X+;DE((/52&ITB!WN.A=.TZ?=$:+DND9-5@:PM286D
M<:"/27F/*/45:9]2"6=!M[C"^-PX0P3BUF6TD9ZSJ[SAU>TBBMZ2'RZXR`[Z
M:3E:(%8%6NN-W4<98[C9MT086)XF?B^9N1,NI7S1264O4*@VXH#OWZ.X$F@)
MX:1R;*3/=K1EE3>X0\BR[(G?PV*H&:":3FNTNI9JW*'CNEXG)RQS&T"ZVW8K
M$HJDDN+Z',5R?44;1"6RJL-=XW1=WWT=@]"UR<MVB"0^IY:MA$02-E;HY?`]
MD`<DEU@76N62AYK(N.OL<J:ME]V.(,LTAWC40ILENWT.8!67SIW7?=-JM$5#
M/+8L9K9QO5GN2S5W04S"@L3$XLXULR@FU]259(\*'T>F+'8_EU;MG)&+;&:7
M6;X-)C>I#4-:!ZJL$1R5K<37*,(W1Y>XE=W<J]9:C*W9,,2`A/=\*S88F$E0
M9+[=(F=4@7C/+816U&]'QF5X(,2Z;M'8C;-/7=`Q-\IU2FNTZ;2\$%)L#*X#
MWN+)M)SA,8Y'_;U!%NJ9I%TJ6-F3"Q*A]<D\K@6,>B#V]$',<.AT!$.^85-=
M6Y,6FGWW+NFEX2QD<XY(\VW:4<LH?<2QBU)>G0N/:@]!L4RZQ-&B#;=`*0G:
MO"TA"<37;`%S$!";20-0?DV;D:8<+(1!*[*-]LD;:_S3NMNX*M@2R=0ZI7*D
MTJ$GO%9)P?3>,LI]R$.O2/Y8BA(ZWA[76@7#BN/WC2,$0#347@IW)^K8&R$J
M$'DZ)LP$&B6K$06+*0-MG$;^6U_,;\J]4L(1"M-NN0/"H+T"GY]M0[$!!2&^
M(T[58<"4".X&:XM/"]=/.6E1W0*+.#)?LKU8(-K5S0WO/SA]?2I8E%2N2<83
M0R1/4N\$EZ8^FB.BE/%G7-=-VA/WW<`*Z'F_U)MW'W4-U_RL^Q0K3-XPE/"Y
MUU!0P@BEGSFNP^Z(>C7;IF@E'?>HR6FNF8)>6%.1%]9"V(Z(Y)TYF5,"HME0
M3P=Z+I4BVW7""<S`9B.5R*,W,?*:-#?N8=FA>Z0(#8`Z-FC<C8PEE739$Q<D
M6#2.;"G*:8`PG:R]VT+7O+6NY+1K^`QE6<D+^#</BAJ6FX+UU?'KR832O1[*
M6$0RR/,EC:D%L"0H0#H6.\J,)FE^.V_IHM/8>Y(AA&+2V@F=2=#G9N`H3E:L
M*IYKG-$,;$Y,SUQAA-RCZVT(0CTQCF/7)NFC@]#V-]H,6]I(,?&5"B;(21!=
M0PA/WJI.[*\(336P5!>M6)W1!?@%>WMWDU2B[]8-UW1G[+F^>GW(-",#?6"X
MYYEVRVP4=$%[^YAP_4G2_&1<</^(!'[_U,:\#0V+1]_PQ>AFDH()=-'NH+Y%
M-GHUL$(OHHC7/*.\D>"J71RT[[-OE:P?$GXEQ=<X.2?]$"'CWK(]DOATW*]4
M?`)M:$J*>U'5L/,TN3/'H-Y,V#Q7SG/&&5;RADV=%2S8-BGZS.]"WJIFT1PC
M<GJX7)%J44^,-X"/U%X9FUB06=@K,M8NEK3B:E%*$Q?V`B%0#0W<D>^CQBU?
MY$7;%W*K4Y`<A-BBP*+MUK6T%/#-7^E-*792A].2:H.X<$LK_6*CJB&^=!!W
M8^9,N`$M#[W&00[8-E]Q11<799DVJ.:Z3L^_^A[!^#XNQF=%3,R3YL,S!$.>
MW9P?N(6FW:CW64L2HB@LEX1JS_GY&Q#YK[R+VOBNF_ST3XO;0H;B"./FPY__
MSY_U59!/-5I*892QL.*X0!MPJ?0@,:=N/HK`P"K-+LRB<UV<$@$KY.,52X,/
MM,PAW`,;UX^[C1H&M.*Q<;WV)KKJS-6!-,.:1+Q=@BIJ0+OZR$7D[/0MEX$>
MG539M!OC9!UW$<M\7VM@,"K$BN09W:K0[9"%?#,6-XG3KVX+N@K,6[CM]$RR
M?^^M'76">K$*UZJ+H,F-LPYI/Q7M\\L5AO:N?)/&S;*3JV'['TC.K(;D7-GY
M33LQ2>ET4%<V\R')BV9EE>0U+C6-1DL7@6=IH<V@G]II0DOH9-5")62$]?RZ
M6>78Z2)D8_E$8;%,M6)B"XU&WXU.05C\,JZFQJZ)"DHM(0U+.+X"6;7&IB77
M+JY!9E!W=5YH!,Z)G0![;^MBD<#/*6#:$\9$Q;[RX$.8$P0M,JX+;U/)6U]J
M"(*WIXE16F(I"N*YKXT4)-@9-VP&)[^)5LAJC)8SR@U)F*@8V?J"18*Y*I=,
M[N&,D:-V(0Z7>,O,.EFY#'$1RKJ#CIYR'N<C23&4D/^9KU,VI*F.7I]8I2]P
M1EJ-:R[EU!5>S7Y;:]13-B]12E`D[-#O5/K<!YHS:"?66+YDN*4'H1[3>]+=
ME6(?'F?FMLA9AM"*P5(+X_KYGY!A\>X_WWW_]-G+MX=1:C"-AO,DGT;4J(['
M?Q%8_-,_';[,AK]Y6XQX)"5-#.?@(!8/_@TS09M'@TNK81[K\O(06_;`D]+W
M'O^[O#B=3O_C$`T+1D,L:@N\DP5\_O!\?(K//@M[2'X_L0\SN@]B9-DQF,(V
M@D/-`^HO?SF<2M+_1'$U^X56Y2"\?M)$X^$304@="H5LD;\W[$;D4^FTJ*&7
MM]95$Q)J[K0XWW^!E(L<]KE4]&2;V.#"3K,W8ECE1,PY[I21(I(^N8##<)O&
M1O$.T%!9('--N(,&Y5WS2LA\AB_10A96N&*AYW)<@M1ZP8YTJTJP)>G\"5OT
MD-*PLN\V&C7G="RX(ZYHO.;I5/(3_2:F[+&\<L%U7`24.(=6=A&@$F6X;X3I
MX3QS92MA=B/)*?*QO!$S-LN/F6_A2P]8XLM^-WTXVM1W+/)G,-(D#/')NMNG
MH7)</E-G/9*!C0'3TC:E/D-X((G.M,3!R4'@",P;K0[<U5LE($.!-E'B@T'>
M>4?IO(#B@FY2C-IM*#FJVTW[GPMBW%KL?^CHY=!;I#''P<)CVTKOJ69WV#L7
M[DLG=\%5/(#%*!#L,PS%RGCI'H@5<(%N;1/_6V0?<"G.+BP8_Y/?28#VK*C@
M'XR#*;D/$CS`O/"K/[TY^*]N\[O[ON*-7OW)O:]M6NF+T"E]XGZ5VI@^>\<'
MC*=9XEKU5>][T<Y)A,PK"R,W/P\!UIQRLVH4=F.0"2',BWJN\!`-325G^B(7
MV]YXR&YT3X@;'-^CGW\K_(C&7!V1J"C^-(V625K)2[_Y21Q.Z4F*%N+1?VWL
M!GWI&Y_K3WJMHW].Q3.#EI:21J=5AXXUG/C=Z;R2`H+&U7O!1HL%-^[4M,+\
MQM).2("@O7!\3VC#3"\W1,&A<'"HFQB_9*&=!M:B7I\#11I:&NTJA#@[=>[K
MU]_#Z`WWNW&UB"`N?UU(H&M3U]VX>8>X[;*X.QQ<;9,0,7R(H'<^\67LCQGG
MJ5(QOY>Q->@^CA^0]=P_HR;?A\R)Z"I*0DR458$2O5N?T1$G-!0^>X$?E5$V
MO]R\(B`:_7"C`N3T,TW408M%>ZFW3S#&W6&I\T([\<2#<>DR.XWE8WB=C>!U
M0#?M?3:XKJ$_!\%X.\V+Z:;HID0&'B/PYG)5]9<!#53T9/4SE^)"\`$0#U@8
MH:."J<[BP\I<X@:((M/IN?.JDL+<0*;2=F9R;B..-@YH[[4/LK`>USI3A>%0
MX"TMD16%KTOH=Q1@<R*2YMB9>S(68A!@,SH@*7+.B].EY7W4?,@&'1C&&C1?
M8U/"TUHEJIJ=':4)!B%7B2!R2(A^YPPMB?UE)VX3KI^)LM,SL3M%?6!67#9>
M@P!Y*?6VJ-3@SC%=]+$VJYWKB$:L0V(>1N,[VJNXD7?2\Q)&I,[.U^K@A@"Q
M0.2A!'V[5XP/LN$WX,N8<W@#`O>"F^J</VOLJA==-3N3.X"5;Q$[ZO(6N`-?
MC'8BI+Y_S]$$I&.W]L&#<]=.QFG$K-<OT!A>UJVA(SG70$`;7;:!#01C0_KO
MC3O2$$&DMK][HDK>("`NJ.J<>D=LW\5="=UFP6P*2T4H?^0@)D'1]]EATF=0
MN5DG\4':[9YV<0=H,7?2^.`XW!KZF[0KJN`W15EC'^$[=]VTX4*]LPL?WL_'
M>!9T@5H#G./F#RS4G'M/F7<6!\5"+9`X!-=37&C?H'>X@^<K(AALFRKK%>=F
M'&6VJ&DTJO4EE(CC-,&/###S#/;L"RXLD:B-4'%FH2:<%)0,%>3/4.,4+YR;
MY*NX#YUKR.QMMB+'N])#P>AJHJ`S)K>[6I(C>!O:&4+W"4>E;6##8Z]68@)(
MFY.I;L0-6H-A>:`(N3Y<IYYG1SG0PS='E*C!E)/!%*=C&4\0TN#A2@<>V(DU
MX$$1QHPT+1_4?(PI1LZ!%.BO8$).B:99HJ+]##8TW#+YQH<1.VNU*T2<ETBE
MU]##^H@A<O^NW#7]D?XU#;A;:Z51LH17CG7Z?#Q6$_,RR8ET)6C]B/',:YF9
M74\<$9V7C\%C;ZS=LALL!&I)==;2.</S.%$DQ+$$)LQ6064;"5"=RTRC0`QJ
M>:GGB=M9JR.@[R15"XC/X@:BIM2>?[:1#L-I;:F)[WV1^I$F(NS*Z-KER77M
M4BSRK)-CLQHF!TJ&O7(,9I&:]0>==<8Q*F+7.R4(B&CMU8:N%OQ[N,1+,6F7
M=2LQMLZPXIJV?<G4F_Z>^'B(-%+.^-L@T3>NR+_C8AJ)XX61=4&#$`5Q83`Q
M^JK16[-3<NE!>U,A[#&8F9("TDN+L+7.[!C'./:RX@ZSP7+`?,+WM&MTEBC'
M3B(;('XEB73QPF(4*]!OD;,%4UM["*Y/FTG7$8I+-(ZFSXE#0'HS)(6#(W]L
M0"U!60T.FDBA./2]()1REU`8IAP#PB'4X[#9PA"H3,TN24O#9O>G?2S3>SIS
MQT3U!)F>')/CCY'9=.0AE:7?5ZN2._4U(=-*,U/"\N/*HI5)2A%.M5"VUG:4
MB"!Z^*5*54)U7'\U`EU9+%6D,`2FN%9=Z-+AW+2M")K2<")NMQ!AC1IA?0?:
MF):%+2`EHPKUI!ED[&'"!(;M1_G1A;(<>3-L<QFJ?3EIP7'/S]@QJY*NKX(5
MOZ6O@`R-M\L\U0GS>-+)O9,=\^D!(APUS#R>@4W+4>)GW*_X0B*`X]NK]$T"
M097*<.\?CN;Y2*?UDVWFHC[L1[DJXGIM:E=?U>7$NJ"7N%]9G&#ID85#&01?
MD1O!5A)?]TPR6+DGI49?P[W05WQX&$(#>B7F6TSI(@.SH,`<R=)2ZWU:OGB>
MJQ?%Q\,161([4NR%1/=9%/+1AG-!DZY"V@:''^0J2UR_>"69H<+@Q/G:#AV/
M*JBZ-%6]:3`(N[5SN)3;X'%[<E^',NTME$G7:".=8%C$YJZ3$7)"O%)/)AWD
MA'-.15*)PADA[N1EJI)PW>Y"HB+8U^!V)/1=Z6[G($O7!\Z2HMTX)G$LMYE\
MAB:]%><F)XZH1.9A<Y:`4\V4AWJMQ(15-G3^^MI\<AFN6)+&D?*8:H!EQ
MC,8">7T?!XZ1Y+!GUA<J;1F)U/D<\2K.#>2V,61TD38),"%_4#Q%;&R,[K3K
MHRG)4.5(U</,M^^>24\R@^TI8/.HHXA:J$/X"5/BP'MC:ZO<?"XI@#[E))M)
M-$#`I>.WMS"2X<XYJZN/>W^R^X#FU-DCC8().8!"[6FIB-RZ*J4IAL3`S\J"
MPZ\TL903'#G>H^Q"#A7ZF\Q((N0LJ%KZLFJGK@6KN@B&$:(JTFC?[9`\R-2R
M&*8\L[+7!DKK*TFG#6EHHTGU)P&L-PINEWGR]G)V,%%IQ7:9?LUMI`_GFJLJ
MF2]H@1"'.=['1X;\:G*:(=W#8NZ;8\AG2,SRAC9?(_'@Y'H$]-2;(]K^\>:H
M][.8J.4I&O\-F<U+3961E$`?_"?Y9U!+H%%)BQ5DB9^*VU1"P9U&!Z&'D5HF
MQ4#EPG)7R`@XFHL8@)/T[D0\,),,5#9U,_VLOK&\^?OA-0#-4R%9E0(#8F`<
M>%8#'">6*VUOX[(E];`W,.@=6Z?1J[NN.;6>I0M6[[U)*\7F%%^SGR<J'>%M
M/-K)XOVB;+B.)QH[W48=L#/?]M[XL$G=HU3.ZFQ8<NR$'1R8]G"]/$S-596H
M4C!'P,JI=53LF!P<+A1V=7DP$J\KZP`#8%M5S/2=K3!;<0@J&.:US[>2W)O`
MIWV/1]S/$&7%?,BWYQYXIX6;@OK[3@;!E#@5_"K$Y)%TD40V7/TX!#PZ':-$
M8\*0:C+HL3QA)<*EER(*DSL:057-I=S`EY+^[H8-C55#+SNDT$;=U+>(I=#P
M,Y$S?4X4O"O:?H8W9>(^WT@?\(EBN4M^"G&,<$/VK8\Z)E1;J/.^RZ5`3YQD
M)58%'A5F(&G+&>&C(Z#<$D74:1^4'+5I_]%JK9X;@5!H>AXU-D\Y?UR&0P5B
MS723^()%5!/)=^F"99Q)Z@S!*[@?))O84!TH7]#_D;(YFT'I"U;9N-4QK!)^
M[=RLPDL.F^7\[I#=MM,GSM9VM_\)/PFU7>^WL."*F<(-AQ"O_4]2YLBMP^1.
M'"@V5A<5M^=(&DH(.>NK`J))N7=R(5L2#*1XA/6X4,$0F`1^P=(>BQ@$;UCY
MI6$7M``IT=-8_=#$43JD6_6Y.Q)IB<GE7.9S5"$`$J4[9;QTI7'%9H(@)'`S
MS=0J$;(Z/5$#,](GLT\U!9\JBQD9)5+^#VU+DK_O;8*B%P[H',64*DKK)0I%
M724N2>*L1<Q.A#V.8S*AWE&NW(LUK'1V)UPB3Q%.+E^)7Y1+'^&O@5=5'>(V
M:<GZMEPTSJ:2+&H_K"S.)5).(N.+=,V.E\(4RIP].@\W/GW!\U50A;//SR6!
MFN\R!LYA,*5A=VBZ3#\IV9*I7&B7P$#CNKR(DD[C6L0:-KT'[!ESPW[E*E76
MS3VE$%*O[/$XJO_[-Z"\8P,,ZU:*KL5:#`"@>9E1=PXGUKG?B.="..$\H<<D
MK^>5-D%'H`(W`2)1NZ[V&]8_NFU4M5',A<X8QIVEB,P@AT6(KSJ='#/2%L61
M:I^*:33X=$%$P$Y)@(/;^X)ER%OWK%VWO7CZCY^A9&L^G_8WZ<-4;'N!JD9.
M2<`6GCR)QSUXBS=>)]FD=-5WW(Z-)M2&M#XI7-E*_W084PG"?W`/)>S='=\]
M=O-49=+R&CR[;L2'F#>6$,G"*PX'*8X#%U+)O0?0OW>[U46W:/]#8G9\9-NT
M6<^JN0.4&_N2WIYV'"X1)>>W(;&%E\4:1XPK*JHMVOBK>5V6UF=[W],3S+$H
M',`&4D_?Y>L0QZ%-X**"!*=KH4K?S;A?#B*'APM-KN]E:&UT42\O:)Q#8J[_
ME);MCT?FN"V0`'B)-R_<>Y<\TL7#X5[NJ=+[^&/+=[5_#WK]DO0_W\'1Q\C:
M16B.P+9@9_!S$E`(#0]U8Z+<TZ2D6+1_*;3===O'EY>[W6Y:M/5TOKZ$K0#_
M;\K55A/LT)N%/$XZP-#G%B:TD5VKT01/+WW;`.>AX$6YS6;Q9O&J\7L;\SZD
M%#D;CYY)"7+\R<"IL,[A^A<??\F%U)"1_V54+X%OM:@KP=OJDJ[5`8^:(?V&
MF\W0;>D*NO%O\W7WDQ,V%46^9R;U-:)(LFL7K$*KZTEL*DFIR.D42'Q^S5;5
M[$<2,==NA)`</E_G!9C6=TVQ0K)R**9,NP.E^EM?:^'D6=[0_X)7H8+WQ'R3
M-V7VU#;-?F)^*.8W1?:TJ7?T0+I(?46/BQ:]>Z_7]88V_+RE!4_,54FK^:-=
M+AM+'_[Q+_^[;E;9-Q6#=V+>$&HV['K_)J?';Z&;O2)MC!X-H$'?)G=]8KY:
M-X6\\&Y;$,AILN<DTJ'(T3J[QKLW^2ZG.=9$6`EF^;ZLZ9WORZ:XR7XHZ"UZ
MEO=E]D/]UX[>BR&GG=T"-,Q5$-%.PTQ`<=5N.1&<AK1EBP:9ULX(,']`9!/=
M@*<D]`*B3U'`YRM:W:(%%#?8RE<]:;%[!=NSOD)^U<2\(KCD1)9>V&;5M_CV
M.3;Q@L3Q&6V4AH)JW"RRKW,P&(*5`#S[FJ3<>C<Q7UL"NR7LL;;:Y8MP2L2T
M.D#N*9S&-4F$?ZB;"K"EXZ3;18=>83FRL6]RB&A;_T^+-EL$LXGYL:YNZCK[
MIMC((6(MW]`=I:6]K6<D#'Y3-#?K?(.-V;OLF_J&MC!#>C0:W:*0/X'@:3W#
MX=.I3LRWMB*-]55/4U18WW=T.1&-E+>$^#=N!6_7*.QA7N7-3?:NJ&YH7U?5
MHK&[[)I4*1H*>W]6]RLZU9Y1QMJ+'_,B^[/MX:(<'O(3'"TWOGLRVUOS_P#Y
'0U,+F>D``!H*
`
end
SHAR_EOF
echo 'gunzipping file tds.texi' &&
gzip -d < _shargzi.tmp > 'tds.texi' && rm -f _shargzi.tmp &&
$shar_touch -am 0114181996 'tds.texi' &&
chmod 0644 'tds.texi' ||
echo 'restore of tds.texi failed'
shar_count="`wc -c < 'tds.texi'`"
test 59801 -eq "$shar_count" ||
echo "tds.texi: original size 59801, current size $shar_count"
fi
exit 0
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 Jan 1996 07:05:41 CST
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 Jan 1996 14:05:20 +0100
Message-ID: <199601171305.OAA18198@spice.iti.informatik.th-darmstadt.de>
From: Joachim Schrod <jschrod@acm.org>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Texinfo/Info/HTML version of 0.999
References: <9601150923.AA02045@macbeth.uni-duesseldorf.de>
>>>>> "UV" == Ulrik Vieth <vieth@thphy.uni-duesseldorf.de> writes:
UV> I'll upload it to ftp.dante.de to
UV> incoming/tds-html.tar.gz anyway, but it won't get installed anywhere,
UV> before you give me the go-ahead and one of the CTAN people here takes
UV> care of it. (Joachim?)
It's there. If there's general agreement that we shall make availabe
this version, I'll add it to the TDS area. (I'm in favor, btw.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: jschrod@acm.org
Roedermark, Germany
Net & publication consultant
================================================================================
From owner-twg-tds@shsu.edu Fri, 19 Jan 1996 06:31:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 19 Jan 1996 13:29:26 +0100
Message-ID: <9601191229.AA01101@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: Texinfo/Info/HTML version of 0.999
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Joachim:
> It's there. If there's general agreement that we shall make availabe
> this version, I'll add it to the TDS area. (I'm in favor, btw.)
Well, it appears that so far noone objected to making it available.
However, it could also be that noone really cares about it.
I'd suggest to wait for Karl to comment on it when he's back from
vacation. As he's actively involved in Texinfo maintenance he's
probably the most competent in Texinfo of all of us. Besides he
also wanted to write some TDS documentation for the Web2C manual
(which is in Texinfo format anyway), so he might want to make use
of it or else rewrite it in a way he sees fit.
In any case, there's no need to hurry to get the Texinfo and HTML
versions out, since it's several months behind the LaTeX version
anyway.
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Mon, 22 Jan 1996 16:01:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 22 Jan 1996 17:00:08 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199601222200.AA29405@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: Texinfo/Info/HTML version of 0.999
at hand-converting the 0.999 LaTeX file to Texinfo, which basically
How about a sed/awk script to replace the query-replace-regexp's? Then
maybe we could do it automatically.
Texinfo experience. So if any Texinfo guru wants to look it over to
improve on it, you're welcome. If not, I might just as well put it
I'll look at it, but I'm sure it's fine. Let's go ahead and distribute
it. At least it's something. Thanks for doing the work.
================================================================================
From owner-twg-tds@shsu.edu Tue, 23 Jan 1996 03:57:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 23 Jan 1996 10:55:20 +0100
Message-ID: <9601230955.AA01374@attila.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: Texinfo/Info/HTML version of 0.999
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Karl wrote:
> at hand-converting the 0.999 LaTeX file to Texinfo, which basically
> How about a sed/awk script to replace the query-replace-regexp's? Then
> maybe we could do it automatically.
Well, I thought of that too, but there were some complications which I
tackled in the hand-conversion. For instance, there was one case where
\path|...| was abused for something that was not really a file argument
(\path|\dump|-able), so I converted it to @code rather than @file.
Then there were some inconsistencies in the use of \literal and \path.
My first idea was to translate \literal to @samp and \path to @file,
but I later found it preferable to translate both to @file in the first
path and later translate @file to @samp in some contexts like @item.
However, this was probably influenced by my personal HTML style sheet
that turns @samp into to bold typewriter, which of course works best
for description items. Still another complication was that I often had
to translate \replaceable into @file{@var{...}} rather than just @var
to get the quotes around the file names consistent.
Taking all this into account, it would of course be nicer to have some
automatic conversion script, but getting it to produce good quality
would probably have been more work than doing a hand-conversion once.
Cheers, Ulrik.
P.S. Karl: I believe it's deliberate that the /incoming directory on
ftp.dante.de is not readable for anybody, but I don't know the reasons
for this policy. I hope Joachim will install it now in the /tds tree
to make it generally available.
================================================================================
From owner-twg-tds@shsu.edu Tue, 23 Jan 1996 07:51:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 23 Jan 1996 08:50:21 -0500
Message-ID: <199601231350.AA13360@terminus.cs.umb.edu>
From: kb@terminus.cs.umb.edu
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Texinfo/Info/HTML version of 0.999
automatic conversion script, but getting it to produce good quality
would probably have been more work than doing a hand-conversion once.
But we're going to have to do the conversion more than once.
Whatever. I'll try to come up with something, I guess.
P.S. Karl: I believe it's deliberate that the /incoming directory on
ftp.dante.de is not readable for anybody, but I don't know the reasons
It's so people can't use the incoming directory for their own purposes,
i.e., fill up the disk. Sad but necessary (my incoming directory is
unreadable, too.)
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Jan 1996 02:32:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 24 Jan 1996 09:31:29 +0100
Message-ID: <9601240831.AA06497@caligula.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: Texinfo/Info/HTML version of 0.999
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
> automatic conversion script, but getting it to produce good quality
> would probably have been more work than doing a hand-conversion once.
> But we're going to have to do the conversion more than once.
> Whatever. I'll try to come up with something, I guess.
Well, I had another try. I did it in elisp, which seemed to be a more
suitable choice for producing Texinfo. Besides, it might also be more
platform-independent than sed/awk/grep. The following script should
do the conversion of everything except for the header and trailer.
It's still a little rough, though. It still misses some commentary
and doc strings. And there may be some areas that need improving.
Cheers, Ulrik.
P.S. It should be clear that this is not a general LaTeX to Texinfo
converter despite the name `ltx2texi' to fit into 8+3 file systems.
;;; ltx2texi.el --- convert LaTeX to Texinfo
;; Copyright (C) 1996
;; Author: Ulrik Vieth <vieth@thphy.uni-duesseldorf.de>
;; Keywords:
;; Version:
;;; This file is *not* part of GNU Emacs.
;;; Commentary:
;;; Code:
(defvar ltx2texi-source-file "tds.tex")
(defvar ltx2texi-target-file "tds.texi")
(defvar ltx2texi-logos-alist
'(("\\TeX{}" . "TeX") ; no need for "@TeX{}" in Info or HTML
("\\MF{}" . "METAFONT")
("\\MP{}" . "MetaPost")
("\\BibTeX{}" . "BibTeX")
("{\\TeX}" . "TeX")
("{\\LaTeX}" . "LaTeX")
("{\\LaTeXe}" . "LaTeX2e")
("{\\AMSTeX}" . "AMS-TeX")
("{\\AmS}" . "AMS")
("{\\iniTeX}" . "INITEX")
("{\\iniMF}" . "INIMF")
("{\\iniMP}" . "INIMP")
("{\\PS}" . "PostScript")
("{\\copyright}" . "@copyright{}")
))
;;; utility functions:
(defun ltx2texi-string-replace (x-string x-replace)
"Searches for occurences of X-STRING, replacing them by X-REPLACE."
(save-excursion
(while (search-forward x-string nil t)
(replace-match x-replace t t)))) ; use fixed case!
(defun ltx2texi-regexp-replace (x-regexp x-replace)
"Searches for occurences of X-REGEXP, replacing them by X-REPLACE."
(save-excursion
(while (re-search-forward x-regexp nil t)
(replace-match x-replace nil nil))))
(defun ltx2texi-alist-replace (x-regexp x-alist)
"Searches for ocurrences of X-REGEXP, replacing them using X-ALIST.
If no match is found in X-ALIST, leaves the original text unchanged."
(save-excursion
(let (x-match
x-replace)
(while (re-search-forward x-regexp nil t)
(setq x-match (match-string 1))
(setq x-replace
(or (cdr (assoc x-match x-alist)) x-match))
(replace-match x-replace t t))))) ; use fixed case!
;;;
(defun ltx2texi-convert ()
(interactive)
(let (target-buffer)
; (setq target-buffer (get-buffer-create ltx2texi-target-file))
; (set-buffer target-buffer)
; (erase-buffer)
; (insert-file-contents-literally ltx2texi-source-file)
(untabify (point-min) (point-max))
(goto-char (point-min))
;; literal `@' -- must come before anything else!
(ltx2texi-regexp-replace "\\([^\\\\]\\)@" "\\1@@")
;; fancy spacing -- should come early before there are too many `@'
(ltx2texi-regexp-replace "\\\\@\\([.?!]\\)" "@\\1")
(ltx2texi-regexp-replace "\\.\\\\\\([ \n]+\\)" ".@:\\1")
(ltx2texi-regexp-replace "\\\\\\([ \n]+\\)" "\\1")
(ltx2texi-regexp-replace "\\\\,\\(dpi\\|pt\\)" "@dmn{\\1}")
;; special TeX characters that needn't be quoted in Texinfo:
(ltx2texi-string-replace "\\_" "_")
(ltx2texi-string-replace "\\&" "&")
(ltx2texi-string-replace "\\%" "%")
(ltx2texi-string-replace "\\pm" "+-")
(ltx2texi-string-replace "$" "") ; avoid using @math{...}
(ltx2texi-string-replace "~" " ") ; maybe avoid using @w{...}
(ltx2texi-string-replace "\\slash " "/")
;; fancy TeX logos -- these are used in arguments of sections
(ltx2texi-alist-replace "\\(\\\\[A-Za-z]+{}\\)" ltx2texi-logos-alist)
(ltx2texi-alist-replace "\\({\\\\[^}]+}\\)" ltx2texi-logos-alist)
;; acronyms -- these are also used in arguments of sections
;; there's no need to use @sc markup, just upcase them.
(save-excursion
(while (re-search-forward "\\\\abbr{\\([^}]+\\)}" nil t)
(replace-match (upcase (match-string 1)) nil t)))
;; applications -- since they are now shown in the default font
;; there's no need to use @r markup either.
(ltx2texi-regexp-replace "\\\\application{\\([^}]+\\)}" "\\1")
;; sectioning commands:
;;
;; first do @chapter and @appendix by narrowing
(save-excursion
(save-restriction
(narrow-to-region
(point-min) (search-forward "\\appendix" nil t))
(goto-char (point-min))
(ltx2texi-regexp-replace
"\\\\section{\\([^}]+\\)}[ ]*" "@node \\1\n@chapter \\1\n")
))
(save-excursion
(save-restriction
(narrow-to-region
(search-forward "\\appendix" nil t) (point-max))
(ltx2texi-regexp-replace
"\\\\section{\\([^}]+\\)}[ ]*" "@node \\1\n@appendix \\1\n")
))
;; @section and @subsection are easy now
(ltx2texi-regexp-replace
"\\\\subsection{\\([^}]+\\)}[ ]*" "@node \\1\n@section \\1\n")
(ltx2texi-regexp-replace
"\\\\subsubsection{\\([^}]+\\)}[ ]*" "@node \\1\n@subsection \\1\n")
;; now we no longer need \apendix as a marker
(ltx2texi-regexp-replace "\\\\appendix[ ]*\n" "")
(ltx2texi-regexp-replace "%?\\\\newpage[ ]*\n" "")
;; \labels are redundant since we have @nodes
(ltx2texi-regexp-replace "\\\\label{sec:\\([^}]+\\)}[ ]*\n" "")
(ltx2texi-regexp-replace "\\\\ref{sec:\\([^}]+\\)}" "@ref{\\1}")
;; this might be redundant in Info as well -- not quite sure!
;; (ltx2texi-regexp-replace "\\(Appendix\\|Section\\)[~ ]" "")
;; now we can do the remaining instances of literal `~'
;; unfortunately this will get lost in the HTML conversion
;; because or   are not yet standard HTML tags
(ltx2texi-regexp-replace
"\\([A-Za-z]+\\)~\\([A-Za-z]+\\)" "@w{\\1 \\2}")
;; various tag markup:
;;
;; \emphasis:
(ltx2texi-string-replace "\\emphasis" "@emph")
;; \citetitle -- no need to match and replace the argument,
;; otherwise we might run into trouble with @w{Volume E}
(ltx2texi-string-replace "\\citetitle" "@cite")
;; special tags:
(ltx2texi-string-replace "\\texmf{}" "@file{texmf}")
(ltx2texi-string-replace "\\CTAN:" "@file{@var{CTAN}:}")
;; \\systemitem -- a silly tag, used exactly once!
(ltx2texi-regexp-replace
"\\\\systemitem{\\([^}]+\\)}{\\([^}]+\\)}" "@file{\\2}")
;; \path -- here we can't avoid shuffling the argument
(ltx2texi-regexp-replace "\\\\path|\\([^|]+\\)|" "@file{\\1}")
;; \literal -- we simply use the same markup as \path
;; since the distinction isn't very clear
(ltx2texi-string-replace "\\literal" "@file")
;; \replaceable -- within ttdisplay we can simply use @var
(save-excursion
(while (search-forward "\\begin{ttdisplay}" nil t)
(save-restriction
(narrow-to-region
(point) (search-forward "\\end{ttdisplay}" nil t))
(goto-char (point-min))
(ltx2texi-string-replace "\\replaceable" "@var")
)))
;; ... but otherwise we have to use @file{@var{...}}
;; to get the quotation marks consistent
(ltx2texi-regexp-replace
"\\\\replaceable{\\([^}]+\\)}" "@file{@var{\\1}}")
;; eliminate redundant quotation marks:
(ltx2texi-regexp-replace "``\\(@file{[^}]+}\\)''" "\\1")
(ltx2texi-regexp-replace "`\\(@file{[^}]+}\\)'" "\\1")
;; combine multiple @file{}s in one line:
(ltx2texi-regexp-replace
"@file{\\(.*\\)}@file{\\(.*\\)}@file{\\(.*\\)}" "@file{\\1\\2\\3}")
(ltx2texi-regexp-replace
"@file{\\(.*\\)}@file{\\(.*\\)}" "@file{\\1\\2}")
;; environments:
;;
;; ttdisplay and tdsSummary -- @example is good for both
(ltx2texi-string-replace "\\begin{ttdisplay}" "\n@example")
(ltx2texi-string-replace "\\end{ttdisplay}" "@end example\n")
(ltx2texi-string-replace "\\begin{tdsSummary}" "\n@example")
(ltx2texi-string-replace "\\end{tdsSummary}" "@end example")
;; enumerate:
(ltx2texi-string-replace "\\begin{enumerate}" "@enumerate")
(ltx2texi-string-replace "\\end{enumerate}" "@end @enumerate")
;; itemize -- always use @itemize @bullet, since it's difficult
;; to determine when to use @itemize @minus for inner levels
(ltx2texi-regexp-replace
"\\\\begin{\\(description\\|itemize\\)}" "@itemize @bullet")
(ltx2texi-regexp-replace
"\\\\end{\\(description\\|itemize\\)}" "@end @itemize")
;; in case of itemize-squueze add extra newlines
(ltx2texi-regexp-replace
"\\\\begin{\\(description\\|itemize\\)-squeeze}" "\n@itemize @bullet")
(ltx2texi-regexp-replace
"\\\\end{\\(description\\|itemize\\)-squeeze}" "@end @itemize")
;; description items -- add extra newlines where appropriate
(ltx2texi-regexp-replace
"\\\\item\\[\\([^]]+\\)\\][ ]*\n" "@item \\1\n")
(ltx2texi-regexp-replace
"\\\\item\\[\\([^]]+\\)\\][ ]*" "@item \\1\n")
;; normal items -- nothing special
(ltx2texi-string-replace "\\item" "@item")
;; replace @file by @samp after @item and add extra newlines
(ltx2texi-string-replace
"@item @file" "@item @samp")
(ltx2texi-regexp-replace
"@item @samp\\([^,\n]*\\),[ ]*" "@item @samp\\1,\n")
))
================================================================================
From owner-twg-tds@shsu.edu Wed, 24 Jan 1996 11:10:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 24 Jan 1996 18:09:52 +0100
Message-ID: <199601241709.SAA11745@spelunke.iti.informatik.th-darmstadt.de>
From: Joachim Schrod <jschrod@acm.org>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Texinfo/Info/HTML version of 0.999
References: <9601230955.AA01374@attila.uni-duesseldorf.de>
>>>>> "UV" == Ulrik Vieth <vieth@thphy.uni-duesseldorf.de> writes:
UV> I hope Joachim will install it now in the /tds tree to make it
UV> generally available.
I have split it, in tds-html.tar.gz and tds-info.tar.gz. It will be
copied to the CTAN tds tree tonight. It will _not_ be in
tds/draft-standard/, but in tds/misc/. The README file has been
changed to point to the new files.
That's because draft-standard/ is a direct mirror of Karl's machine.
mirror would discard my new files RSN. If somebody thinks one should
introduce a special directory for these two files (draft-aux?) one
should raise this issue. Best to do it until 22:00 CET (16:00 EST)
tonight, as I'm not so often at the University any more.
Cheers,
Joachim
PS:
UV> P.S. Karl: I believe it's deliberate that the /incoming directory on
UV> ftp.dante.de is not readable for anybody, but I don't know the reasons
UV> for this policy.
Obviously you hadn't problems with the administration of a large ftp
site yet. At our site, we had lots of problems with illegal material
that can bring an ftp administrator into trouble (ranging from stolen
software to kids porn). Restricting access to /incoming was the only
possibility left.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: ftpadmin@ftp.th-darmstadt.de
ftp.th-darmstadt.de, Administration
================================================================================
From owner-twg-tds@shsu.edu Mon, 29 Jan 1996 03:37:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 29 Jan 1996 10:36:05 +0100
Message-ID: <9601290936.AA09708@macbeth.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: ltx2texi.el (was Texinfo/Info/HTML version)
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Once again, here's an improved version of ltx2texi.el to convert
the LaTeX version of the TDS draft into Texinfo (and from there
to Info and HTML). [One intermediate version went only to Karl
since I didn't want to bother you all.]
This version now does about 98% of the conversion automatically
(including the header, nodes and menus). In the end, it leaves
you in a buffer containing the converted file for further editing
if necessary. You'll still have to save the file manually, but
that's probably better than always trying to save it, no matter
want may have gone wrong in the conversion process.
Since it is customary for Elisp files to follow a certain template
for header lines, this file now carries a copyright notice (unlike
tdsguide.cls). I've inserted `TeX Users Group' as the copyright
holder, just as it says in TDS draft. I hope that'll be all right.
The `Maintainer:' line now says `TWG-TDS', which is supposed to
mean ``whoever is currently editing the TDS draft and nees to hack
the converter to fix some problem or to achieve a certain effect''.
I don't intend to do any more about it. I'll leave it to others
now to improve it or develop it further, if needed.
Cheers, Ulrik.
P.S. Joachim: If you like, you might put it up in tds/misc as well.
Either simply as ltx2texi.el in tds/misc, or else in a subdirectory
ltx2texi-0.5 if you prefer to record it by version number like
you did for tdsguide.cls. Any earlier versions aren't worth
archiving. I haven't kept them myself as I was developping it.
;;; ltx2texi.el --- convert LaTeX to Texinfo (and Info and HTML)
;; Copyright (C) 1996 TeX Users Group
;; Author: Ulrik Vieth <vieth@thphy.uni-duesseldorf.de>
;; Maintainer: TWG-TDS
;; Version: 0.5
;; Keywords: TDS, LaTeX, Texinfo, Info, HTML, tex, maint
;;; This file is *not* part of GNU Emacs.
;;; Commentary:
;; Description:
;;
;; This file provides a limited LaTeX-to-Texinfo conversion function
;; `ltx2texi-convert' which is primarily intended to convert the LaTeX
;; source of the TDS draft document `tds.tex' that uses a couple of
;; special markup tags defined in the doucment class `tdsguide.cls'.
;; It is definitely *not* suitable to be used as a general-purpose
;; LaTeX-to-TeXinfo converter and is not intended to be used as such.
;;
;; Usage:
;;
;; 0. load or autoload this file, e.g: (load-library "ltx2texi")
;;
;; 1. go to a directory containing `tds.tex', e.g. in dired mode
;;
;; 2. run M-x ltx2texi-convert -- this does all the conversion and
;; leaves you in a buffer `tds.texi' containing the converted file
;;
;; 3. edit the buffer if necessary and save it -- you will be asked
;; for a file name (which should be `tds.texi', of course)
;;
;; 4. run M-x makeinfo-buffer or invoke makeinfo and/or texi2html
;; from the shell -- don't try texi2dvi, it may work all right,
;; but it's not recommended since it will only cause confusion
;; with the DVI file created from the original LaTeX source!
;;
;; Bugs:
;;
;; * whitespace (esp. blank lines) before and after environments
;; will be inconsistent (should be fixed in the LaTeX version!)
;;
;; * whitespace (esp. indentation) in tdsSummary environments
;; will be inconsistent (should be fixed in the LaTeX version!)
;;
;; * labels are references are assumed to coincide with names
;; of @nodes -- this is not always true, e.g. for MF vs. \MF{}
;;
;; * the last comma in the list of contributors should be a period
;;
;; * the list of contributors should be handled in a better way
;; (currently: LaTeX tabbing -> @quotation -> HTML <blockquote>)
;;
;; * the contents of the top node may get lost in the texi2html
;; conversion under some circumstances, or else it may end up
;; in the wrong split file -- this seems to be a texi2html bug
;;
;; History:
;;
;; v 0.0 -- 1996/01/23 UV created
;; v 0.1 -- 1996/01/24 UV first rough version, posted to twg-tds
;; v 0.2 -- 1996/01/24 UV added some commentary and doc strings
;; v 0.3 -- 1996/01/25 UV modularized code, handle header and trailer,
;; call texinfo routines for @nodes and @menus
;; v 0.4 -- 1996/01/27 UV slightly touched-up and some doc fixes,
;; improved handling of legalnotice header
;; v 0.5 -- 1996/01/28 UV more documentation added, code freeze
;;
;;; Code:
(require 'texinfo) ; needed to update @nodes and @menus
;; file name variables
(defvar ltx2texi-source-file "tds.tex"
"File name of TDS LaTeX source to be converted.")
(defvar ltx2texi-target-file "tds.texi"
"File name of TDS Texinfo source to be created.")
(defvar ltx2texi-filename "tds.info"
"File name of Info file to be inserted in Texinfo header.")
;; translation tables
(defvar ltx2texi-logos-alist
'(("\\TeX{}" . "TeX") ; no need to use "@TeX{}"
("{\\TeX}" . "TeX") ; when only doing Info
("{\\LaTeX}" . "LaTeX")
("{\\LaTeXe}" . "LaTeX2e")
("{\\AmS}" . "AMS")
("{\\AMSTeX}" . "AMS-TeX")
("\\MF{}" . "METAFONT")
("\\MP{}" . "MetaPost")
("\\BibTeX{}" . "BibTeX")
("{\\iniTeX}" . "INITEX")
("{\\iniMF}" . "INIMF")
("{\\iniMP}" . "INIMP")
("{\\PS}" . "PostScript")
("{\\copyright}" . "@copyright{}")
)
"List of TeX logos and their replacement text after conversion.")
(defvar ltx2texi-logos-regexp-1 "\\(\\\\[A-Za-z]+{}\\)"
"Regexp for TeX logos to be converted using `ltx2texi-logos-alist'.")
(defvar ltx2texi-logos-regexp-2 "\\({\\\\[^}]+}\\)"
"Regexp for TeX logos to be converted using `ltx2texi-logos-alist'.")
;;
(defvar ltx2texi-tags-alist
'(("\\emphasis" . "@emph")
("\\citetitle" . "@cite")
("\\literal" . "@file")
("\\replaceable" . "@var")
("\\command" . "@code") ; defined, but not used
;; ("\\application" . "@r") ; unnecessary, but ...
;; ("\\abbr" . "@sc") ; unnecessary, but ...
)
"List of markup tags and their replacement text after conversion.")
(defvar ltx2texi-tags-regexp "\\(\\\\[a-z]+\\)"
"Regexp for markup tags to be converted using `ltx2texi-tags-alist'.")
;;
(defvar ltx2texi-env-alist
'(("\\begin{ttdisplay}" . "@example")
("\\end{ttdisplay}" . "@end example")
("\\begin{tdsSummary}" . "@example")
("\\end{tdsSummary}" . "@end example")
("\\begin{enumerate}" . "@enumerate")
("\\end{enumerate}" . "@end enumerate")
("\\begin{enumerate-squeeze}" . "@enumerate")
("\\end{enumerate-squeeze}" . "@end enumerate")
("\\begin{itemize}" . "@itemize @bullet")
("\\end{itemize}" . "@end itemize")
("\\begin{itemize-squeeze}" . "@itemize @bullet")
("\\end{itemize-squeeze}" . "@end itemize")
("\\begin{description}" . "@table @samp")
("\\end{description}" . "@end table")
("\\begin{description-squeeze}" . "@table @samp")
("\\end{description-squeeze}" . "@end table")
("\\begin{legalnotice}" . "@titlepage") ; special hack
("\\end{legalnotice}" . "@end titlepage")
("\\begin{tabbing}" . "@quotation") ; special hack
("\\end{tabbing}" . "@end quotation")
)
"List of environments and their replacement text after conversion.")
(defvar ltx2texi-env-regexp "\\(\\\\\\(begin\\|end\\){[^}]+}\\)"
"Regexp for environments to be converted using `ltx2texi-env-alist'.")
;;; some utility functions
(defun ltx2texi-string-replace (x-string x-replace)
"Searches for occurences of X-STRING, replacing them by X-REPLACE."
(save-excursion
(while (search-forward x-string nil t)
(replace-match x-replace t t)))) ; use fixed case!
(defun ltx2texi-regexp-replace (x-regexp x-replace)
"Searches for occurences of X-REGEXP, replacing them by X-REPLACE."
(save-excursion
(while (re-search-forward x-regexp nil t)
(replace-match x-replace t nil)))) ; use fixed case!
(defun ltx2texi-alist-replace (x-regexp x-alist)
"Searches for ocurrences of X-REGEXP, replacing them using X-ALIST.
If no match is found in X-ALIST, leaves the original text unchanged."
(save-excursion
(let (x-match
x-replace)
(while (re-search-forward x-regexp nil t)
(setq x-match (match-string 1))
(setq x-replace (or (cdr (assoc x-match x-alist)) x-match))
(replace-match x-replace t t))))) ; use fixed case!
;;; the main conversion function
(defun ltx2texi-convert ()
"Have a try at converting LaTeX to TeXinfo. Good luck!"
(interactive)
;; get a buffer to operate on and insert the LaTeX source
(set-buffer (get-buffer-create ltx2texi-target-file))
(erase-buffer)
(insert-file-contents-literally ltx2texi-source-file)
;; tab characters can mess up tds-summary envrionments,
;; so get rid of them as soon as possible
(untabify (point-min) (point-max))
(goto-char (point-min))
;; do the conversion steps for the text body
(ltx2texi-do-simple-tags) ; mostly general
(ltx2texi-do-fancy-logos) ; mostly specific to TDS
(ltx2texi-do-sectioning) ; mostly general
(ltx2texi-do-markup-tags) ; mostly specific to TDS
(ltx2texi-do-environments) ; partly specific to TDS
;; do the conversion for header and trailer
(ltx2texi-do-header) ; partly specific to TDS
(ltx2texi-do-trailer) ; partly specific to TDS
;; standard Texinfo functions
(texinfo-every-node-update)
(texinfo-all-menus-update)
(texinfo-master-menu nil)
;; all that's left to do is saving the buffer to a file
;; -- we simply select the buffer and leave saving it to
;; the user in case some manual intervention is needed
(switch-to-buffer ltx2texi-target-file)
)
;;; various steps of the conversion process
(defun ltx2texi-do-simple-tags ()
"First step of \\[ltx2texi-convert]. Not useable by itself."
;; literal `@' -- should come before anything else, since it's
;; the Texinfo control character.
(ltx2texi-regexp-replace "\\([^\\\\]\\)@" "\\1@@")
;; fancy spacing -- should come early before we have many `@'
;; "\@" -- space factor corrections before sentence end `.'
(ltx2texi-regexp-replace "\\\\@\\." "@.")
;; "\ " -- control space after `.' in the middle of sentences
(ltx2texi-regexp-replace "\\.\\\\\\([ \n]+\\)" ".@:\\1")
;; "\ " -- control space used otherwise
(ltx2texi-regexp-replace "\\\\\\([ \n]+\\)" "\\1")
;; "\," -- thin space used with dimensions like "dpi" or "pt"
(ltx2texi-regexp-replace "\\\\,\\([a-z]+\\)" "@dmn{\\1}")
;; special TeX characters that needn't be quoted in Texinfo:
(ltx2texi-string-replace "\\_" "_")
(ltx2texi-string-replace "\\&" "&")
(ltx2texi-string-replace "\\%" "%")
;; special TeX characters that we prefer to transliterate:
(ltx2texi-regexp-replace "\\\\slash[ ]*" "/")
;; we could translate $...$ into @math{...}, but why bother
;; when we can transliterate it easily?
(ltx2texi-string-replace "$" "")
(ltx2texi-string-replace "\\pm" "+-")
;; we could use @w{word1 word2} (this is handled elsewhere),
;; but why bother when it'll get lost in texi2html anyway?
(ltx2texi-string-replace "~" " ")
)
(defun ltx2texi-do-fancy-logos ()
"Second step of \\[ltx2texi-convert]. Not useable by itself."
;; fancy TeX logos -- these are used in arguments of sections,
;; so we have to do them early before doing sectioning commands.
(ltx2texi-alist-replace ltx2texi-logos-regexp-1 ltx2texi-logos-alist)
(ltx2texi-alist-replace ltx2texi-logos-regexp-2 ltx2texi-logos-alist)
;; acronyms -- these are also used in arguments of sections.
;; There's no need to use @sc markup, just upcase the argument.
(save-excursion
(while (re-search-forward "\\\\abbr{\\([^}]+\\)}" nil t)
(replace-match (upcase (match-string 1)) nil t)))
;; applications -- similar to acronyms, so done here as well.
;; There's no need to use @r markup either, it's the default!
(ltx2texi-regexp-replace "\\\\application{\\([^}]+\\)}" "\\1")
)
(defun ltx2texi-do-sectioning ()
"Third step of \\[ltx2texi-convert]. Not useable by itself."
;; first do @chapter and @appendix by narrowing
(save-excursion
(save-restriction
(narrow-to-region
(point-min) (search-forward "\\appendix" nil t))
(goto-char (point-min))
(ltx2texi-regexp-replace
"\\\\section{\\([^}]+\\)}[ ]*" "@node \\1\n@chapter \\1\n")
))
(save-excursion
(save-restriction
(narrow-to-region
(search-forward "\\appendix" nil t) (point-max))
(ltx2texi-regexp-replace
"\\\\section{\\([^}]+\\)}[ ]*" "@node \\1\n@appendix \\1\n")
))
;; @section and @subsection are just shifted a level up
(ltx2texi-regexp-replace
"\\\\subsection{\\([^}]+\\)}[ ]*" "@node \\1\n@section \\1\n")
(ltx2texi-regexp-replace
"\\\\subsubsection{\\([^}]+\\)}[ ]*" "@node \\1\n@subsection \\1\n")
;; now we no longer need \apendix as a marker
(ltx2texi-regexp-replace "\\\\appendix[ ]*\n" "")
;; \newpage can go as well
(ltx2texi-regexp-replace "%?\\\\newpage[ ]*\n" "")
;; \labels are redundant since we have @nodes
(ltx2texi-regexp-replace "\\\\label{sec:\\([^}]+\\)}[ ]*\n" "")
;; \refs now refer to @nodes instead of \labels
(ltx2texi-regexp-replace "\\\\ref{sec:\\([^}]+\\)}" "@ref{\\1}")
;; this might be redundant in Info as well -- not quite sure!
;; (ltx2texi-regexp-replace "\\(Appendix\\|Section\\)[~ ]" "")
)
(defun ltx2texi-do-markup-tags ()
"Fourth step of \\[ltx2texi-convert]. Not usable by itself."
;; special tags -- for \CTAN, we must used fixed-case replace!
(ltx2texi-string-replace "\\texmf{}" "@file{texmf}")
(ltx2texi-string-replace "\\CTAN:" "@file{@var{CTAN}:}")
;; convert simple tags without expanding their arguments:
;; \emphasis, \citetitle, \literal, \replaceable
(ltx2texi-alist-replace ltx2texi-tags-regexp ltx2texi-tags-alist)
;; \\systemitem -- a silly tag with an extra argument that
;; isn't printed. It is used exactly once!
(ltx2texi-regexp-replace
"\\\\systemitem{\\([^}]+\\)}{\\([^}]+\\)}" "@file{\\2}")
;; \path -- here we can't avoid shuffling the argument
(ltx2texi-regexp-replace "\\\\path|\\([^|]+\\)|" "@file{\\1}")
;; After turning \replaceable into @var above we now have to
;; turn @var{...} into @file{@var{...}} to get quotation marks
;; around file names consistent. (Read: those extra quotation
;; marks inserted automatically by makeinfo in the @file tag.)
;; For simplicity we first do the change everywhere and then
;; undo it again inside `ttdisplay' environments, where we
;; can leave @var by itself as @file isn't used there anyway.
(ltx2texi-regexp-replace "@var{\\([^}]+\\)}" "@file{@var{\\1}}")
(save-excursion
(while (search-forward "\\begin{ttdisplay}" nil t)
(save-restriction
(narrow-to-region
(point) (search-forward "\\end{ttdisplay}" nil t))
(goto-char (point-min))
(ltx2texi-regexp-replace "@file{@var{\\([^}]+\\)}}" "@var{\\1}")
)))
;; eliminate redundant quotation marks around @file
(ltx2texi-regexp-replace "``\\(@file{[^}]+}\\)''" "\\1")
(ltx2texi-regexp-replace "`\\(@file{[^}]+}\\)'" "\\1")
;; ... and combine multiple @file{}s in one line
(ltx2texi-regexp-replace
"@file{\\(.*\\)}@file{\\(.*\\)}@file{\\(.*\\)}" "@file{\\1\\2\\3}")
(ltx2texi-regexp-replace
"@file{\\(.*\\)}@file{\\(.*\\)}" "@file{\\1\\2}")
;; ... also simplify cases of nested @file{}s
(ltx2texi-regexp-replace
"@file{\\(.*\\)@file{\\(.*\\)}\\(.*\\)}" "@file{\\1\\2\\3}")
;; literal `~' -- if it hasn't been converted to space earlier,
;; we can now do the conversion to @w{word1 word2} without
;; running the risk of confusion the regexp matcher somewhere.
;; Unfortunately @w will get lost again in the HTML conversion
;; because or   are not yet standard HTML tags.
(ltx2texi-regexp-replace
"\\([A-Za-z]+\\)~\\([A-Za-z]+\\)" "@w{\\1 \\2}")
)
(defun ltx2texi-do-environments ()
"Fifth step of \\[ltx2texi-convert]. Not useable by itself."
;; convert \begin and \end of environments
(ltx2texi-alist-replace ltx2texi-env-regexp ltx2texi-env-alist)
;; convert \items
(ltx2texi-string-replace "\\item" "@item")
;; insert newlines after description items where appropriate
(ltx2texi-regexp-replace
"@item\\[\\([^]]+\\)\\][ ]*\n" "@item \\1\n")
(ltx2texi-regexp-replace
"@item\\[\\([^]]+\\)\\][ ]*" "@item \\1\n")
;; insert newlines after @item @file, also replace @item @file
;; by @item @samp -- this is done because it may look nicer
;; in the HTML version, but it depends on the style sheet used
(ltx2texi-regexp-replace
"@item @file\\([^,\n]*\\),[ ]*" "@item samp\\1,\n")
)
;;; handling the header and trailer
(defun ltx2texi-do-header ()
"Convert LaTeX header to Texinfo. Used in \\[ltx2texi-convert]."
(let (title-string
author-string
version-string)
;; collect information
(save-excursion
(re-search-forward "\\\\tdsVersion{\\(.*\\)}" nil t)
(setq version-string (match-string 1))
(re-search-forward "\\\\title{\\(.*\\)}" nil t)
(setq title-string (match-string 1))
(re-search-forward "\\\\author{\\(.*\\)}" nil t)
(setq author-string (match-string 1))
)
;; discard information lines
(ltx2texi-regexp-replace "\\\\title{.*}[ ]*\n" "")
(ltx2texi-regexp-replace "\\\\author{.*}[ ]*\n" "")
(ltx2texi-regexp-replace "\\\\tdsVersion{.*}[ ]*\n\n" "")
;; discard pre-title lines
(ltx2texi-regexp-replace "%&latex[ ]*\n" "")
(ltx2texi-regexp-replace "\\\\NeedsTeXFormat.*\n" "")
;; convert \documentclass to \input texinfo
(ltx2texi-regexp-replace "\\\\documentclass.*\n\n" "\\\\input texinfo\n")
;; insert Texinfo header lines
(save-excursion
(goto-char (search-forward "texinfo\n" nil t))
(insert "@setfilename " ltx2texi-filename "\n")
(insert "@settitle " title-string "\n\n")
(insert "@set version " version-string "\n\n")
)
;; discard \begin{document} and \maketitle
(ltx2texi-regexp-replace "\\\\begin{document}[ ]*\n\n" "")
(ltx2texi-regexp-replace "\\\\maketitle[ ]*\n\n" "")
;; copy contents of `legalnotice' environments
(save-excursion
(let ((begin (search-forward "@titlepage\n\n" nil t))
(end (progn
(search-forward "@end titlepage" nil t)
(match-beginning 0))))
(copy-region-as-kill begin end)
))
;; insert stuff for title page before `legalnotice' environment
;; -- \begin{legalnotice} has been converted to @titlepage
(save-excursion
(goto-char (search-forward "@titlepage\n" nil t))
(insert "@title " title-string "\n")
(insert "@subtitle Version @value{version}\n")
(insert "@author " author-string "\n\n")
(insert "@page\n@vskip 0pt plus 1filll\n")
)
;; insert stuff for @node Top and master menu after `legalnotice'
;; -- \end{legalnotice} has been converted to @end titlepage
(save-excursion
(goto-char (search-forward "@end titlepage\n\n" nil t))
(insert "@ifinfo\n")
(insert "@node Top\n@top " title-string "\n\n")
;; insert contents of `legalnotice' copied above
(yank) ; should include a "\n\n" at the end
(insert "@menu\n@end menu\n")
(insert "@end ifinfo\n\n")
)
;; discard \tableofcontents -- @contents belongs in the trailer
(ltx2texi-regexp-replace "\\\\tableofcontents[ ]*\n\n" "")
))
(defun ltx2texi-do-trailer ()
"Convert LaTeX trailer to Texinfo. Used in \\[ltx2texi-convert]."
;; The list of contributors is a LaTeX tabbing environment, which
;; is difficult to convert -- we convert it to a normal paragraph
;; inside a @quotation environment, so it gets indented a little.
;; Conversion of the tabbing environment is already done elsewhere,
;; so we just have to remove some redundant tags.
;; discard alignment preamble consisting of lines starting with
;; \hspace{0.25\linewidth}
(ltx2texi-regexp-replace "\\\\hspace.*\n" "")
;; convert "\>" and "\\" in tabbing environment to comma
(ltx2texi-regexp-replace "[ ]+\\\\>[ ]*" ", ")
;; In the earlier conversion of "\ ", "\\" followed by newline
;; was already converted to "\", so we just have to convert
;; the remaining instances of "\" followed by space or newline.
(ltx2texi-regexp-replace "[ ]+\\\\[ ]*" ", ")
;; convert \end{document} to @contents and @bye
(ltx2texi-string-replace "\\end{document}" "@contents\n@bye\n")
)
;;; ltx2texi.el ends here
================================================================================
From owner-twg-tds@shsu.edu Mon, 29 Jan 1996 10:20:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 29 Jan 1996 11:15:24 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199601291615.AA26932@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: ltx2texi.el (was Texinfo/Info/HTML version)
P.S. Joachim: If you like, you might put it up in tds/misc as well.
If it gets distributed, perhaps it should be called tds2texi.el.
BTW, the copyright notice doesn't allow copying or modification :-).
(Need to insert the GPL or whatever explicitly.)
Thanks for all your work.
================================================================================
From owner-twg-tds@shsu.edu Mon, 29 Jan 1996 11:03:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 29 Jan 96 17:01:03 GMT
Message-ID: <9601291701.AA29840@r8h.cs.man.ac.uk>
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: TDS locations for graphics.sty, autopict.sty and friends.
The LaTeX `graphics' distribution and also autopict.sty (ie LaTeX
picture mode) would seem to be almost canonical examples of TDS
packages to be installed under tex/latex however as those of you on
ctan-ann@shsu.edu will have just seen, I just put on ctan plain TeX
versions of graphcs color and picture mode. These all work the same
way, the user goes
\input graphicx
and graphicx.tex looks like (in fact is)
% Plain TeX interface to graphicx package.
% David Carlisle
\input miniltx
\makeatletter
\def\Gin@driver{dvips.def}
\input graphicx.sty
\makeatother
miniltx.tex is just whatever I needed to pull out of latex.ltx to get
the packages to load into plain.
The point of this message is that it occured to me that this
requires graphicx.sty (and hence graphics.sty, dvips.def etc etc) to be
in the input path of plain thus most likely in tex/generic/graphics or
something.
Of course by making miniltx.tex approach latex.ltx one could move
more and more of the tex/latex tree under tex/generic. This would seem
to be against the spirit of keeping formats separate in TDS. Not sure
what the politically correct solution is....
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 29 Jan 1996 11:33:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 29 Jan 1996 18:30:07 +0100
Message-ID: <199601291730.SAA15531@spice.iti.informatik.th-darmstadt.de>
From: Joachim Schrod <jschrod@acm.org>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TDS locations for graphics.sty, autopict.sty and friends.
References: <9601291701.AA29840@r8h.cs.man.ac.uk>
>>>>> "DC" == David Carlisle <carlisle@cs.man.ac.uk> writes:
DC> The point of this message is that it occured to me that this
DC> requires graphicx.sty (and hence graphics.sty, dvips.def etc etc) to be
DC> in the input path of plain thus most likely in tex/generic/graphics or
DC> something.
My opinion, too.
DC> Of course by making miniltx.tex approach latex.ltx one could move
DC> more and more of the tex/latex tree under tex/generic. This would seem
DC> to be against the spirit of keeping formats separate in TDS. Not sure
DC> what the politically correct solution is....
IMHO the politically correct solution is: <drumroll> let the author
decide. I.e., that's a matter of _intention_. If code is intended to
be used with multiple formats, it goes in generic/. If it's intended
to be it's own stuff, although one can make it run with effort in
other formats, too; then it goes in <format>/.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: jschrod@acm.org
Roedermark, Germany
Net & publication consultant
================================================================================
From owner-twg-tds@shsu.edu Mon, 29 Jan 1996 12:17:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 29 Jan 96 18:09:36 GMT
Message-ID: <9601291809.AA29996@r8h.cs.man.ac.uk>
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TDS locations for graphics.sty, autopict.sty and friends.
Joachim >IMHO the politically correct solution is: <drumroll> let the
Joachim> author decide.
Ah but what if `the author' can not make up his mind! In this case
graphics was written purely `for' LaTeX. So the suggestion is that it
gets put in tex/latex.
Then 3 years later someone (in this case, but not necessarily, the same
person) writes a `wrapper' for plain TeX that makes a few low level
definitions and then inputs the LaTeX file. Does that mean that the
author of the `wrapper' should be able to change the TDS location of
the original package?
At the time I wrote the first message I had in mind that this
particular example might directly affect people putting together `TDS
compliant' distributions, but I just tried it on tetex and I notice
that
TEXINPUTS = $KPSE_DOT:!!$TEXMF/tex//:!!$FONTDIR/afm//
^^^^^^^^^^^^
so plain tex currently searches the whole lot anyway on tetex. If it
didn't, the graphics.tex file as posted to ctan would not work.
David
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 Jan 1996 07:07:43 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0thFaP-0001iYC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 30 Jan 96 12:55 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: TDS locations for graphics.sty, autopict.sty and friends.
>At the time I wrote the first message I had in mind that this
>particular example might directly affect people putting together `TDS
>compliant' distributions, but I just tried it on tetex and I notice
>that
>TEXINPUTS = $KPSE_DOT:!!$TEXMF/tex//:!!$FONTDIR/afm//
> ^^^^^^^^^^^^
I thought the `canonical' setting for a format-specific TEXINPUTS was:
.:$TEXMF/tex/$FORMAT//:$TEXMF/tex//
It's entertaining to see that fontinst has caused the afm directory to
get into the default TEXINPUTS path! Personally I think I'd leave it
out, since people running fontinst are expected to know what they're
doing (spot my attitude to software). Alternatively, you could have a
`fontinst' shell script which sets TEXINPUTS to:
.:$TEXMF/tex/fontinst//:$TEXMF/tex//:$TEXMF/fonts/afm//:$TEXMF/fonts/pl//:
before running `tex fontinst.sty'.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 Jan 1996 10:26:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 30 Jan 1996 11:22:34 -0500
Message-ID: <199601301622.AA23266@terminus.cs.umb.edu>
From: kb@terminus.cs.umb.edu
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TDS locations for graphics.sty, autopict.sty and friends.
I thought the `canonical' setting for a format-specific TEXINPUTS was:
.:$TEXMF/tex/$FORMAT//:$TEXMF/tex//
I believe the doc currently says merely to include generic// after $FORMAT//.
However, this discussion is persuasive argument otherwise. I'll change
it for the next draft.
author of the `wrapper' should be able to change the TDS location of
the original package?
No, of course not. That's one reason it's persuasive.
(Soon we'll back to everything being in one directory ... :-)
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 Jan 1996 11:47:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 30 Jan 1996 18:44:56 +0100
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9601301744.AA02192@regulus.dbis.uh>
To: TWG-TDS@SHSU.edu
Subject: Re: TDS locations for graphics.sty, autopict.sty and friends.
> >compliant' distributions, but I just tried it on tetex and I notice
> >that
>
> >TEXINPUTS = $KPSE_DOT:!!$TEXMF/tex//:!!$FONTDIR/afm//
> I thought the `canonical' setting for a format-specific TEXINPUTS was:
> .:$TEXMF/tex/$FORMAT//:$TEXMF/tex//
Yes, indeed. And this is how TEXINPUTS.latex ist set up. But the
TEXINPUTS line in texmf.cnf is not format-specific. It is the fallback
path if none of the format-specific paths applies.
> It's entertaining to see that fontinst has caused the afm directory to
> get into the default TEXINPUTS path! Personally I think I'd leave it
The reason for the afm in TEXINPUTS is that teTeX includes a ps2pk version
that searches for .afm files along the kpse_tex_format path.
There still is no kpse_afm_format, even in the latest tex-pretest.
Thomas
================================================================================
From owner-twg-tds@shsu.edu Tue, 30 Jan 1996 14:30:53 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0thMbk-0001iQC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 30 Jan 96 20:24 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: TDS locations for graphics.sty, autopict.sty and friends.
>> It's entertaining to see that fontinst has caused the afm directory to
>> get into the default TEXINPUTS path! Personally I think I'd leave it
>The reason for the afm in TEXINPUTS is that teTeX includes a ps2pk version
>that searches for .afm files along the kpse_tex_format path.
Bizarre---there's another tool which needs afm files on the texinputs
path. Weirdness abounds...
>There still is no kpse_afm_format, even in the latest tex-pretest.
Sounds like it wouldn't hurt if there were such a beastie...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 31 Jan 1996 10:18:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 31 Jan 1996 17:13:02 +0100
Message-ID: <199601311613.RAA13570@spice.iti.informatik.th-darmstadt.de>
From: Joachim Schrod <jschrod@acm.org>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: ltx2texi.el (was Texinfo/Info/HTML version)
References: <199601291615.AA26932@terminus.cs.umb.edu>
>>>>> "KB" == K Berry <kb@cs.umb.edu> writes:
KB> P.S. Joachim: If you like, you might put it up in tds/misc as well.
KB> If it gets distributed, perhaps it should be called tds2texi.el.
If it shall be distributed, it must be sent to me again. I've thrown
away the mail as I didn't intended to use it myself.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: jschrod@acm.org
Roedermark, Germany
Net & publication consultant
From owner-twg-tds@shsu.edu Thu, 01 Feb 1996 03:20:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 1 Feb 1996 10:19:37 +0100
Message-ID: <9602010919.AA13364@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: ltx2texi.el (was Texinfo/Info/HTML version)
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Joachim writes:
>>>>> "KB" == K Berry <kb@cs.umb.edu> writes:
KB> P.S. Joachim: If you like, you might put it up in tds/misc as well.
KB> If it gets distributed, perhaps it should be called tds2texi.el.
> If it shall be distributed, it must be sent to me again. I've thrown
> away the mail as I didn't intended to use it myself.
1. Karl is right concerning the name change. Calling it ltx2texi.el
would probably raise false expectations, especially if it ends up
on CTAN:tds/ and people happen to find it with `quote site index'.
2. We haven't yet established whether or not it should be distributed
at all. As I said before, I wouldn't mind that, but whether it should
probably depends on whether it will actully be used in the production
of ``official'' Info and HTML versions (in case any further revisions
are needed at all). Of course, it that case the then-current version
of tds2texi.el should be archived, but not necesarily all previous
revisions.
In any case, I'll send Joachim another copy in a private mail.
No need to clutter up the TDS mail archives with that.
Cheers, Ulrik.
P.S. Apparently, you misquoted the lines above. The first line
reading KB> was actually my text, but Karl just uses indentation
for quoted text and no prefixes, so that wasn't clear to SuperCite.
================================================================================
From owner-twg-tds@shsu.edu Sat, 17 Feb 1996 07:06:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 17 Feb 1996 12:49:59 GMT
Message-ID: <199602171249.MAA07718@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: TDS / Unix CD work
References: <"swan.cl.cam.:057100:951120205114"@cl.cam.ac.uk>
After talking vaguely about this for some time on and off, and being
aware of other similar projects, i have decided to try and go for a
new Unix teTeX CD within the next 3 months regardless. This would be
jointly sold/approved by TUG, UKTUG and GUTenberg, if they formally
agree (I haven't formally asked yet :-}), or by me personally if they
dont...
Naturally, i want as much help and advice as i can get on this, so who
better than the veterans of the TDS? Obviously anyone who has worked
on the 4AllTeX CD will have very valuable opinions about what should
be on the wishlist.
The GroundRules
---------------
1) the CD has two main objectives:
a) to provide a ready to run mountable Unix file system
for a variety of platforms
b) to provide an ISO-9660 compliant TDS runtime
tree as large as we can make it, with text files in Unix format
(or LF line separators, not CR/LF)
if there is space to DOS, MAC, VMS executables, all well and good,
but that is not the current priority
2) the executables and layout are Thomas Esser's teTeX package, no
arguing please. this means the CD looks like
/texmf TDS tree
/bin
/system binaries
/man
/info
/texmf.cnf runtime configuration file
/distrib the archival teTeX distribution
/src any other sources provided
<other> if someone contributes VMS or something
if you haven't used teTeX, be aware that its runtime configuration
*is in relation to the binaries*. there is no default location for
the package.
Thomas will provide new Make* scripts to write on writeable media;
by default this will be the TDS tree under /usr/local/texmf (the only
decision about real locations that had to be made), but an
environment variable can relocate this
3) the CD must be ready for sale on May 29th at a GUTenbery meeting
about TeX distributions
4) the master file system will either be here at Elsevier (i have got
loan of a few gigabytes to play in) or at SCRI in the TUGboat
production area. my job is to collate and insert contributions.
5) arguments about TDS layout are referred to the TDS group
6) arguments about executables, layout, compilation, what have you,
will be referred to Thomas Esser and Karl Berry as arbiters
7) this CD should have a shelf-life of 3-6 months and will be re-issued once
web2c 7 is stable
8) There are no remaining preconditions about what goes on the CD. we go
with what is there now if all else fails
9) no packages "just in case" or "might work" or "here are the sources,
give it a try". Totally set up or nothing.
What Not to Do
--------------
- Start arguing about the philosophy of the idea
- Say "why not DOS?" or "Why not Macintosh?"
- Suggest waiting for web2c 7.0
- Suggest different locations for binaries
- Suggest it have all of CTAN on there
- Ask about copyright
- Tell me how to do it, but not do it yourself
What to Do
----------
a) ask me for the current contents list, and wish list, and decide which
bit you can provide (i can put these lists on CTAN)
b) get and install a virgin teTeX distribution if you don't have it
c) if its an executable, find someone with clean "reference" machines;
Michel Goossens and CERN may be able to help a little here
d) make your package, and send me a tar file, with a paragraph saying
what you did, when, and so on
The Wish List
-------------
I'll append my initial wish list. I'll maintain this, and note who is
doing what (its like a wedding present list....)
Conclusion
----------
Any comments? Suggestions? Feel free to circulate this to anyone you
think would like to join in.
sebastian
# this is mostly programs so far; i take it for granted that
# there are millions of LaTeX packages and
# fonts to do.
Package: A much larger set of PostScript metrics
Who: SPQR
Package: aucTeX and lacheck
Note: location?
Package: detex
Package: dt2dv and dv2dt
Note: Geoffrey Tobin's package
Package: dvidvi
Package: dviselect, dviconcat
Note: part of SeeTeX
Package: latex2html
Note: a *real* can of worms. i dont even want to think about it
Package: metapost
Note: needs a source patch, executables, and a diff for texmf.cnf
Package: mlTeX
Note: this needs some discussion with Thomas
Package: omega
Note: i have asked John and Yannis
Package: pstricks
Package: t1utils?
Package: xhdvi
Note: maybe not clean, talk to Thomas
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Feb 1996 04:16:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Feb 1996 11:11:09 +0100
Message-ID: <9602201011.AA09797@caligula.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: TDS / Unix CD work
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sebastian wrote:
> After talking vaguely about this for some time on and off, and being
> aware of other similar projects, i have decided to try and go for a
> new Unix teTeX CD within the next 3 months regardless. This would be
> jointly sold/approved by TUG, UKTUG and GUTenberg, if they formally
> agree (I haven't formally asked yet :-}), or by me personally if they
> dont...
First question: what about DANTE (and NTG and whatever other group)?
No, I'm not a DANTE official, just an ordinary member, but I wonder
why you just mention those three groups above.
> Naturally, i want as much help and advice as i can get on this, so who
> better than the veterans of the TDS? Obviously anyone who has worked
> on the 4AllTeX CD will have very valuable opinions about what should
> be on the wishlist.
Next question: I recently discovered that there exists or existed
a TEX-CD mailing list at listserv.shsu.edu, whose mail archives seem
to indicate that it was active only briefly from December 93 till
March 94, but has been idle ever since the NTG went ahead to produce
their 4allTeXCD (which I personally find a very messy) while most
of the Unix people started discussing the TDS and took 1 1/2 years
to finish that.
Wouldn't it be a good idea to reactivate that mailing list for your
project? AFAIK, it's open for subscribtion by anyone (I've tried it
recently) while the TDS mailing list is closed and both list-owners
are unavailable.
> a) to provide a ready to run mountable Unix file system
> for a variety of platforms
> b) to provide an ISO-9660 compliant TDS runtime
> tree as large as we can make it, with text files in Unix format
> (or LF line separators, not CR/LF)
OK, sound's fine so far. But might I also suggest using RockRidge
Extensions to allow for those files that don't (yet) fit in the
8+3 name space? I don't know about the technical impliciations,
but most of the Linux CDs have it, and it works just fine without
even thinking about it. Besides, file names like dvips.info-{1,2,3}
or kpathsea_toc.html wouldn't travel too well under 8+3 truncation
and we're aiming especially at Unix systems.
> What Not to Do
> --------------
[...]
> - Suggest waiting for web2c 7.0
That's what I was about to suggest concerning MetaPost (see below)
> What to Do
> ----------
[...]
> b) get and install a virgin teTeX distribution if you don't have it
... and get more disk space if it's all occupied by texk-pretest...
> Conclusion
> ----------
> Any comments? Suggestions? Feel free to circulate this to anyone you
> think would like to join in.
Some suggestions:
1.) Try to preserve the original file dates/modification times as
much as possible, i.e. use cp -p or tar when arranging files
on the local filesystem. Likewise, when ftp'ing always get
the whole directory as tar.gz not individual files, since tar
will preserve the time stamps while ftp doesn't.
2.) Add lots of documentation in texmf/doc, at least more than
there is presently in the teTeX distribution.
Some suggestions: the latest UK TUG TeX FAQ, comp.fonts FAQ,
the TDS draft (so that people can understand why things are
organized as they are), tutorials such as lshort2e/lkurz2e,
other useful stuff in CTAN:help or CTAN:info ...
3.) Add index.html files to the texmf/doc tree, so that uses can
point their favorite WWW browser to the mounted CD and find
the documentation by a clicking and having the appropriate
viewer (xdvi, ghostview, whatever) invoked automatically,
no matter what file format. I suspect that many people tend
to ignore the documentation if it's difficult to find, but
what could be easier than WWW.
Caveat: Collecting the raw data for index.html files is easy
using the MakeHTML script in teTeX. But making these index
files pretty by adding the titles and a little description
can be a lot of work, though.
> Package: A much larger set of PostScript metrics
> Who: SPQR
I'm skeptical about that. Anything that goes beyond the basic
35 and a few free widely-used fonts probably won't do any good
for a large pecentage of users that don't have extra font CDs.
Besides, while running from the mounted CD is one goal, I think
it should also be easy to copy packages to disk selectively
if one doesn't want to run from CD. In that case, a huge font
tree might not be what everyone wants, or at least it would
make it more difficult to copy some subtrees of the texmf tree.
> Package: aucTeX and lacheck
> Note: location?
In case of doubt, I'd suggest an emacs/lisp tree at the top level.
Still, users running from the CD would have to set their load-path
appropriately or copy an edited version of tex-site.el to their
site-lisp directory on disk. The location of the info files
shouldn't be a problem, though. Just put them in the teTeX info
directory.
BTW, are there other non-standard Emacs packages that would be
of general interest on a TeX CD? Anything like html-helper-mode
or other HTML/SGML stuff?
> Package: latex2html
> Note: a *real* can of worms. i dont even want to think about it
While latex2html might be difficult, I'd suggest to include
texi2html, especially since Texinfo is already there in teTeX.
It does require Perl (which we might assume to be available on
many Unix platforms), but as far as I know it works just fine
with both Perl4 and Perl5.
We might also include texi2html-converted versions of Texinfo
manuals, i.e. Kpathsea, Dvips, Eplain, AucTeX, TDS, ...
> Package: metapost
> Note: needs a source patch, executables, and a diff for texmf.cnf
Well, I guess I would be the ideal candidate for that, should
I allow myself to be drawn into it. However, as I mentioned
recently on the teTeX mailing list, I'd really hate to go back
to the old version and touch up the MP-0.63/teTeX-0.3 version
for MP-0.631/teTeX-0.3.3 (with additional bug fixes for MP).
That's why I was about to suggest waiting for web2c-7.0 which
will have it by default (including several minor impovements).
Anyone else who wants to do it?
> Package: omega
> Note: i have asked John and Yannis
Is Phil going to suggest e-TeX 1.0 as well? Bernd already had
a change file for web2c-7.0, I believe, and I think it would
be much easier to include than Omega, since it doesn't change
the architecture. (I had tried e-TeX once with teTeX-0.3
when it was first announced, but I never pursued that further.)
Other packages of potential interest:
- filehdr (and checksum)
consist of an elisp package and a small C program
- psutils: psbook, psselect, psnup, ...
most of them C programs, some might require Perl
- cweb (or cwebx), wmerge, tie, other LitProg tools?
OK, so far these are just some comments and ideas. I'm a bit
reluctant to really offer my help on anything specific since
I've already spend too much time on various projects recently
and should better concentrate on getting some real work done.
Anyway, it looks good so far and I wish the project success.
I hope it'll really get done this time and I'm looking forward
to the first usable TeX CD that neither suffers from a messy
organization nor from having everything packaged up making
it difficult to get at anything (such as having the teTeX
binaries for all platforms packaged in a huge 20 MB zip file
only to preserve the long file names of the tar.gz files).
In case of doubt, I'd suggest that less is more, i.e. better
concentrate on the well-known standard stuff and have that
well organized rather than trying to fill the CD to the max.
Cheers, Ulrik.
P.S. Last question: Any idea about the price of the CD?
The latest CTAN CD produced by DANTE in cooperation with
Addison-Wesley sells at DM 50,- with book or DM 10,-
(CD only) for DANTE members.
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Feb 1996 07:44:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Feb 1996 13:37:21 GMT
Message-ID: <199602201337.NAA06071@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: TDS / Unix CD work
References: <9602201011.AA09797@caligula.uni-duesseldorf.de>
> First question: what about DANTE (and NTG and whatever other group)?
> No, I'm not a DANTE official, just an ordinary member, but I wonder
> why you just mention those three groups above.
nothing against Dante at all, but i personally am doing this as part
of my contribution to TUG and UKTUG, and Michel Goossens is working on
it for GUTenberg. so that was where i started. i have asked Michel
to contact the othe rgroups in due course to ask them if they want to
take part. but its individuals who will do the work
> Next question: I recently discovered that there exists or existed
> a TEX-CD mailing list at listserv.shsu.edu, whose mail archives seem
> to indicate that it was active only briefly from December 93 till
> March 94, but has been idle ever since the NTG went ahead to produce
> their 4allTeXCD (which I personally find a very messy) while most
> of the Unix people started discussing the TDS and took 1 1/2 years
> to finish that.
ah, history. yes, that list started when NTG (Kees, i think) first
proposed the 4alltex thing. i got involved by saying we should do it
properly, but it got too complicated, so NTG went ahead with the
smaller project. in the meanwhile, as you say, the discussion rolled
off to become the TDS
> Wouldn't it be a good idea to reactivate that mailing list for your
> project? AFAIK, it's open for subscribtion by anyone (I've tried it
i will do, if enough people show an interest, certainly.
> OK, sound's fine so far. But might I also suggest using RockRidge
> Extensions to allow for those files that don't (yet) fit in the
> 8+3 name space? I don't know about the technical impliciations,
oh, sorry, i didnt make it clear. this *is* a Rock Ridge CD, but the
TDS tree is ISO conformant. so DOS people will see just what Unix
people see, once they go below texmf. what they see in
bin/sparc-solaris2.4, who knows or cares :-}
i made my first test Rock Ridge CD this morning, creating an image on a CD and
then taking it to a PC to write a disk. it worked as i expected, so i am
confident so far
> > b) get and install a virgin teTeX distribution if you don't have it
> ... and get more disk space if it's all occupied by texk-pretest...
disk is cheap, so they tell me :-}
> 1.) Try to preserve the original file dates/modification times as
> much as possible, i.e. use cp -p or tar when arranging files
> on the local filesystem. Likewise, when ftp'ing always get
> the whole directory as tar.gz not individual files, since tar
> will preserve the time stamps while ftp doesn't.
yes. submission method is by tar.gz, i agree.
> 2.) Add lots of documentation in texmf/doc, at least more than
> there is presently in the teTeX distribution.
> Some suggestions: the latest UK TUG TeX FAQ, comp.fonts FAQ,
> the TDS draft (so that people can understand why things are
> organized as they are), tutorials such as lshort2e/lkurz2e,
> other useful stuff in CTAN:help or CTAN:info ...
yes, any or all of that, sure. i propose to have the TDS printed out
with the CD
> 3.) Add index.html files to the texmf/doc tree, so that uses can
> point their favorite WWW browser to the mounted CD and find
> the documentation by a clicking and having the appropriate
> viewer (xdvi, ghostview, whatever) invoked automatically,
> no matter what file format. I suspect that many people tend
sounds a fine idea.
> to ignore the documentation if it's difficult to find, but
> what could be easier than WWW.
i could suggest things
> Caveat: Collecting the raw data for index.html files is easy
> using the MakeHTML script in teTeX. But making these index
goodness. i never heard of makehtml. ok, sounds good
> files pretty by adding the titles and a little description
> can be a lot of work, though.
if there is a master catalog file. oh god, we are talking LSM already
:-}
> > Package: A much larger set of PostScript metrics
> > Who: SPQR
>
> I'm skeptical about that. Anything that goes beyond the basic
> 35 and a few free widely-used fonts probably won't do any good
> for a large pecentage of users that don't have extra font CDs.
lots of people have Lucida
> Besides, while running from the mounted CD is one goal, I think
> it should also be easy to copy packages to disk selectively
> if one doesn't want to run from CD. In that case, a huge font
> tree might not be what everyone wants, or at least it would
> make it more difficult to copy some subtrees of the texmf tree.
ah, ok in that case i break it up into pieces. ok, fine.
> In case of doubt, I'd suggest an emacs/lisp tree at the top level.
> Still, users running from the CD would have to set their load-path
> appropriately or copy an edited version of tex-site.el to their
> site-lisp directory on disk. The location of the info files
> shouldn't be a problem, though. Just put them in the teTeX info
> directory.
Joachim has said he'll look at this
> While latex2html might be difficult, I'd suggest to include
> texi2html, especially since Texinfo is already there in teTeX.
> It does require Perl (which we might assume to be available on
> many Unix platforms), but as far as I know it works just fine
> with both Perl4 and Perl5.
given the way teTeX works, this would have to do in every bin
directory, yes?
> We might also include texi2html-converted versions of Texinfo
> manuals, i.e. Kpathsea, Dvips, Eplain, AucTeX, TDS, ...
i sense a volunteer...
> > Package: metapost
> > Note: needs a source patch, executables, and a diff for texmf.cnf
>
> Well, I guess I would be the ideal candidate for that, should
> I allow myself to be drawn into it. However, as I mentioned
if you dont, i dont think anyone else will
> That's why I was about to suggest waiting for web2c-7.0 which
> will have it by default (including several minor impovements).
if web2c 7.0 is finished soon, fine. otherwise wait for a second
edition in the late summer?
> Is Phil going to suggest e-TeX 1.0 as well? Bernd already had
including etex or omega is a *serious* undertaking, as it means
building it for every platform, apart from integration with teTeX's
kpathsea. if someone can do it, great. but its not a sine qua non,
IMHO
personally i'd prefer Omega, since i dont see any great use for eTeX,
buts thats my personal bias ;-}
> - filehdr (and checksum)
> consist of an elisp package and a small C program
compiled for 15-20 platforms?
> - psutils: psbook, psselect, psnup, ...
> most of them C programs, some might require Perl
ditto, compiled for 15-20 platforms?
> - cweb (or cwebx), wmerge, tie, other LitProg tools?
too much work in the time available to get this right. lets get
the main TDS tree right first
> I hope it'll really get done this time and I'm looking forward
> to the first usable TeX CD that neither suffers from a messy
> organization nor from having everything packaged up making
well, i can promise you that. i have it in front of me! i have 200 Mb
of stuff (about 50 is proprietary fonts belonging to Elsevier) on it,
and the only thing lacking is a) more and more packages, b) rewritten
scripts to make sure no-one tries to write on the CD. i propose taking
it home tonight, throwing away my TeX installation, and mounting this
nice gold job...
> In case of doubt, I'd suggest that less is more, i.e. better
> concentrate on the well-known standard stuff and have that
> well organized rather than trying to fill the CD to the max.
i could not agree more.
> P.S. Last question: Any idea about the price of the CD?
> The latest CTAN CD produced by DANTE in cooperation with
> Addison-Wesley sells at DM 50,- with book or DM 10,-
> (CD only) for DANTE members.
my contacts suggest i can make copies for around \pounds 5 a disk
if i make 200-300. so i'd expect \pounds10-15 realistically to get
the package. how many did DANTE make, does anyone know?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Feb 1996 09:59:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Feb 1996 15:50:28 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: <960220155028.21e1d635@vms.rhbnc.ac.uk>
Subject: Re: TDS / Unix CD work
>> personally i'd prefer Omega, since i dont see any great use for eTeX,
>> buts thats my personal bias ;-}
So you don't want to be told the exact line at which
your unmatched `{' occurred?! OK, that's up to you :-)
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Feb 1996 09:59:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Feb 1996 16:57:00 +0100
Message-ID: <9602201557.AA10896@caligula.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: TDS / Unix CD work
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
>> While latex2html might be difficult, I'd suggest to include
>> texi2html, especially since Texinfo is already there in teTeX.
>> It does require Perl (which we might assume to be available on
>> many Unix platforms), but as far as I know it works just fine
>> with both Perl4 and Perl5.
> given the way teTeX works, this would have to do in every bin
> directory, yes?
That depends on how you set up the search path. Perhaps it might
be a good idea to the platform-independ stuff like Perl or shell
scripts into CD:/bin and only the binaries into CD:/bin/system.
>> We might also include texi2html-converted versions of Texinfo
>> manuals, i.e. Kpathsea, Dvips, Eplain, AucTeX, TDS, ...
> i sense a volunteer...
That would be easy indeed. I could more less just tar up what
I've got, but I'd better check that I have the latest versions.
>> > Package: metapost
>> > Note: needs a source patch, executables, and a diff for texmf.cnf
>>
>> Well, I guess I would be the ideal candidate for that, should
>> I allow myself to be drawn into it. However, as I mentioned
> if you dont, i dont think anyone else will
Well, perhaps I might have another look, but only if someone
else (Thomas?) would take care of producing the binaries for all
platforms. Also note that including MetaPost involves messing
around with teTeX's kpathsea library and rebuilding kpsetool.
>> - filehdr (and checksum)
>> consist of an elisp package and a small C program
> compiled for 15-20 platforms?
>> - psutils: psbook, psselect, psnup, ...
>> most of them C programs, some might require Perl
> ditto, compiled for 15-20 platforms?
How many platforms are there already in standard teTeX and how many
do you plan to support? But yes, you're right, any program that's
added needs to be compiled for each platform.
> my contacts suggest i can make copies for around \pounds 5 a disk
> if i make 200-300. so i'd expect \pounds10-15 realistically to get
> the package. how many did DANTE make, does anyone know?
AFAIK, someone at DANTE did the work of putting the CD together,
but the CD was produced by Addison-Wesley. DANTE got 500 copies
for distribution to their members. I have no idea, how many A-W
produced for sale with their book. BTW, most of the book only
tells you how to do unzip, gunzip, ftp, ftpmail, whatever, so
it's almost entirely useless for anyone who knows that already.
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Feb 1996 10:12:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Feb 1996 11:06:07 -0500
Message-ID: <199602201606.AA11410@terminus.cs.umb.edu>
From: kb@terminus.cs.umb.edu
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TDS / Unix CD work
> Package: A much larger set of PostScript metrics
> Who: SPQR
I'm skeptical about that. Anything that goes beyond the basic
I think including your metrics for all the PS fonts is a great idea.
But I also think the way to organize it is according to what fonts users
actually have, i.e., the installation options are:
1) freefonts + 35
2) bitstream 500 font cd
3) monotype cd
4) y&y lucida
and whatever else. *Not* by selecting individual typefaces or vendors,
since everyone will have adobe/*/utopia, but few will have adobe/*/garamond.
If you *really* want to go overboard, we could construct a list of the
Type 1's supplied by the Unix vendors and have more options:
5) AIX Type 1's
6) SunOS Type 1's
etc.
If the installation script (assuming its existence) works off a database
that maps installation options to directories to install off the CD,
this would be easy.
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Feb 1996 10:12:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Feb 1996 16:10:16 GMT
Message-ID: <199602201610.QAA07961@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
CC: CHAA006@alpha1.rhbnc.ac.uk
Subject: Re: TDS / Unix CD work
References: <960220155028.21e1d635@vms.rhbnc.ac.uk>
Philip Taylor writes:
> >> personally i'd prefer Omega, since i dont see any great use for eTeX,
> >> buts thats my personal bias ;-}
>
> So you don't want to be told the exact line at which
> your unmatched `{' occurred?! OK, that's up to you :-)
>
ah, when you emerge from your shell, Phil, it is with a bounce in your
step and an airy gait
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Feb 1996 10:18:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Feb 1996 17:15:29 +0100
Message-ID: <9602201615.AA11206@caligula.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Re: TDS / Unix CD work
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Karl asked:
> Caveat: Collecting the raw data for index.html files is easy
> using the MakeHTML script in teTeX. But making these index
> What is MakeHTML?
Since Sebastian also asked about it, I'll better reply to TWG-TDS.
`MakeHTML' is a script that I got from teTeX, where it was located
in texmf/doc. It could be that is was originally called `makehtml'
and I renamed it to have it sorted to the top of the directory.
It basically recurses through all the subdirectories and generates
a simple listing of all .tex, .dvi and .ps files it finds.
It's good start for collecting raw data for an index.html file,
but it doesn't know about .dvi.gz and .ps.gz. Of course, it also
can't decide whether a .tex file is just part of the source of
a printed manual or an example that users might want to look at.
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Feb 1996 10:33:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Feb 1996 16:31:28 GMT
Message-ID: <199602201631.QAA11674@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: TDS / Unix CD work
References: <199602201606.AA11410@terminus.cs.umb.edu>
> But I also think the way to organize it is according to what fonts users
> actually have, i.e., the installation options are:
> 1) freefonts + 35
> 2) bitstream 500 font cd
> 3) monotype cd
> 4) y&y lucida
> and whatever else. *Not* by selecting individual typefaces or vendors,
> since everyone will have adobe/*/utopia, but few will have adobe/*/garamond.
i buy the idea of separating out
standard
otheradobe
monotype
free
lucida
but not on a basis of CDs. people buy things individually as well
> If you *really* want to go overboard, we could construct a list of the
> Type 1's supplied by the Unix vendors and have more options:
> 5) AIX Type 1's
> 6) SunOS Type 1's
but i dont want to go overboard :-}
>
> If the installation script (assuming its existence) works off a database
> that maps installation options to directories to install off the CD,
> this would be easy.
we dont have an instalation script :-{
its called cp -r
BTW please consider the fact that i cant have subdirectories under
texmf/tex/latex/psnfss (remember that discussion?), so how do i divide
up this stuff?
BTW (2), i am breaking down the texmf/dvips directory into
texmf/dvips/<package> (ie starting with base), in order to make it
quite clear what comprises eg pstricks and what does not. this works,
but will screw `plain' dvips users, i suspect. does anyone think i am
being over-hard?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Feb 1996 10:54:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Feb 1996 16:50:41 GMT
Message-ID: <199602201650.QAA12225@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
CC: te@informatik.uni-hannover.de
Subject: Re: TDS / Unix CD work
References: <9602201557.AA10896@caligula.uni-duesseldorf.de>
> That depends on how you set up the search path. Perhaps it might
> be a good idea to the platform-independ stuff like Perl or shell
> scripts into CD:/bin and only the binaries into CD:/bin/system.
i'll let Thomas comment on that...
> >> We might also include texi2html-converted versions of Texinfo
> >> manuals, i.e. Kpathsea, Dvips, Eplain, AucTeX, TDS, ...
> > i sense a volunteer...
> That would be easy indeed. I could more less just tar up what
> I've got, but I'd better check that I have the latest versions.
please, yes. i assume you *are* a teTeX user, so that you'llbe using
the same as Thomas?
> Well, perhaps I might have another look, but only if someone
> else (Thomas?) would take care of producing the binaries for all
> platforms. Also note that including MetaPost involves messing
> around with teTeX's kpathsea library and rebuilding kpsetool.
oh horrors. this is getting unfunny. i dont think we should do it
this time
> How many platforms are there already in standard teTeX and how many
> do you plan to support? But yes, you're right, any program that's
> added needs to be compiled for each platform.
there are 12 now. thomas sent me 5 more today, and there are certainly
others
> AFAIK, someone at DANTE did the work of putting the CD together,
> but the CD was produced by Addison-Wesley. DANTE got 500 copies
> for distribution to their members. I have no idea, how many A-W
how is the Dante CD organized? compressed? CTAN layout?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Feb 1996 11:03:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Feb 1996 18:01:46 +0100
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9602201701.AA14346@wega.informatik.uni-hannover.de>
To: TWG-TDS@shsu.edu
Subject: Re: TDS / Unix CD work
> > That depends on how you set up the search path. Perhaps it might
> > be a good idea to the platform-independ stuff like Perl or shell
> > scripts into CD:/bin and only the binaries into CD:/bin/system.
> i'll let Thomas comment on that...
Two things:
- I do not like files of the same type at different directory levels
- that way the user has to add *two* directories to his PATH.
It is really not hard to copy a set of scripts from one 'master'
directory into all the other subdirectories. It is just 1 minute of
shell programming...
> > Well, perhaps I might have another look, but only if someone
> > else (Thomas?) would take care of producing the binaries for all
> > platforms. Also note that including MetaPost involves messing
> > around with teTeX's kpathsea library and rebuilding kpsetool.
> oh horrors. this is getting unfunny. i dont think we should do it
> this time
No, I definately do not want to recompile teTeX for all the 17
platforms I now have binaries for...
> > How many platforms are there already in standard teTeX and how many
> > do you plan to support? But yes, you're right, any program that's
> > added needs to be compiled for each platform.
> there are 12 now. thomas sent me 5 more today, and there are certainly
> others
At least solaris-2.5 will be added.
Thomas
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Feb 1996 12:33:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Feb 1996 18:05:52 GMT
Message-ID: <199602201805.SAA14153@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@ELSEVIER.CO.UK>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
CC: m.GOOSSENS@CERN.ch
Subject: Re: TDS / Unix CD work
References: <9602201701.AA14346@wega.informatik.uni-hannover.de>
>
> At least solaris-2.5 will be added.
>
i think there was a variety of aix that Michel asked for. what is the
supported set at CERN, Michel?
if no-one else does it, i shall do solaris-2.5 next week
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Feb 1996 12:36:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Feb 1996 19:32:15 +0100 (MET)
From: Michel Goossens <Michel.Goossens@cern.ch>
Reply-To: TWG-TDS@SHSU.edu
To: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
CC: TWG-TDS@shsu.edu, m.GOOSSENS@cern.ch
Subject: Re: TDS / Unix CD work
Message-ID: <Pine.A32.3.91.960220193046.59021B-100000@sp053.cern.ch>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> > At least solaris-2.5 will be added.
> >
We also now have solaris 2.5 (somewhere)
> i think there was a variety of aix that Michel asked for. what is the
> supported set at CERN, Michel?
The "old" 3.2, and the "new" 4.1 (which does not work yet :+{).
Plus a few SGI's. Perhaps it would be best to post the present list
to the "core team", so that I can talk to people at CERN to find
"clear" misses (for us, at least).
m
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Feb 1996 16:43:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Feb 1996 17:42:29 -0500
Message-ID: <199602202242.AA24988@terminus.cs.umb.edu>
From: kb@terminus.cs.umb.edu
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TDS / Unix CD work
- I do not like files of the same type at different directory levels
Put the scripts in bin/share.
- that way the user has to add *two* directories to his PATH.
Users don't mind.
It is really not hard to copy a set of scripts from one 'master'
directory into all the other subdirectories. It is just 1 minute of
shell programming...
Of course not. It's keeping all the copies up-to-date that is a pain. If
they never change, then it doesn't matter, of course.
If we are talking modern Unix, Rock Ridge, and all that, how about links
(hard or soft)?
================================================================================
From owner-twg-tds@shsu.edu Tue, 20 Feb 1996 16:51:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Feb 1996 17:46:32 -0500
Message-ID: <199602202246.AA25071@terminus.cs.umb.edu>
From: kb@terminus.cs.umb.edu
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TDS / Unix CD work
we dont have an instalation script :-{
We're not going to query the user as to what they want to install off
the CD? Just blast the whole thing to the hard disk? I don't think
people will be happy.
BTW please consider the fact that i cant have subdirectories under
texmf/tex/latex/psnfss (remember that discussion?), so how do i divide
up this stuff?
What stuff? I'm confused. if you're talking about the latest support
files, didn't we conclude the only feasible solution was to stuff
everything into that one directory?
BTW (2), i am breaking down the texmf/dvips directory into
texmf/dvips/<package> (ie starting with base), in order to make it
quite clear what comprises eg pstricks and what does not. this works,
but will screw `plain' dvips users, i suspect. does anyone think i am
being over-hard?
Do you mean tex/dvips/<package>? I don't see why pstricks should be
under dvips. It doesn't come with it.
I don't see why plain users will be screwed, but then I guess I don't
really understand what you're doing :-). And yes, if you are going to
make dvips/psfonts unusable for plain folks, I think you are being
overhard :-).
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Feb 1996 04:41:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 21 Feb 1996 11:37:59 +0100
Message-ID: <199602211037.LAA00160@lancelot.thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: TDS / Unix CD work
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sebastian wrote:
>> >> We might also include texi2html-converted versions of Texinfo
>> >> manuals, i.e. Kpathsea, Dvips, Eplain, AucTeX, TDS, ...
>> > i sense a volunteer...
>> That would be easy indeed. I could more less just tar up what
>> I've got, but I'd better check that I have the latest versions.
> please, yes. i assume you *are* a teTeX user, so that you'llbe using
> the same as Thomas?
OK, since I was the one who suggested and since I had everything
I needed around, I did that last night. Details follow in the
next mail. BTW, I am a teTeX user, but I'm lagging behind. So far,
I'm still using the development version teTeX-0.3 here and at home.
>> Well, perhaps I might have another look, but only if someone
>> else (Thomas?) would take care of producing the binaries for all
>> platforms. Also note that including MetaPost involves messing
>> around with teTeX's kpathsea library and rebuilding kpsetool.
> oh horrors. this is getting unfunny. i dont think we should do it
> this time
Well, so it really seems better to delay MetaPost for web2c-7.0,
doesn't it? It that case, I'd also suggest delaying Omega, ML-TeX,
e-TeX as well since including them might have similar implications
AFAIK, web2c-7.0 will at least include MetaPost and tex -mltex.
Bernd already did some work on integrating e-TeX for texk-pretest,
but that still requires merging multiple change files for TeX,
so it would be slightly more difficult but certainly possible.
I don't know about Omega, but I suspect it might imply some more
substantial changes to get everything up to Unicode/16bit etc.
> how is the Dante CD organized? compressed? CTAN layout?
CTAN layout, snapshot taken on 1995/11/01. Everything is packed
into zip files by directory. So I have to do things like
unzip -p <directory>.zip some-long-file-name.tar.gz | tar xvf -
It works, but it's so incovenient that it makes a strong case
for using RockRidge to put long file names on the CD.
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Feb 1996 04:53:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 21 Feb 1996 11:50:53 +0100
Message-ID: <199602211050.LAA00173@lancelot.thphy.uni-duesseldorf.de>
To: s.rahtz@ELSEVIER.CO.UK
CC: twg-tds@shsu.edu
Subject: TUG Unix CD: HTML documentation
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Hi Sebastian et al.,
last night I've assembled the first package mostly containing
texi2html and HTML documentation converted from Texinfo sources.
Where shall I upload the .tar.gz file?
Note: What exactly should or should not go into texmf/doc/html/
has been debated at length repeatedly on TWG-TDS and probably is
more or less up to the installer. So, I have taken the liberty
to occupy texmf/doc/html/ for a start and also added a little
framework such as putting a few icons into texmf/doc/html/icons.
Please check my README and index.html files, if you find them
acceptable/suitable. These may have to be edited whenever more
documentation is added.
Cheers, Ulrik.
--------
Package: doc-html
Who: UV, 1996/01/21
What:
* texi2html (Perl script, system independent)
* faq2html.el (converter for UK TUG TeX FAQ)
* tds2texi.el (converter for TDS draft)
* index pages for texmf/doc/html/
* basic icons for texmf/doc/html/
* documentation converted with texi2html:
- TDS draft (v0.999, also Texinfo and Info)
- UK TUG TeX FAQ (v2.0d, source from RF privately)
- comp.fonts FAQ (dated, from ftp://jasper.ora.com)
- Fontname 2.0 (source from teTeX-lib)
- Kpathsea 2.6 (source from teTeX-src)
- Dvips 5.58f (source from teTeX-src)
- Eplain 2.6 (source from CTAN/3 CD)
- Texinfo 3.6 (source from teTeX-lib)
- Auc-TeX 9.3b (source from CTAN/3 CD)
Size: 720 KB (tar.gz), 3 MB (unpacked)
File List:
----------
bin/texi2html
man/man1/texi2html.1
emacs/lisp/faq2html.el
emacs/lisp/tds2texi.el
texmf/doc/html/README
texmf/doc/html/index.html
texmf/doc/html/icons
texmf/doc/html/icons/README
texmf/doc/html/icons/back.xbm
texmf/doc/html/icons/invisible.xbm
texmf/doc/html/icons/mf.xbm
texmf/doc/html/icons/tex.xbm
info/tds.texi
info/tds.info
texmf/doc/html/tds/
texmf/doc/html/texfaq/
texmf/doc/html/fontfaq/
texmf/doc/html/fontname/
texmf/doc/html/kpathsea/
texmf/doc/html/dvips/
texmf/doc/html/eplain/
texmf/doc/html/texinfo/
texmf/doc/html/auctex/
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Feb 1996 05:08:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 21 Feb 1996 11:05:32 GMT
Message-ID: <199602211105.LAA18104@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: vieth@thphy.uni-duesseldorf.de
CC: twg-tds@shsu.edu
Subject: Re: TUG Unix CD: HTML documentation
References: <199602211050.LAA00173@lancelot.thphy.uni-duesseldorf.de>
Ulrik Vieth writes:
> last night I've assembled the first package mostly containing
> texi2html and HTML documentation converted from Texinfo sources.
> Where shall I upload the .tar.gz file?
excellent. put on incoming on ftp.tex.ac.uk, please
> more or less up to the installer. So, I have taken the liberty
> to occupy texmf/doc/html/ for a start and also added a little
> framework such as putting a few icons into texmf/doc/html/icons.
i think we are all not entirely sure how this should all work, so i
think your approach of "this is what i think, i have done it, let
anyone who objects say so" is probably the best!
> bin/texi2html
bin/share, surely. then everything in bin/share can be linked back to
bin/system at the last minute
> man/man1/texi2html.1
non-ISO. but ok for man
> texmf/doc/html/index.html
.htm, for ISO? or let it fall through
> texmf/doc/html/icons/invisible.xbm
non-ISO.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Feb 1996 05:18:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 21 Feb 1996 11:14:49 GMT
Message-ID: <199602211114.LAA18167@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: TDS / Unix CD work
References: <199602211037.LAA00160@lancelot.thphy.uni-duesseldorf.de>
> Well, so it really seems better to delay MetaPost for web2c-7.0,
> doesn't it? It that case, I'd also suggest delaying Omega, ML-TeX,
> e-TeX as well since including them might have similar implications
> AFAIK, web2c-7.0 will at least include MetaPost and tex -mltex.
it does seem sensible to wait...
> I don't know about Omega, but I suspect it might imply some more
> substantial changes to get everything up to Unicode/16bit etc.
what the implications are for kpathsea, i am not sure; but probably
not many.
> > how is the Dante CD organized? compressed? CTAN layout?
>
> CTAN layout, snapshot taken on 1995/11/01. Everything is packed
> into zip files by directory. So I have to do things like
ugh. thats no advance at all!
> It works, but it's so incovenient that it makes a strong case
> for using RockRidge to put long file names on the CD.
beware. i noticed yesterday that
config.hlct
gets ISOized to config.001, so don't assume that ISOizing is always
rational! (this is the algorithm in the mkisofs program i have, anyway)
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Feb 1996 05:23:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 21 Feb 1996 12:18:32 +0100
Message-ID: <199602211118.MAA00209@lancelot.thphy.uni-duesseldorf.de>
To: s.rahtz@elsevier.co.uk
CC: twg-tds@shsu.edu
Subject: Re: TUG Unix CD: HTML documentation
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sebastian writes:
>> bin/texi2html
> bin/share, surely. then everything in bin/share can be linked back to
> bin/system at the last minute
Yes, sure, but that wasn't decided yet last night, when I did it.
>> man/man1/texi2html.1
> non-ISO. but ok for man
>> texmf/doc/html/index.html
> .htm, for ISO? or let it fall through
No, please don't truncate this to .htm. Most of the files below
texmf/doc/html/whatever don't fit into 8+3. All the filenames
are constructed as <title>_<nnn>.html automatically by texi2html
and all the links will fail if you rename them. Remeber that
this directory is indented to be read by (Unix) WWW browsers
which should be capable of handling them. If you feel strongly
about this in texmf/doc/html, then put the whole tree elsewhere,
i.e. at a top-level html directory.
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Feb 1996 05:33:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 21 Feb 1996 11:31:29 GMT
Message-ID: <199602211131.LAA18432@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: vieth@thphy.uni-duesseldorf.de
CC: twg-tds@shsu.edu
Subject: Re: TUG Unix CD: HTML documentation
References: <199602211105.LAA18104@cadair.elsevier.co.uk> <199602211118.MAA00209@lancelot.thphy.uni-duesseldorf.de>
Ulrik Vieth writes:
(when does this top being TWG-TDS business? do others want to read
all this? should we shift to another list? views?)
> >> texmf/doc/html/index.html
> > .htm, for ISO? or let it fall through
>
> No, please don't truncate this to .htm. Most of the files below
> texmf/doc/html/whatever don't fit into 8+3. All the filenames
> are constructed as <title>_<nnn>.html automatically by texi2html
> and all the links will fail if you rename them. Remeber that
> this directory is indented to be read by (Unix) WWW browsers
eh? why only Unix? PC people have Netscape too!
> which should be capable of handling them. If you feel strongly
> about this in texmf/doc/html, then put the whole tree elsewhere,
> i.e. at a top-level html directory.
well, this *is* a TDS question. surely we should be sure that the TDS
tree contains ISO conformant files?
i feel inclined to leave them as .html and let them fall through to
.htm, at this stage
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Feb 1996 05:49:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 21 Feb 1996 12:47:40 +0100
Message-ID: <199602211147.MAA00248@lancelot.thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Re: TUG Unix CD: HTML documentation
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sebastian writes:
>> which should be capable of handling them. If you feel strongly
>> about this in texmf/doc/html, then put the whole tree elsewhere,
>> i.e. at a top-level html directory.
> well, this *is* a TDS question. surely we should be sure that the TDS
> tree contains ISO conformant files?
> i feel inclined to leave them as .html and let them fall through to
> .htm, at this stage
Well, index.html vs. index.htm isn't the real problem. The real
problem is what do you do with a directory full of files named
as "kpathsea_<nnn>.html" where <nnn>=1..45 or "toc". Surely not
truncate them all to 8+3? Same problem arises for all documents
whose title is more then 4 characters, i.e. nearly all of them.
You'll have to regard these texi2html-generated files as similar
to Info files which also don't care about 8+3 names.
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Feb 1996 05:57:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 21 Feb 1996 11:56:16 GMT
Message-ID: <199602211156.LAA18990@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: TDS / Unix CD work
References: <199602202246.AA25071@terminus.cs.umb.edu>
kb@terminus.cs.umb.edu writes:
> we dont have an instalation script :-{
>
> We're not going to query the user as to what they want to install off
> the CD? Just blast the whole thing to the hard disk? I don't think
> people will be happy.
i am hoping someone will write an install script. if they dont,
people will still pay their $10-20, i promise
> BTW please consider the fact that i cant have subdirectories under
> texmf/tex/latex/psnfss (remember that discussion?), so how do i divide
> up this stuff?
>
> What stuff? I'm confused. if you're talking about the latest support
> files, didn't we conclude the only feasible solution was to stuff
> everything into that one directory?
i mean that the LaTeX files for Lucida Bright cannot go in
texmf/tex/latex/psnfss/lucbr (as one might wish) because we said it
was one level only.
> BTW (2), i am breaking down the texmf/dvips directory into
> texmf/dvips/<package> (ie starting with base), in order to make it
> quite clear what comprises eg pstricks and what does not. this works,
> but will screw `plain' dvips users, i suspect. does anyone think i am
> being over-hard?
>
> Do you mean tex/dvips/<package>? I don't see why pstricks should be
> under dvips. It doesn't come with it.
no, i mean texmf/dvips/<package>. dvips header files for packages
the point is that pstricks comes with half a dozen PS prolog files,
which dvips needs to see. so i put them in texmf/dvips/pstricks, but
the corollary of that was to put the standard stuff in texmf/dvips/base
> I don't see why plain users will be screwed, but then I guess I
i mean dvips, rather than dvipsk, users, who wont see the subdirectories
> really understand what you're doing :-). And yes, if you are going to
> make dvips/psfonts unusable for plain folks, I think you are being
> overhard :-).
no i dont mean *that* sort of plain, i mean "non-kpathsea" plain
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Feb 1996 06:23:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 21 Feb 96 12:21:25 GMT
Message-ID: <9602211221.AA15036@r8.cs.man.ac.uk>
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TDS / Unix CD work
> the point is that pstricks comes with half a dozen PS prolog files,
> which dvips needs to see. so i put them in texmf/dvips/pstricks,
Are they really dvips-specific I though at least most of them would
work as long as the dvi->ps driver had *some* mechanism of getting a
header file into the final PS output?? Of course if you put them
somewhere else, then you still need to tell dvips where to find them
so ...
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Feb 1996 06:23:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 21 Feb 96 12:16:53 GMT
Message-ID: <9602211216.AA15027@r8.cs.man.ac.uk>
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: vieth@thphy.uni-duesseldorf.de
Subject: Re: TUG Unix CD: HTML documentation
> i feel inclined to leave them as .html and let them fall through to
> .htm, at this stage
If I understood Ulrik's description then `falling through' will not
produce a set of links that is useable on an ISO/DOS system.
> All the filenames
> are constructed as <title>_<nnn>.html automatically by texi2html
> and all the links will fail if you rename them.
so presumably when truncated to 8+3 the various <title>_<nnn> will
typically all look like the same file, <titl> ?
I hate DOS:-)
However it would be nice to at least ensure that for any new files
that are created in the TDS part of the CD at least have unique names
when truncated to 8+3.
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Feb 1996 06:54:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 21 Feb 1996 12:52:09 GMT
Message-ID: <199602211252.MAA19629@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: TUG Unix CD: HTML documentation
References: <9602211216.AA15027@r8.cs.man.ac.uk>
David Carlisle writes:
>
> > i feel inclined to leave them as .html and let them fall through to
> > .htm, at this stage
>
> If I understood Ulrik's description then `falling through' will not
> produce a set of links that is useable on an ISO/DOS system.
yes. it'll be garbage in DOS and Mac. it needs a health warning
>
> so presumably when truncated to 8+3 the various <title>_<nnn> will
> typically all look like the same file, <titl> ?
no, they are not just truncated. the ISOization allocates unique
names, somehow
> However it would be nice to at least ensure that for any new files
> that are created in the TDS part of the CD at least have unique names
> when truncated to 8+3.
someone needs to rewrite texi2html to write ISO-compatible names. but
its better to do that than hack the files by hand!
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Feb 1996 07:18:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 21 Feb 1996 14:17:55 +0100
Message-ID: <199602211317.OAA00391@lancelot.thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: TUG Unix CD: HTML documentation
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
David wrote:
>> i feel inclined to leave them as .html and let them fall through to
>> .htm, at this stage
> If I understood Ulrik's description then `falling through' will not
> produce a set of links that is useable on an ISO/DOS system.
It might work as long as we're talking only about index.html files
in various levels of texmf/doc/ since it would be possible to get
along if they are only connected by links to a directory or ".."
>> All the filenames
>> are constructed as <title>_<nnn>.html automatically by texi2html
>> and all the links will fail if you rename them.
> so presumably when truncated to 8+3 the various <title>_<nnn> will
> typically all look like the same file, <titl> ?
> I hate DOS:-)
I hate having to care about DOS restrictions when producing
a Unix CD. I think the options we have are these:
1) If the dogma is that everything below texmf/doc/ must be 8+3,
then the texi2html-documentation belongs outside texmf/doc/.
That's exactly the same problem we would face in the case of
texmf/doc/info/ which is already in a separete info/ tree.
In this case, you can just move the whole tree and edit the
README and index files while everything else I produced can
remain unchanged.
2) If anyone wants to have something similar suitable for DOS,
you're welcome to start by (a) hacking the texi2html program
to produce .htm instead of .html in the internal links and
(b) regenerate everything I produced last night again from
the Texinfo sources (after having renamed them to a basename
that's no longer than 4 characters). Any volunteers for that?
If not, forget the idea!
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Feb 1996 14:34:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 21 Feb 1996 21:33:36 +0100
Message-ID: <199602212033.VAA12522@spock.iti.informatik.th-darmstadt.de>
From: Joachim Schrod <jschrod@acm.org>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TUG Unix CD: HTML documentation
References: <199602211050.LAA00173@lancelot.thphy.uni-duesseldorf.de> <199602211105.LAA18104@cadair.elsevier.co.uk>
>>>>> "SR" == Sebastian Rahtz <s.rahtz@elsevier.co.uk> writes:
SR> Ulrik Vieth writes:
>> texmf/doc/html/icons/invisible.xbm
SR> non-ISO.
OK, I bite. I find this whole ISO business complete nonsense for a CD
targeted to major Unix platforms.
As far as I understand, if there is a file foo45678.bar on the CD, and
the CD is mounted with Rock Ridge Extension in effect (as sebastian
wrote it should have), a request for foo456789.bar will not succeed.
If that's dead wrong 'though, the rest of this mail is garbage.
Let's suppose we have interesting styles with non-ISO file names,
e.g., chapterbib.sty or cwebarray.sty. Their user interface is very
clearly documented in several papers, sometimes even books:
\usepackage{chapterbib}
\usepackage{cwebarray}
If these files are put on the CD as chapterb.sty or cwebarra.sty,
LaTeX won't find them. Bad luck, isn't it? So we prevent the usage of
such styles just because some idiot at ISO insisted on such brain-dead
standards!
Fight ISO! Go out on the street! Come to a rally!
Make a usable TeX CD... :-)
Joachim
PS: Hope our mailer problems have been repaired by now, and you won't
get tons of exemplars of this mail.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: jschrod@acm.org
Roedermark, Germany
Net & publication consultant
================================================================================
From owner-twg-tds@shsu.edu Wed, 21 Feb 1996 17:24:21 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 21 Feb 1996 15:23:42 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199602212323.PAA15302@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: TUG Unix CD: HTML documentation
>>>>> "SR" == Sebastian Rahtz <s.rahtz@elsevier.co.uk> writes:
SR> Ulrik Vieth writes:
>> texmf/doc/html/icons/invisible.xbm
SR> non-ISO.
OK, I bite. I find this whole ISO business complete nonsense for a CD
targeted to major Unix platforms.
As far as I understand, if there is a file foo45678.bar on the CD, and
the CD is mounted with Rock Ridge Extension in effect (as sebastian
wrote it should have), a request for foo456789.bar will not succeed.
If that's dead wrong 'though, the rest of this mail is garbage.
Let's suppose we have interesting styles with non-ISO file names,
e.g., chapterbib.sty or cwebarray.sty. Their user interface is very
clearly documented in several papers, sometimes even books:
\usepackage{chapterbib}
\usepackage{cwebarray}
If these files are put on the CD as chapterb.sty or cwebarra.sty,
LaTeX won't find them. Bad luck, isn't it? So we prevent the usage of
such styles just because some idiot at ISO insisted on such brain-dead
standards!
Funny you should say that after what the idiots (my near neighbors)
who designed DOS file names forced us to do with the TDS.
The most general answer is to use a postinstall script like the ones
that the SVR4 package use. Then you can name the stuff on the CDROM
anything you like and provide a rationalized directory structure
somewhere with the names got right.
It would theoretically be possible to mount the CDROM directly on
the $TEXMF mount point, but it would sure be slow. THat means that
virtually all users will want to extract the files onto a faster
storage device. In the course of the extraction and installation, or
just after it, the rational names and directory structures can
be applied.
I am doing that with the Solaris2.5 stuff. The regular files
are (witn a few exceptions for purely Unix references) all kept
to 8+3 names, but the complete pkgmap links them to a more
reasonable organization---supplier first, *.300pk, all the stuff
that got thrown out with the DOS bathwater.
Fight ISO! Go out on the street! Come to a rally!
I must admit that sounds like fun. But I'd rather fight DogWindows
first.
Make a usable TeX CD... :-)
By the way, you are welcome to the 2.5 executables I put together.
It's kpathsea2.6 stuff, all done up into shared object libraries.
I hope to get to looking at the new web2c stuff fairly soon.
I would still suggest that people look at SVR4 packaging. The objections
I have seen to it assume several things about the system that are
not true. It is not Solaris-specific, it is not designed solely
to deal with packages full of binaries, and it does not force the
installer to put everything into /opt or into any other place, at least
not in the Solaris2.5 version. Even the more rigid Solaris2.4 version
can be beaten into submission.
--
%=======================================================================%
| 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, 22 Feb 1996 01:17:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 22 Feb 1996 07:13:55 GMT
Message-ID: <199602220713.HAA27559@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: TUG Unix CD: HTML documentation
References: <199602211050.LAA00173@lancelot.thphy.uni-duesseldorf.de> <199602211105.LAA18104@cadair.elsevier.co.uk> <199602212033.VAA12522@spock.iti.informatik.th-darmstadt.de>
> OK, I bite. I find this whole ISO business complete nonsense for a CD
> targeted to major Unix platforms.
its targeted at Unix platforms, yes, but for everyone else as
well. its a TDS CD, looked at from another perspective
> As far as I understand, if there is a file foo45678.bar on the CD, and
> the CD is mounted with Rock Ridge Extension in effect (as sebastian
> wrote it should have), a request for foo456789.bar will not succeed.
> If that's dead wrong 'though, the rest of this mail is garbage.
it might be. what happens is that foo45678.bar is ISOized, but the
full name is kept in a separate record. RR systems will read that
record, and thus retrieve the right file
> Make a usable TeX CD... :-)
i have. i used it at home for the last 2 evenings. it all works
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 22 Feb 1996 01:29:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 22 Feb 1996 07:25:58 GMT
Message-ID: <199602220725.HAA27583@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: TUG Unix CD: HTML documentation
References: <199602212323.PAA15302@june.cs.washington.edu>
> It would theoretically be possible to mount the CDROM directly on
> the $TEXMF mount point, but it would sure be slow. THat means that
its surprisingly reasonable, actually. mounted on my 486 Linux, i can
run LaTeX quite humanly. the ls-R database means no searching after
the startup, so the CD isnt hammered that much
> virtually all users will want to extract the files onto a faster
> storage device. In the course of the extraction and installation, or
> just after it, the rational names and directory structures can
> be applied.
yes, but that makes the installation script considerably more
sophisticated.
> I am doing that with the Solaris2.5 stuff. The regular files
> are (witn a few exceptions for purely Unix references) all kept
> to 8+3 names, but the complete pkgmap links them to a more
> reasonable organization---supplier first, *.300pk, all the stuff
> that got thrown out with the DOS bathwater.
but that means your users see a non-standard system when they use
it. i think thats bad news, they wont be able to talk to the rest of
us.
now if the package stuff you used were free and portable to all other
Unixes (or maybe it is?)..
> I would still suggest that people look at SVR4 packaging. The objections
> I have seen to it assume several things about the system that are
i'll try anything thats portable.
are there any volunteers to put together an install/deinstall system
for me? based on tar listings, ie package XXX has a complete tar
listing of the files that make it up, rooted at texmf/, so one needs
to present all the known packages, and copy them on demand to some
place chosen on the hard disk
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 22 Feb 1996 04:02:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 22 Feb 1996 10:59:19 +0100
Message-ID: <9602220959.AA10750@macbeth.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: more thoughts on .htm vs .html
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Just a few thoughts before I embark on trying to get some real work done,
i.e. write up a physics paper that has been delayed for too long already...
1.) I heard that Netscape on DOS/Win might be clever enough to find
a file "index.htm" on the local filesystem even if a link points
to "index.html". Whether this means that it does an 8+3 truncation
of the requested file name internally or whether it just knows
about the extension ".html" as a special case, I don't know.
If the ISOization process would mean that a file "index.html"
under RockRidge really showed up as "index.htm" under ISO and
not as something completely different, this might at least be
some sort of kludgy solution to provide some index files in
the texmf/doc/ tree.
2.) Concerning Joachim's complaint regarding long filenames for TeX
packages such as "chapterbib" not being found when stored with
a truncated name: I vaguely recall having read somewhere that
some DOS TeX implementations (e.g. emTeX) might be clever enough
to try various alternatives, i.e. both an 8+3 or an 5+3+3
truncated name, when a long file name is requested via \input.
GNU Emacs under DOS also seems to get along when the basename
of an Elisp package is truncated to 8 chars as long as it is
unique. However I don't know what would happen to dvips.info
when the internal links point to dvips.info-{1,2,3}.
In any case, I thing it would be the best approach for a CD targetted
primarily at Unix to use long filenames under RockRidge and simply
rely on the cleverness of DOS implementations to get along somehow
with truncated file names (*if* they are really truncated and not
mapped to something completely different).
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Thu, 22 Feb 1996 04:24:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 22 Feb 1996 11:21:45 +0100
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9602221021.AA17707@wega.informatik.uni-hannover.de>
To: TWG-TDS@SHSU.edu
Subject: Re: TUG Unix CD: HTML documentation
> It would theoretically be possible to mount the CDROM directly on
> the $TEXMF mount point, but it would sure be slow. THat means that
> virtually all users will want to extract the files onto a faster
> storage device. In the course of the extraction and installation, or
> just after it, the rational names and directory structures can
> be applied.
In fact, one of our aims was that tex, latex, xdvi, dvips, ... all should
run directly from the CD. Sebastian made some tests and he told me that
performance was not too bad.
> By the way, you are welcome to the 2.5 executables I put together.
> It's kpathsea2.6 stuff, all done up into shared object libraries.
Unless they are made from the teTeX sources, they are of no use for us.
teTeX's kpathsea has some features from the next web2c release, like
relative directory names in ls-R. I.e. the directory names in ls-R
start with ./tex/latex/... instead of being absolute. Together with
the selfdir feature, the CD may be mounted anywhere and used without
setting any environment variable.
Thomas
================================================================================
From owner-twg-tds@shsu.edu Thu, 22 Feb 1996 04:37:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 22 Feb 1996 11:36:54 +0100
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9602221036.AA17719@wega.informatik.uni-hannover.de>
To: TWG-TDS@SHSU.edu
Subject: Re: TUG Unix CD
> are there any volunteers to put together an install/deinstall system
> for me? based on tar listings, ie package XXX has a complete tar
> listing of the files that make it up, rooted at texmf/, so one needs
> to present all the known packages, and copy them on demand to some
> place chosen on the hard disk
If all extra packages are available as .tar.gz, then they can be installed
with a modified (extended) version of teTeX's install.sh. There 'just'
need to be opend a new series (e.g. contrib). The script is *very*
intellignet (e.g. calculates disk space requirements) and generates
the file lists in texmf/lists. These lists could be used to remove
packages.
Please have a look at it. Its advantage is that is is simple (i.e. a
single shell script) and portable.
Thomas
================================================================================
From owner-twg-tds@shsu.edu Thu, 22 Feb 1996 05:34:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 22 Feb 96 11:33:55 GMT
Message-ID: <9602221133.AA03827@r8h.cs.man.ac.uk>
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: more thoughts on .htm vs .html
Ulrick>
2.) Concerning Joachim's complaint regarding long filenames
for TeX
In any case, I thing it would be the best approach for a CD targetted
primarily at Unix to use long filenames under RockRidge and simply
rely on the cleverness of DOS implementations to get along somehow
with truncated file names (*if* they are really truncated and not
mapped to something completely different).
Yes, I agree, I also have a few such of these long name packages,
longtable, enumerate, ... Emtex and I think most other DOS TeX's do
correctly truncate (emtex tries both truncation and first5+last3)
however if an iso file system might show longtable.sty as some random
unique name that happens to be 8+3 then it might be a good idea to put
longtabl.sty on the CD as well. (You could make a link I suppose, but
perhaps you can not rely on that doing anything sensible under an ISO
system either...)
David
================================================================================
From owner-twg-tds@shsu.edu Thu, 22 Feb 1996 06:26:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 22 Feb 1996 12:23:38 GMT
Message-ID: <199602221223.MAA00417@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
CC: twg-tds@shsu.edu
Subject: Re: more thoughts on .htm vs .html
References: <9602220959.AA10750@macbeth.uni-duesseldorf.de>
> 1.) I heard that Netscape on DOS/Win might be clever enough to find
> a file "index.htm" on the local filesystem even if a link points
> to "index.html". Whether this means that it does an 8+3 truncation
> of the requested file name internally or whether it just knows
> about the extension ".html" as a special case, I don't know.
but that doesnt help the other long names, does it
> If the ISOization process would mean that a file "index.html"
> under RockRidge really showed up as "index.htm" under ISO and
it does
> 2.) Concerning Joachim's complaint regarding long filenames for TeX
> packages such as "chapterbib" not being found when stored with
> a truncated name: I vaguely recall having read somewhere that
the news is worse than i expected. i have mounted my RRIP teTeX CD
under Linux, and when i look at it in a DOS window, i see
Volume in drive D is /
Directory of D:\CDROM\TEXMF\TEX\LATEX\TOOLS
[.] [..] AFTER~RP.STY ARRAY.STY DCOLUMN.STY
DELARRAY.STY E.TEX ENUME~9X.STY FONTSMPL.STY FONTSMPL.TEX
FTNRIGHT.STY H.TEX HHLINE.STY INDEN~7J.STY LAYOUT.STY
LONGT~76.STY MULTICOL.STY RAWFONTS.STY S.TEX SHOWKEYS.STY
SOMEDEFS.STY TABULARX.STY THB.STY THC.STY THCB.STY
THEOREM.STY THM.STY THMB.STY THP.STY TRANS.TBL
VARIOREF.STY VERBATIM.STY VERBTEST.TEX X.TEX XR.STY
XSPACE.STY
36 file(s) 161,540 bytes
0 bytes free
not quite what the doctor ordered, is it?
or is this an artefact of
loading the CD in a Linux DOS box? hmm, let me try elsewhere...
....
yes, i loaded the CD on a DOS machine (ugh, i had to wash my hands
afterwards) and saw LONGTABL.STY and so on.
so in fact we are OK. the DOS people see what they want. what will
*not* work is if you copy from a DOS-viewed CD to Unix, because you
will take the truncation with you
do we have a VMS volunteer to see what they see?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 22 Feb 1996 06:37:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 22 Feb 1996 12:33:27 GMT
Message-ID: <199602221233.MAA00473@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: TUG Unix CD, and ISOization
References: <9602221036.AA17719@wega.informatik.uni-hannover.de>
> If all extra packages are available as .tar.gz, then they can be installed
> with a modified (extended) version of teTeX's install.sh. There 'just'
> need to be opend a new series (e.g. contrib). The script is *very*
> intellignet (e.g. calculates disk space requirements) and generates
> the file lists in texmf/lists. These lists could be used to remove
> packages.
ah, sorry, i should have thought of that. i shall examine it more
carefully (its amazing how many things you have thought of in teTeX,
its like an Aladdin's cave...)
re ISOed names, the kind of effect that ISOization has on Ulrik's
html files is like this:
Using TEXFAQ_1.000;1 for ./texmf/doc/html/texfaq/texfaq_17.html (texfaq_16.html)
Using TEXFAQ_1.001;1 for ./texmf/doc/html/texfaq/texfaq_16.html (texfaq_15.html)
Using TEXFAQ_1.002;1 for ./texmf/doc/html/texfaq/texfaq_15.html (texfaq_14.html)
Using TEXFAQ_1.003;1 for ./texmf/doc/html/texfaq/texfaq_14.html (texfaq_13.html)
Using TEXFAQ_1.004;1 for ./texmf/doc/html/texfaq/texfaq_13.html (texfaq_12.html)
Using TEXFAQ_1.005;1 for ./texmf/doc/html/texfaq/texfaq_12.html (texfaq_11.html)
Using TEXFAQ_1.006;1 for ./texmf/doc/html/texfaq/texfaq_11.html (texfaq_10.html)
Using TEXFAQ_1.007;1 for ./texmf/doc/html/texfaq/texfaq_10.html (texfaq_1.html)
really, texi2html could be rewritten easily to make this a lot
easier...
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 22 Feb 1996 07:02:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 22 Feb 1996 14:01:27 +0100
Message-ID: <9602221301.AA11236@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: TUG Unix CD, and ISOization
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sebastian writes:
> re ISOed names, the kind of effect that ISOization has on Ulrik's
> html files is like this:
> Using TEXFAQ_1.000;1 for ./texmf/doc/html/texfaq/texfaq_17.html (texfaq_16.html)
> Using TEXFAQ_1.001;1 for ./texmf/doc/html/texfaq/texfaq_16.html (texfaq_15.html)
> Using TEXFAQ_1.002;1 for ./texmf/doc/html/texfaq/texfaq_15.html (texfaq_14.html)
> Using TEXFAQ_1.003;1 for ./texmf/doc/html/texfaq/texfaq_14.html (texfaq_13.html)
> Using TEXFAQ_1.004;1 for ./texmf/doc/html/texfaq/texfaq_13.html (texfaq_12.html)
> Using TEXFAQ_1.005;1 for ./texmf/doc/html/texfaq/texfaq_12.html (texfaq_11.html)
> Using TEXFAQ_1.006;1 for ./texmf/doc/html/texfaq/texfaq_11.html (texfaq_10.html)
> Using TEXFAQ_1.007;1 for ./texmf/doc/html/texfaq/texfaq_10.html (texfaq_1.html)
> really, texi2html could be rewritten easily to make this a lot
> easier...
Interesting! Now, the question is what the ISOization would do if
the files were name just "faq_xx.html" instead of "texfaq_xx.html".
Would that at least result in "FAQ_xx.HTM" or in "FAQ_xx.000"?
That is, does it just invent new names when the basename exceeds
8 characters or does it do that as well for the extension part?
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Thu, 22 Feb 1996 07:22:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 22 Feb 1996 13:18:43 GMT
Message-ID: <199602221318.NAA01518@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: TUG Unix CD, and ISOization
References: <9602221301.AA11236@macbeth.uni-duesseldorf.de>
> Interesting! Now, the question is what the ISOization would do if
> the files were name just "faq_xx.html" instead of "texfaq_xx.html".
> Would that at least result in "FAQ_xx.HTM" or in "FAQ_xx.000"?
> That is, does it just invent new names when the basename exceeds
> 8 characters or does it do that as well for the extension part?
>
i can send you the software if you like, you point it at a directory,
and it makes an ISO image as a file. it tells you what its doing.
i think the point is that texfaq_15 and texfaq_16 both truncate to
texfaq_1; you miss the boat by one character. just removing the _
helps!
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 22 Feb 1996 07:23:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 22 Feb 1996 14:21:38 +0100
Message-ID: <9602221321.AA11274@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: more thoughts on .htm vs .html
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sebastian writes:
> the news is worse than i expected. i have mounted my RRIP teTeX CD
> under Linux, and when i look at it in a DOS window, i see
> not quite what the doctor ordered, is it?
> or is this an artefact of
> loading the CD in a Linux DOS box? hmm, let me try elsewhere...
Strange! Did you consider writing a bug report to the author of
the Linux DOSEMU? Could it be that it tries to access the CD as
a msdos filesystem instead of an iso filesystem? I've never used
DOSEMU myself, so I'm just guessing here.
Cheers, Ulrik.
P.S. The "Reply-To" line inserted automatically by the list server
seems to cause some mailers (e.g. RMAIL) to produce two header lines,
i.e. both "To: TWG-TDS" and "CC: TWG-TDS". Please try to make sure
to remove the CC header to avoid sending redundant extra copies.
================================================================================
From owner-twg-tds@shsu.edu Thu, 22 Feb 1996 10:50:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 22 Feb 1996 16:46:13 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: <960222164613.21e37cd9@vms.rhbnc.ac.uk>
Subject: Re: more thoughts on .htm vs .html
>> do we have a VMS volunteer to see what they see?
Put it t'post, lad!
================================================================================
From owner-twg-tds@shsu.edu Thu, 22 Feb 1996 11:10:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 22 Feb 1996 18:06:33 +0100
Message-ID: <9602221706.AA11528@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: TUG Unix CD, and ISOization
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sebastian writes:
> i think the point is that texfaq_15 and texfaq_16 both truncate to
> texfaq_1; you miss the boat by one character. just removing the _
> helps!
Well, that doesn't mean anything. It just happens to be the case for
"texfaq" whiere the basename is 6 character and the numeric part is
two-digits only. However, there are other cases where the numeric
part goes into three digits (e.g. for the Texinfo manual) or where
the basename is even longer (e.g. "texinfo", "kpathsea", "fontname").
It appears that it would really take careful tuning to make sure
that all texi2html-generated filenames stay within 8 characters
by shortening the basename and the same would apply for info/
if you wanted to make that usable for Emacs under DOS as well
(e.g. by using "dvips-{1,2,3}" instead of "dvips.info-{1,2,3}").
What surprises me a little that you make so much fuss about fixing
the HTML file names so that they could go into an ISO-conformant
TDS tree below texmf/doc/html/, while you take it for granted or
otherwise don't seem to care that Info files would be non-conformant
just because they happen to be in info/ instead of texmf/doc/info/.
IMHO, it should be done right for either both or none of them.
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Fri, 23 Feb 1996 01:46:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 23 Feb 1996 07:37:47 GMT
Message-ID: <199602230737.HAA05445@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: TUG Unix CD, and ISOization
References: <9602221706.AA11528@macbeth.uni-duesseldorf.de>
> What surprises me a little that you make so much fuss about fixing
> the HTML file names so that they could go into an ISO-conformant
> TDS tree below texmf/doc/html/, while you take it for granted or
> otherwise don't seem to care that Info files would be non-conformant
> just because they happen to be in info/ instead of texmf/doc/info/.
> IMHO, it should be done right for either both or none of them.
but info is explicitly not in the TDS tree, like man. neither are
widely used on other platforms, are they? whereas html is very widely
used.
i am not that bothered, actually. unless someone *wants* to do the
work, i propose to leave it exactly as you gave it to me (and very
nice it is too!). i'd rather *some people* saw *somethhing*
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 23 Feb 1996 17:32:02 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 23 Feb 1996 15:28:23 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199602232328.PAA25340@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: TUG Unix CD: HTML documentation
On the use of CD as a resource for TeX support files.
Sebastian's experience suggests that some CD players are a great
deal more equal than others. I find that with a single flat directory
I get good results, but with anything beyond that the minutes fly
like hours. That, however, may be platform specific :-{
The selfdir feature.
This makes me even more eager to wrap up what I am presently
doing and get to the new version. I was just worrying over that
very question a week ago and now you assure me that it is all
taken care of.
I think I will move out to the sidelines on this effort for now.
But I shall watch your progress with interest.
--
%=======================================================================%
| 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, 26 Feb 1996 03:50:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 26 Feb 1996 09:44:12 GMT
Message-ID: <199602260944.JAA17392@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: TUG Unix CD: HTML documentation
References: <199602232328.PAA25340@june.cs.washington.edu>
> deal more equal than others. I find that with a single flat directory
> I get good results, but with anything beyond that the minutes fly
> like hours. That, however, may be platform specific :-{
but do you have an ls-R file? surely thats what makes the difference?
>
> I think I will move out to the sidelines on this effort for now.
> But I shall watch your progress with interest.
the more i think about this, i realize that we will none of us do a
proper job until all packages on CTAN come with a "expand me into TDs
format" script of some kind. without this, people like Pierrer,
myself, the 4alltex people etc, will waste time "installing" packages
which have to be redone whenever they are released.
roll on the TDS registry!
QUESTION
i am getting very confused over texmf/source and texmf/doc for .dtx
files. if you take a package with his
x.ins
x.dtx
sample.tex
readme
what files do you put in which directory in a really nice working TDS?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 26 Feb 1996 03:59:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 26 Feb 1996 09:55:45 GMT
Message-ID: <199602260955.JAA17462@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: TDS / Unix CD work
References: <9602211221.AA15036@r8.cs.man.ac.uk>
David Carlisle writes:
>
> > the point is that pstricks comes with half a dozen PS prolog files,
> > which dvips needs to see. so i put them in texmf/dvips/pstricks,
>
> Are they really dvips-specific I though at least most of them would
> work as long as the dvi->ps driver had *some* mechanism of getting a
> header file into the final PS output?? Of course if you put them
> somewhere else, then you still need to tell dvips where to find
oh *rats*, you are right of course. i am feeling drunk today
(metaphorically) so someone tell me what the correct generic place
for PS header files might be....
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 26 Feb 1996 04:11:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 26 Feb 1996 11:07:13 +0100
Message-ID: <199602261007.LAA00247@lancelot.thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Some comments on CTAN:info/tdscd
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Hi Sebastian et al.,
1. After so much discussion last week I gave in and regenerated all
the texi2html documentation to ensure that filenames remain uniqiue
when truncated to 8+3. While I was at it I also regenerated all the
Info files for the same reason. Expect my uploads at ftp.tex.ac.uk.
2. I had a look at the files you placed on CTAN:info/tdscd and noted
the following problems (some of this may be TDS releveant but most
of it is probably only of interest for Sebastian and Thomas):
* tdscd/isoed:
> Using MAKEFILE.000;1 for ./texmf/doc/latex/rotating/makefile (Makefile)
This conflict between a "Makefile" and "makefile" in the same
directory looks suspiciously like an installation problem that
should be resolved somehow, i.e. there shouldn't ever be more
than one [Mm]akefile in the same directory in the first place.
> Using DC.000;1 for ./texmf/dvips/base/dc.enc (DC.enc)
This conflict between "DC.enc" and "dc.enc" looks like a mixup of
the stuff that comes with fontname-2.0 and with the dvips sources.
If I remeber correctly, "DC.enc" and "EC.enc" are some old versions
of "dc.enc" and "cork.enc". This should also be cleaned up.
* tdscd/files:
> /teTeX/doc:
> german
>
> /teTeX/doc/german:
> koma-script
>
> /teTeX/doc/german/koma-script:
> scr_new1.dvi
[...]
> scrguide.dvi
Doesn't that belong into teTeX/texmf/doc/german ?
> /teTeX/texmf/bibtex/bib:
> README
> harvard
>
Where's mrabbrev.bib (from AMS-LaTeX)?
Where's xampl.bib (from BibTeX)?
> /teTeX/texmf/doc/babel:
Should be texmf/doc/generic/babel according to TDS.
> /teTeX/texmf/doc/dc:
Should be texmf/doc/fonts/dc. In fact, that directory already exists,
but the contents is slightly different. So what's messed up here?
BTW, it would be nice to include a DVI file of dcdoc.tex as well.
> /teTeX/texmf/doc/fontname:
> ChangeLog
> README
> fontname.dvi
Should be texmf/doc/fonts/fontname. I'm also doubtful whether
ChangeLog will be of interest for anyone, if the full sources
aren't kept here.
> /teTeX/texmf/doc/help:
> CTAN.sites
> TeX-FAQ
> TeX-index
> csname.txt
> ctan.dat
> tds.dvi
> unixtex.ftp
Should have subdirectories help/ctan, help/faq, etc. according
to TDS. At least, that's what the doc summary figure says.
I'd suggest to add the UK TUG FAQ here as well. It's certainly
better than the old Usenet FAQ.
> /teTeX/texmf/doc/latex/base:
> 00readme.txt
> Makefile.unx
> alltt.dtx
> alltt.ins
[...]
What are all the .dtx and .ins files doing here? Doesn't the TDS
say explicitly that thex belong into texmf/source/latex/base:
-- from tds.tex --
\item[\path|source|] for sources. This includes both traditional
program sources (for example, \application{Web2c} sources go in
\path|texmf/source/web2c|) and {\LaTeX} \path|dtx| sources (which go in
\path|texmf/source/latex|).
------------------
IMHO, texmf/doc/latex/base should only include the following:
- *.txt (perhaps not even all of them)
- *.err
- ltnews*.{tex,dvi}
- *guide.{tex,dvi}
- {small2e,sample2e}.tex (but also in tex/latex/base)
- *.dvi (for any other formatted source documentation)
The same applies for texmf/doc/latex/{graphics,tools}, except
that graphics should also include .ps files, not only .dvi.
> /teTeX/texmf/doc/latex/revtex:
This looks incomplete. There should be DVI files for all
man*.tex files, but there's probably no need for PS files.
> /teTeX/texmf/doc/latex/styles:
[...]
> here.doc
> index.doc
> ulem.doc
I believe these are old (pre-LaTeX2e) .doc (pre-.dtx) files
that should be LaTeXable somehow to produce DVI documentation.
They are not necessarily meant to be read in source form.
> /teTeX/texmf/doc/latex/umlaute:
> anleitung.dvi
> umlaute.dvi
Might this is belong into texmf/doc/latex/german perhaps?
(This package has been largely obsoleted by "inputenc" anyhow,
but who knows who might be relying on it...)
> /teTeX/texmf/doc/programs:
> dvipsk.dvi
> info-stnd.dvi
> info.dvi
> kpathsea.dvi
> makeinfo.dvi
Where's texinfo.dvi? I guess that would be more interesting
than makeinfo, info and info-stnd.
> /teTeX/texmf/fonts/tfm:
[...]
> bitstrea
> bitstream
Why both of these?
> dcbi0500.tfm
> dcbi0600.tfm
> ...
> dctt2074.tfm
> dctt2488.tfm
> jknappen
> monotype
Something must have been screwed up here!
> /teTeX/texmf/fonts/tfm/jknappen:
> tc
Ah yes, "dc" is missing here. There's where it should have been.
> /teTeX/texmf/fonts/tfm/public/mflogo:
logobf10.tfm is missing!
> /teTeX/texmf/sources:
TDS says "texmf/source" (without trailing `s')! Here's where I would
expect to see a lot of stuff in texmf/source/{generic,latex}/<package>/...
In fact, you might put all the teTeX/extra-distrib stuff from CTAN here.
> /teTeX/texmf/tex/initex:
> latex209
> /teTeX/texmf/tex/initex/latex209:
> initex
> /teTeX/texmf/tex/initex/latex209/initex:
> latex.tex
What's this doing here? "texmf/tex/initex" has been gone long since.
This stuff obviously belongs into texmf/tex/latex209/base/...
> /teTeX/texmf/tex/plain/base:
[...]
Should add at least logmac.tex (neeeded to TeX Knuth's errorlog.tex).
There are also some more variations of (l)list.tex in last year's
distribution of systems/knuth/local/lib. However, I'm unconvinced
that they should all go in the plain/base.
> /teTeX/texmf/tex/plain/misc:
[...]
> dcstdedt.tex
I don't think dcstdedt.tex makes much sense here. It's just an utility
file to create mf source files and should go whereever the corresponding
sources are, i.e. texmf/fonts/source/jknappen/dc/.
> epsf.tex
There's already an "epsf.tex" in tex/generic/dvips, so I don't think
it's needed here (unless it includes some extra hacks by Knuth, but
I guess that hacked version is called xepsf.tex).
> /teTeX/texmf/web2c:
> biglatex.fmt
> latex.fmt
> latex.log
Which languages for hypenation tables will be configured into the
distributed latex.fmt file on the CD? Remember that this is something
that users may well want to configure, so it would be a good idea to
set up texmf.cnf, so that format files by default will also be searched
in the corresponding directory on disk, no just on the CD.
General comments:
1. I would find the output of "find /teTeX -print | sort" easier
to check than the output of "ls -R /teTeX".
2. If time permits in the production cycle, it might be a good idea
to have someone (us?) check the contents of a preliminary CD
for problems, mismatches, mix-ups, etc. as mentioned above before
releasing it to the general public.
Cheers, Ulrik.
P.S. Another suggestions:
What about including other related software such as Acrobat readers
or WWW brosers for those Unix platforms where they are available?
They usually come as binary distributions anyway and sometimes even
include a fool-proof installation routine to set them up if they
don't come fully set up. (And if we can't get binaries for all
our platforms, one could say ``Hey Adobe, we've got 17 platforms,
you've got only 5, so when will you do something about the rest?'')
================================================================================
From owner-twg-tds@shsu.edu Mon, 26 Feb 1996 04:20:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 26 Feb 1996 11:17:50 +0100
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9602261017.AA02944@wega.informatik.uni-hannover.de>
To: TWG-TDS@SHSU.edu
Subject: Re: TUG Unix CD: HTML documentation
> i am getting very confused over texmf/source and texmf/doc for .dtx
> files. if you take a package with his
> x.ins
> x.dtx
> sample.tex
> readme
My opinion is:
x.ins x.dtx -> texmf/source/latex/<package>
sample.tex,readme,[x.dvi] -> texmf/doc/latex/<package>
The reason is: people will look for documentation in texmf/doc and
user documentation should be 'ready to preview/print' in .dvi format.
Sample files are most helpful in source there.
The nature of the .ins/.dtx is more source than documentation as others
already pointed out here.
Thomas
================================================================================
From owner-twg-tds@shsu.edu Mon, 26 Feb 1996 04:29:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 26 Feb 1996 11:27:57 +0100
Message-ID: <199602261027.LAA00259@lancelot.thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: TUG Unix CD: HTML documentation
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sebastian wrote:
> QUESTION
> i am getting very confused over texmf/source and texmf/doc for .dtx
> files. if you take a package with his
> x.ins
> x.dtx
> sample.tex
> readme
> what files do you put in which directory in a really nice working TDS?
I usually start by putting all these files as they come from CTAN
into texmf/source/latex/<package>. Then I procede as follows:
1. Run latex x.ins and move/copy all the files that are produced,
i.e. *.{fd,def,cls,clo,sty} and possibly *.tex (but not sample.tex)
to ../../../tex/latex/<package>
2. Run latex x.dtx to produce the documentation (it usually takes
several latex runs) and move/copy the resulting *.{dvi,ps} files
to ../../../doc/latex/<package>
3. Copy sample.tex, etc. to ../../../doc/latex/<package>.
4. Leave the readme in the source/<package> directory if it just
contains release notes and/or installation instructions.
Copy the readme to the doc/<package> directory only if it is
explicitly meant as end user documentation.
The remaining question is whether step 2. should be done using
a ltxdoc.cfg file containg \OnlyDescription or whether you want
full source documentation (including index and change history).
Cheers, Ulrik.
P.S. Ideally, the source/<package> directory should look the same
after completing the installation as it was when it came from CTAN.
================================================================================
From owner-twg-tds@shsu.edu Mon, 26 Feb 1996 04:46:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 26 Feb 1996 11:44:51 +0100
Message-ID: <199602261044.LAA00290@lancelot.thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: TUG Unix CD: HTML documentation
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
> what files do you put in which directory in a really nice working TDS?
Here's another answer to Sebastian's question.
Appended below is my first attempt at writing a mostly generic
installation Makefile, which I wrote for mflogo-1.5c in December.
Apart from the 'check-fonts' and 'install-fonts' targets, which
are very specific to mflogo, most of this should work for any
single-file .dtx package, if you change the variables PACKAGE
and SRCFILES, TEXFILES, DOCFILES appropriately.
Anyone interested in improving this?
Cheers, Ulrik.
## Makefile for the installation of the `mflogo' package:
##
## Note: this Makefile is *totally unsupported* as it is
## my first attempt at writing an installation Makefile.
##
## This assumes that you have a TDS-compliant Unix/Web2C
## installation, such as e.g. teTeX and that some common
## Unix utilities like 'cp', 'tar', 'mkdir', or 'test'
## are available.
## Usage:
##
## say 'make' or 'make all' to unpack the macros and produce
## the documentation
##
## say 'make install' to install everything except the fonts
##
## say 'make install-fonts' to install the fonts if needed
### package specifics (don't change!):
# package name, used in directories
PACKAGE = mflogo
# file names, used in dependencies
SRCFILES = mflogo.dtx mflogo.ins
TEXFILES = mflogo.sty Ulogo.fd
DOCFILES = mflogo.dvi
# install $(FONTARCHIVE), if $(FONT_TO_TRY) isn't found
FONT_TO_TRY = logod10.tfm
FONTARCHIVE = logofont.tar
### customizable variables:
# Where the TeX installation resides:
TEXMF = /opt/tex/texmf
SRCDIR = $(TEXMF)/source/latex/$(PACKAGE)
TEXDIR = $(TEXMF)/tex/latex/$(PACKAGE)
DOCDIR = $(TEXMF)/doc/latex/misc
FONTDIR = $(TEXMF)/fonts/source/public/$(PACKAGE)
TFMDIR = $(TEXMF)/fonts/tfm/public/$(PACKAGE)
# How to run LaTeX(2e):
LATEX = yes | latex
#LATEX = latex
# How to install the files:
INSTALL = cp -p
#INSTALL = install -c
# How to update the directory database:
TEXHASH = texhash
#TEXHASH = (cd $(TEXMF); ls -R $(TEXMF) > ls-R)
# How to check if the required fonts are installed:
#
KPSEWHICHCMD = kpsewhich tfm $(FONT_TO_TRY)
#KPSEWHICHCMD = kpsewhich $(FONT_TO_TRY)
#KPSEWHICHCMD = find $(TEXMF)/fonts -name "$(FONT_TO_TRY)" -print
### unpack targets:
default: all
all: check-fonts make-sty make-doc
make-sty: $(TEXFILES)
make-doc: $(DOCFILES)
.PHONY: make-sty make-doc
# Procude LaTeX macros:
$(TEXFILES): $(SRCFILES)
$(LATEX) $(PACKAGE).ins
# Produce documentation:
$(DOCFILES): $(SRCFILES) $(TEXFILES)
$(LATEX) $(PACKAGE).dtx
# Check if the required fonts are installed:
check-fonts:
$(KPSEWHICHCMD) > /dev/null || $(MAKE) install-fonts
.PHONY: check-fonts
### install targets:
install: install-sty install-doc # install-fonts
$(MAKE) post-install
.PHONY: install
# Install LaTeX macros:
install-sty: $(TEXFILES)
test -d $(TEXDIR) || mkdir $(TEXDIR)
(for f in $(TEXFILES); do $(INSTALL) $$f $(TEXDIR); done)
.PHONY: install-sty
# Install documentation:
install-doc: $(DOCFILES)
test -d $(DOCDIR) || mkdir $(DOCDIR)
(for f in $(DOCFILES); do $(INSTALL) $$f $(DOCDIR); done)
.PHONY: install-doc
# Install font sources and TFM files:
install-fonts: $(FONTARCHIVE)
(cd $(TEXMF); tar xvf $(SRCDIR)/$(FONTARCHIVE) )
$(MAKE) post-install
.PHONY: install-fonts
# Update the directory database:
post-install:
$(TEXHASH)
.PHONY: post-install
### clean targets:
clean:
rm -f *.log *.aux *.toc *.lof *.lot *.bbl *.blg
rm -f *.idx *.ind *.ilg *.glo *.gls
distclean: clean
rm -f $(TEXFILES) $(DOCFILES)
uninstall:
(for f in $(TEXFILES); do rm -f $(TEXDIR)/$$f; done)
(for f in $(DOCFILES); do rm -f $(DOCDIR)/$$f; done)
================================================================================
From owner-twg-tds@shsu.edu Mon, 26 Feb 1996 05:00:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 26 Feb 96 10:55:59 GMT
Message-ID: <9602261055.AA09905@r8h.cs.man.ac.uk>
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Some comments on CTAN:info/tdscd
Ulrik said, quoting Sebastian's file list I think
> here.doc
If that's my file, could you move it to /dev/null (and delete from
ctan as well:-)
and in a later message
> The remaining question is whether step 2. should be done using
> a ltxdoc.cfg file containg \OnlyDescription or whether you want
> full source documentation (including index and change history).
I would say to use \OnlyDescription if you are putting ready made dvi
files on the cd. Anyone who wants to look at source listings will
probably manage to latex the dtx files in the source tree...
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 26 Feb 1996 05:17:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 26 Feb 1996 12:16:31 +0100
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9602261116.AA03097@wega.informatik.uni-hannover.de>
To: TWG-TDS@SHSU.edu
Subject: Re: Some comments on CTAN:info/tdscd
> > /teTeX/doc/german/koma-script:
> > scr_new1.dvi
> [...]
> > scrguide.dvi
>
> Doesn't that belong into teTeX/texmf/doc/german ?
I dont see why the koma-script should be omitted.
> > /teTeX/texmf/bibtex/bib:
> > README
> > harvard
> >
> Where's mrabbrev.bib (from AMS-LaTeX)?
> Where's xampl.bib (from BibTeX)?
There are no .bib files in teTeX at all (there have been too many to
include all of them and I did not know which ones are the most important).
But, of course, for the CD there sould be as many as one can find.
> > /teTeX/texmf/doc/babel:
> Should be texmf/doc/generic/babel according to TDS.
Thanks, I will fix this for teTeX.
> > /teTeX/texmf/doc/dc:
>
> Should be texmf/doc/fonts/dc. In fact, that directory already exists,
> but the contents is slightly different. So what's messed up here?
> BTW, it would be nice to include a DVI file of dcdoc.tex as well.
dcdoc.dvi is part of teTeX (directory: texmf/doc/fonts/dc). texmf/doc/dc
does not exist in teTeX. Mayby, Sebastian added /teTeX/texmf/doc/dc??
> > /teTeX/texmf/doc/fontname:
> > ChangeLog
...
> Should be texmf/doc/fonts/fontname. I'm also doubtful whether
> ChangeLog will be of interest for anyone, if the full sources
> aren't kept here.
Thanks.
> > /teTeX/texmf/doc/help:
> Should have subdirectories help/ctan, help/faq, etc. according
> to TDS. At least, that's what the doc summary figure says.
Thanks.
> > /teTeX/texmf/doc/latex/base:
> > 00readme.txt
> > Makefile.unx
> > alltt.dtx
> > alltt.ins
> [...]
>
> What are all the .dtx and .ins files doing here? Doesn't the TDS
> say explicitly that thex belong into texmf/source/latex/base:
They have been added by Sebastian here. I think, he will fix this.
> IMHO, texmf/doc/latex/base should only include the following:
> - *.txt (perhaps not even all of them)
> - *.err
> - ltnews*.{tex,dvi}
> - *guide.{tex,dvi}
> - {small2e,sample2e}.tex (but also in tex/latex/base)
> - *.dvi (for any other formatted source documentation)
Yes. The "rest" like 00readme.txt, Changelog, ... should go to
texmf/sources.
> The same applies for texmf/doc/latex/{graphics,tools}, except
> that graphics should also include .ps files, not only .dvi.
As for some few .dvis files that should be available as .ps, too
(like the graphics docs), there is a Makefile in texmf/doc as part
of teTeX. Maybe, Sebastian did not yet notice it... :-)
> > /teTeX/texmf/doc/latex/styles:
> [...]
> > here.doc
> > index.doc
> > ulem.doc
>
> I believe these are old (pre-LaTeX2e) .doc (pre-.dtx) files
> that should be LaTeXable somehow to produce DVI documentation.
> They are not necessarily meant to be read in source form.
That was me. So, they should go into texmf/source/latex/misc, right?
>
> > /teTeX/texmf/doc/latex/umlaute:
> > anleitung.dvi
> > umlaute.dvi
>
> Might this is belong into texmf/doc/latex/german perhaps?
Why not texmf/doc/german/umlaute ?
> > /teTeX/texmf/doc/programs:
> > dvipsk.dvi
> > info-stnd.dvi
> > info.dvi
> > kpathsea.dvi
> > makeinfo.dvi
>
> Where's texinfo.dvi? I guess that would be more interesting
> than makeinfo, info and info-stnd.
That should be added.
> > /teTeX/texmf/fonts/tfm:
> [...]
> > bitstrea
> > bitstream
I used only the fontname-2.0 directory names for directories. Maybe,
Sebastian still uses different names somewhere.
> > dctt2074.tfm
> > dctt2488.tfm
> > jknappen
> > monotype
>
> Something must have been screwed up here!
Yes, has to be fixed...
> > /teTeX/texmf/fonts/tfm/public/mflogo:
> logobf10.tfm is missing!
I will add this one to teTeX, too.
> > /teTeX/texmf/tex/plain/misc:
> [...]
> > dcstdedt.tex
>
> I don't think dcstdedt.tex makes much sense here. It's just an utility
That was me. I will delete the file there for teTeX.
> > epsf.tex
>
> There's already an "epsf.tex" in tex/generic/dvips, so I don't think
texmf/tex/plain/misc/epsf.tex comes from teTeX. If
tex/generic/dvips/epsf.tex is the same, texmf/tex/plain/misc/epsf.tex
should be removed.
> Which languages for hypenation tables will be configured into the
> distributed latex.fmt file on the CD? Remember that this is something
> that users may well want to configure, so it would be a good idea to
> set up texmf.cnf, so that format files by default will also be searched
> in the corresponding directory on disk, no just on the CD.
That is already done.
So, that have been my comments to Ulrik's feedback from the teTeX
point-of-view. I think, this feedback was very helpful for both
the TeX CD and my teTeX distribution :-) So, many thanks!
Thomas
================================================================================
From owner-twg-tds@shsu.edu Mon, 26 Feb 1996 05:52:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 26 Feb 1996 12:52:48 +0100
Message-ID: <199602261152.MAA00401@lancelot.thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: Some comments on CTAN:info/tdscd
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
te writes:
>> > /teTeX/doc/german/koma-script:
>> > scr_new1.dvi
>> [...]
>> > scrguide.dvi
>>
>> Doesn't that belong into teTeX/texmf/doc/german ?
> I dont see why the koma-script should be omitted.
Yes, I meant teTeX/texmf/doc/german/koma-script. The imprtant point
is "texmf/doc" rather than just "doc".
>>
>> > /teTeX/texmf/doc/latex/umlaute:
>> > anleitung.dvi
>> > umlaute.dvi
>>
>> Might this is belong into texmf/doc/latex/german perhaps?
> Why not texmf/doc/german/umlaute ?
Right. That's probably what I meant.
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Mon, 26 Feb 1996 07:01:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 26 Feb 1996 12:58:34 GMT
Message-ID: <199602261258.MAA18844@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: Some comments on CTAN:info/tdscd
References: <199602261007.LAA00247@lancelot.thphy.uni-duesseldorf.de>
> the texi2html documentation to ensure that filenames remain uniqiue
> when truncated to 8+3. While I was at it I also regenerated all the
> Info files for the same reason. Expect my uploads at ftp.tex.ac.uk.
you are a hero.
> 2. I had a look at the files you placed on CTAN:info/tdscd and noted
> the following problems (some of this may be TDS releveant but most
i wont comment on all, but thank you very much for looking at this,
its really very helpful.
> > /teTeX/texmf/bibtex/bib:
> > README
> > harvard
> >
> Where's mrabbrev.bib (from AMS-LaTeX)?
> Where's xampl.bib (from BibTeX)?
good point. i had forgotten both
> Should be texmf/doc/generic/babel according to TDS.
>
> > /teTeX/texmf/doc/dc:
>
> Should be texmf/doc/fonts/dc. In fact, that directory already exists,
> but the contents is slightly different. So what's messed up here?
me and Thomas at different times
> > /teTeX/texmf/doc/latex/base:
> > 00readme.txt
> > Makefile.unx
> > alltt.dtx
> > alltt.ins
> [...]
>
> What are all the .dtx and .ins files doing here? Doesn't the TDS
> say explicitly that thex belong into texmf/source/latex/base:
yes, my mistake. many of the same kind to undo
> > /teTeX/texmf/doc/latex/revtex:
>
> This looks incomplete. There should be DVI files for all
> man*.tex files, but there's probably no need for PS files.
yes, that was half-finished.
> > /teTeX/texmf/fonts/tfm:
> [...]
> > bitstrea
> > bitstream
an interesting question....
> > dctt2074.tfm
> > dctt2488.tfm
> > jknappen
> > monotype
>
> Something must have been screwed up here!
indeed...
> TDS says "texmf/source" (without trailing `s')! Here's where I would
> expect to see a lot of stuff in texmf/source/{generic,latex}/<package>/...
> In fact, you might put all the teTeX/extra-distrib stuff from CTAN here.
Thomas and I talked about whether to include .tar.gz packages of what
we build the TDS tree from, but it would cut down on the CD
space. that extra-distrib is my working area
> What's this doing here? "texmf/tex/initex" has been gone long since.
> This stuff obviously belongs into texmf/tex/latex209/base/...
yup, all a mess, to reo
> set up texmf.cnf, so that format files by default will also be searched
> in the corresponding directory on disk, no just on the CD.
thats true; it isnt set up in texmf.cnf as its stands; will add
> 1. I would find the output of "find /teTeX -print | sort" easier
> to check than the output of "ls -R /teTeX".
ok
> 2. If time permits in the production cycle, it might be a good idea
> to have someone (us?) check the contents of a preliminary CD
> for problems, mismatches, mix-ups, etc. as mentioned above before
> releasing it to the general public.
oh yes, definitely! i have sent a preliminary CD to Thomas already (he
has done revised Make* scripts etc), and i propose in (say) a month to
make 3 or 4 and send out real CDs to people with some time and energy
to look at for a few weeks, as well as posting the list to CTAN. i
have got a supplier yet, but i would guess i'll need to get the final
product to them by the first week of May to be on the safe side.
> What about including other related software such as Acrobat readers
i am planning to check Acrobat with Adobe.
> or WWW brosers for those Unix platforms where they are available?
since we do not include GhostScript, isnt this a bit over the top?
but the short answer is that if someone puts together a tar.gz file,
claims responsibility for it, tests it, and it doesnt break anything
else, why not? but i'd be very reluctant to have only partial bin/
support - it would be sad to say "this CD is fully populated only for
linux and solaris". also, its a slippery slope. why not add gzip,
unzip, netpbm, perl....
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 26 Feb 1996 07:02:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 26 Feb 1996 13:00:13 GMT
Message-ID: <199602261300.NAA18872@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: TUG Unix CD: HTML documentation
References: <199602261044.LAA00290@lancelot.thphy.uni-duesseldorf.de>
ha, nice one, Ulrik (the Makefile). i shall start playing with that
with great pleasure
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 26 Feb 1996 07:56:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 26 Feb 1996 14:53:42 +0100
Message-ID: <199602261353.OAA17047@spock.iti.informatik.th-darmstadt.de>
From: Joachim Schrod <jschrod@acm.org>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TUG Unix CD: HTML documentation
References: <199602261027.LAA00259@lancelot.thphy.uni-duesseldorf.de>
>>>>> "UV" == Ulrik Vieth <vieth@thphy.uni-duesseldorf.de> writes:
UV> Sebastian wrote:
>> QUESTION
>> i am getting very confused over texmf/source and texmf/doc for .dtx
>> files. if you take a package with his
>> x.ins
>> x.dtx
>> sample.tex
>> readme
>> what files do you put in which directory in a really nice working TDS?
UV> I usually start by putting all these files as they come from CTAN
UV> into texmf/source/latex/<package>. Then I procede as follows:
I do almost the same, but would like to add my changes, FYI,
UV> 2. Run latex x.dtx to produce the documentation (it usually takes
UV> several latex runs) and move/copy the resulting *.{dvi,ps} files
UV> to ../../../doc/latex/<package>
Use tex-it for getting fully TeXed documents, a script posted
infrequently by me. I append it below.
UV> The remaining question is whether step 2. should be done using
UV> a ltxdoc.cfg file containg \OnlyDescription or whether you want
UV> full source documentation (including index and change history).
Yes. For my convenience, I have globally installed the following
ltxdoc.cfg:
================ snip snap ========================================
% ltxdoc.cfg 11 Jan 95
%------------------------------------------------------------
%
% Configuration for LaTeX standard class `ltxdoc'
% (Program documentation for LaTeX)
%
% A4 paper is used almost everywhere, except in the US; make that the
% default.
\PassOptionsToClass{a4paper}{article}
% If a file `OnlyDesc' exists in the input path, we just typeset the
% description (i.e., everything until \StopEventually). That's a
% convenient way to get only the user documentation from style files
% that use the ltxdoc class for documentation.
\InputIfFileExists{OnlyDesc}{%
\AtBeginDocument{\OnlyDescription}%
}{}
\endinput
================ snip snap ========================================
i.e., if a file `OnlyDesc' exists in the current directory, only the
description of a .dtx files is typeset. That allows me to `touch
OnlyDesc' instead of creating a package specific ltxdoc.cfg that would
override my global one.
And here is tex-it:
================ snip snap ========================================
#!/bin/sh
# $ITI: tex-it,v 1.3 1995/06/14 10:49:12 schrod Exp $
#----------------------------------------------------------------------
#
# tex-it --- transform a TeX document to a final DVI file
#
# (history at end)
# SYNOPSIS
#
# tex-it [-bi] tex-cmd file
#
# tex-it runs 'tex-cmd' on 'file' as often as necessary to produce a
# DVI file where all cross references are resolved. That convergence
# is reached by analyzing auxilliary files:
# -- If file.toc has changed, the table of contents is not up to date.
# -- If file.idx has changed, the index is not up to date.
# MakeIndex is assumed to be used for creating the index.
# -- If file.aux has changed, cross references are not up to date.
# -- If file.aux contains a "\bibdata" tag and if the set of
# "\citation" tags have changed, then BibTeX is run.
#
# No other auxilliary files are handled. No subdocuments (via
# "\include") are supported.
#
# 'tex-cmd' may be more than one word.
#
#
# OPTIONS
# `-b' skip test for BibTeX
# `-i' skip test for MakeIndex
# NOTE: On HP-UX this script is not functional, you have to substitute
# /bin/sh by /bin/ksh in the first line. (/bin/sh doesn't have the
# getopts builtin.)
cmd=`basename $0`
usage()
{
echo "usage: $cmd [-bi] tex-cmd file" >&2
exit 1
}
# Normalize and check arguments.
do_bibtex=true
do_makeindex=true
while getopts 'bi' option
do case "$option" in
b) do_bibtex=''
;;
i) do_makeindex=''
;;
*) usage
;;
esac
done
shift `expr $OPTIND - 1`
test $# -gt 0 || usage
# Get file name (last argument), discard extension if necessary.
file=`eval "echo \\$$#"`
file=`echo $file | sed 's/\.[^.]*//'`
# Create temporary directory for auxilliary files to compare. Discard
# that directory if the script is terminated. Note that trap handler
# for 0 is executed at the end of the trap handler for the other
# signals.
tmp=/tmp/tex$$
trap "/bin/rm -rf $tmp" 0
trap "exit 4" 1 2 3 15
mkdir $tmp
# ------------------------------------------------------------
#
# Set up functions that save auxilliary information and check if they
# have changed. Save functions are called `save_<type>', check
# functions are called `check_<type>'. Check functions set $run_tex to
# "true" if TeX must be run anew. Check functions may run programs to
# create other auxilliary files.
# aux: table of contents & cross references
#
# We don't check for *.toc files. LaTeX stores the information in the
# AUX file anyhow, and plain-based macros typically produce the table
# of contents at the end of the document, when it's guaranteed to be
# OK.
save_aux()
{
if [ -f "$file.aux" ]
then cp "$file.aux" $tmp
else touch "$tmp/$file.aux"
fi
}
check_aux()
{
test -f "$file.aux" || return 0
cmp -s "$file.aux" "$tmp/$file.aux" || run_tex=true
}
# bibtex: Citations
save_bibtex()
{
if [ -f "$file.aux" ]
then egrep '^\\(citation|bibdata)' "$file.aux" |
sort >"$tmp/$file.bib"
else touch "$tmp/$file.bib"
fi
}
check_bibtex()
{
test "$do_bibtex" -a -f "$file.aux" || return 0
egrep '^\\(citation|bibdata)' "$file.aux" | sort >$tmp/bib.new
if grep '^\\bibdata' $tmp/bib.new >/dev/null
then if cmp -s "$tmp/$file.bib" $tmp/bib.new
then : do nothing
else bibtex "$file"
run_tex=true
fi
fi
}
# idx: raw index data
save_idx()
{
if [ -f "$file.idx" ]
then cp "$file.idx" $tmp
else touch "$tmp/$file.idx"
fi
}
check_idx()
{
test "$do_makeindex" -a -f "$file.idx" || return 0
if cmp -s "$file.idx" "$tmp/$file.idx"
then : do nothing
else makeindex "$file"
run_tex=true
fi
}
# Two functions that collect the functions above.
save_aux_info()
{
save_aux
save_bibtex
save_idx
}
check_aux_info()
{
check_aux
check_bibtex
check_idx
}
# Process the document by TeX. Determine if TeX must be run anew by
# the functions realized above.
run_tex=true
while [ "$run_tex" ]
do save_aux_info
"$@"
run_tex=''
check_aux_info
done
#======================================================================
#
# $ITIlog: tex-it,v $
# Revision 1.3 1995/06/14 10:49:12 schrod
# HP-UX /bin/sh doesn't grok getopts, use ksh instead.
#
# Revision 1.2 1995/04/19 14:31:06 schrod
# Support MakeIndex call, too.
#
# Revision 1.1 1995/03/14 17:07:26 schrod
# Added script to process a TeX document.
#
================ snip snap ========================================
Shall I make a package out of this script? (I'll leave for a
conference RSN, where I will be the rest of the week, don't expect
stuff from me before the next weekend.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: jschrod@acm.org
Roedermark, Germany
Net & publication consultant
================================================================================
From owner-twg-tds@shsu.edu Mon, 26 Feb 1996 20:31:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 27 Feb 1996 03:29:22 +0100
Message-ID: <199602270229.DAA16838@spock.iti.informatik.th-darmstadt.de>
From: Joachim Schrod <jschrod@acm.org>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Some comments on CTAN:info/tdscd
References: <199602261007.LAA00247@lancelot.thphy.uni-duesseldorf.de>
>>>>> "UV" == Ulrik Vieth <vieth@thphy.uni-duesseldorf.de> writes:
>> /teTeX/texmf/tex/plain/base:
UV> Should add at least logmac.tex (neeeded to TeX Knuth's errorlog.tex).
UV> There are also some more variations of (l)list.tex in last year's
UV> distribution of systems/knuth/local/lib. However, I'm unconvinced
UV> that they should all go in the plain/base.
Exactly, that's not the wrong place for them. In my installation, I
have added a package `stanford' with Knuth's macros that are not real
basic plain stuff. Files like fontchart.tex, gkpmac.tex, letter.tex,
etc., are placed there as well. One might use a package name `knuth'
instead, I don't mind -- but please don't put them in base/.
UV> What about including other related software such as Acrobat readers
UV> or WWW brosers for those Unix platforms where they are available?
If there is additional software to be added, I would recommend Perl
and a modern Borne shell (e.g., bash). That enables us to write
portable scripts. E.g., my tex-it script from this morning uses shell
functions that are not available in very old Borne shells like the one
distributed with Ultrix.
Cheers,
Joachim
PS: Still discussing theoretically. I have the current teTeX now, 4 GB
free disk space at home, a new CD ROM -- just in case sebastian sends
me one -- and will start to package stuff at the next weekend.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: jschrod@acm.org
Roedermark, Germany
Net & publication consultant
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Feb 1996 02:18:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 27 Feb 1996 09:18:29 +0100
From: Michel LAVAUD <lavaud@centre.univ-orleans.fr>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199602270818.JAA16921@centre.univ-orleans.fr>
To: twg-tds@shsu.edu
Subject: Which place for docs in French, German, etc?
To:twg-tds@shsu.edu
Subject: Which place for docs in French, German, etc?
I have not seen any place for documentation in French (or German,
Italian etc.). Did I miss it? If there is no place for it, I
would propose to add a level of directories in /doc main
subdirectory:
./doc/english
./doc/french
./doc/german
etc. This would give e.g. /doc/french/latex/(package). The other
possibility, would be /doc/latex/(package)/french. But I think it
would be impractical, as it would be necessary to jump several
levels up and then several levels down to go from one doc to the
other, and difficult to see what docs are available in French.
Michel Lavaud (lavaud@univ-orleans.fr)
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Feb 1996 03:57:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 27 Feb 1996 09:53:10 GMT
Message-ID: <199602270953.JAA25024@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: Which place for docs in French, German, etc?
References: <199602270818.JAA16921@centre.univ-orleans.fr>
i don't quite see the problem:
- the French translation of X goes into
doc/<package>/french
(just as the english does in
doc/<package>/english
- the entire new package with a French manual is
doc/<package>
- the revised-for-french (ie FAQ) takes a new name
doc/frfaq
the idea of a complete tree
doc/french
makes me nervous; at the least we'd have to move everything now there
to
doc/english
but when a manual only exists in one language, how is a user expected
to realize its in French, German, Russian?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Feb 1996 07:15:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 27 Feb 1996 13:08:50 +0100
From: Michel LAVAUD <lavaud@centre.univ-orleans.fr>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199602271208.NAA12112@centre.univ-orleans.fr>
To: twg-tds@shsu.edu
Subject: Re: Which place for docs in French, German, etc?
To:twg-tds@shsu.edu
Subject: Which place for docs in French, German, etc?
> doc/french
> makes me nervous; at the least we'd have to move everything now there
> to
> doc/english
>
> but when a manual only exists in one language, how is a user expected
> to realize its in French, German, Russian?
Well, he would look in directory doc/french, or doc/german, or
doc/russian. It's a question of collecting together matter of the
same kind. Docs in French are of the same kind. When you get
documentation (say for a TV set) in several languages, say Dutch,
English, French, German, Japanese etc., you have usually the
complete doc in Dutch collected together, then the English doc,
then the French doc, etc:
1 Dutch
Chapter one
Chapter two
...
2 English
Chapter one
Chapter two
...
Of course, one could also have a different type of organization:
1 - Chapter one
Dutch
English
French
German
...
2 - Chapter two
Dutch
English
French
German
...
but I never saw that. As for commercial software, doc is also
organized in the first way, when it is provided in several
languages. I find this is more user-friendly.
Having to look through many directories to find doc in French
would make me uncomfortable (although not nervous). I think that
most French users would appreciate that doc in French would be
gathered together in one main subdirectory /french, rather than
disseminated in the whole doc tree. It would be interesting to
have the opinion of other non-English speaking people ?
Michel Lavaud (lavaud@univ-orleans.fr)
================================================================================
From owner-twg-tds@shsu.edu Tue, 27 Feb 1996 13:06:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 27 Feb 1996 14:04:20 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199602271904.AA03602@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
disseminated in the whole doc tree. It would be interesting to
have the opinion of other non-English speaking people ?
I hope English speakers are also allowed to reply :-).
This discussion of collecting the doc in certain languages vs. keeping
all doc with the package seems very reminiscient to me of the typeface
debate (etc.). We decided there to collect things by type (i.e., language).
I can't say I'm excited about another directory level under doc/, but
maybe it makes sense.
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 01:46:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 28 Feb 1996 07:41:54 GMT
Message-ID: <199602280741.HAA02975@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: Which place for docs in French, German, etc?
References: <199602271208.NAA12112@centre.univ-orleans.fr>
Michel LAVAUD writes:
> documentation (say for a TV set) in several languages, say Dutch,
> English, French, German, Japanese etc., you have usually the
,,,,
> Of course, one could also have a different type of organization:
>
> 1 - Chapter one
> Dutch
> English
> French
> German
excuse me, but i do see that arrangment on my microwave instructions :-}
but i dont have any very strong feelings on this. i just stipulate
that the number of directory levels remain constant, so that
lots of things move down one to doc/english
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 05:06:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 28 Feb 1996 12:05:44 +0100
From: Michel LAVAUD <lavaud@centre.univ-orleans.fr>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199602281105.MAA17315@centre.univ-orleans.fr>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
Karl BERRY wrote:
> > Of course, one could also have a different type of organization:
> > disseminated in the whole doc tree. It would be interesting to
> > have the opinion of other non-English speaking people ?
>
> I hope English speakers are also allowed to reply :-).
Ah yes, sorry for my bad English, I meant "have also the opinion of
non-English speaking people" (and sorry if this is still bad English :-))
> documentation (say for a TV set) in several languages, say Dutch,
> English, French, German, Japanese etc., you have usually the
>
> 1 - Chapter one
> Dutch
> English
> French
> German
> excuse me, but i do see that arrangment on my microwave instructions :-}
Sorry, Sebastian, I apologize: my statement was to bald indeed.
(BTW, I heard that a woman put her dog into a microwave oven to
have it dried; maybe she had this model and she couldn't find the
page where this practice is discouraged ? :-})
> I can't say I'm excited about another directory level under doc/, but
> maybe it makes sense.
A few advantages I see, if all doc for a given language is in its
own subdirectory :
- when making installation on hard disk, user can delete docs in
languages he don't know, by performing "rm -r" or "delete" in the
corresponding directories. For example, if an English user don't
read/need French doc, he can delete it with rm -r doc/french/*.
But If doc in all languages sit in on subdir, it is not trivial
(with usual OS commands) to get rid of French doc, especially if
directory names are not homogeneous, sometimes frFAQ, sometimes
package/french.
- when using doc from a CD-ROM or from a network disk, a French
user can access all French doc by assigning a disk with name L:
to directory doc/french (with subst L: doc/french on PC, or mount
doc/french for network disk, etc.), and he will see only doc in
French on this disk. With the same CD-ROM, a German user could
assign this disk L: to German directory and he will see only
German doc (For docs not available in German or French, assign
disk M: to English doc).
If doc is organized the other way, everybody will see docs in all
languages mixed together. As long as there is almost no doc
available in other languages than English, no problem. But if
many docs will become available in other languages, users could
find it tedious to find what they need.
> but i dont have any very strong feelings on this. i just stipulate
> that the number of directory levels remain constant, so that
> lots of things move down one to doc/english
To keep directory names shorter for TDS, maybe it would be better
to use the two letters "fr" for French subdir, "de" for German,
"es" for Spanish etc. as used in Internet addresses, instead of
"german" or "deutsch", or "french" or "francais", and add a file
languages.txt that contains the list
de deutsch german
fr francais french
es espanol spanish
etc? In this case: for english, I don't know what could be used,
en? uk? us?
Michel Lavaud (lavaud@univ-orleans.fr)
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 05:52:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 28 Feb 1996 11:48:11 GMT
Message-ID: <199602281148.LAA07517@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: Which place for docs in French, German, etc?
References: <199602281105.MAA17315@centre.univ-orleans.fr>
michel is getting quite convincing! i dont have a dog so havent tried
the microwave trick yet, is it fun? would a baby do?
but in this case we must change
the TDS to specify texmf/doc/<language> as mandatory.
using the 2 letter codes is also a good idea to prevent upset and
confusion. i am afraid we would have to have "us" for english, sigh.
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 05:57:21 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0trkKG-0001ilC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 28 Feb 96 11:45 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
The documentation directory structure should be based around making
it easy for A. N. Punter to find the documentation they're after. If
we go for:
$texmf/doc/<language>/<package>
then this makes it easy to find (e.g.) all French documentation, but
difficult to find (e.g.) all documentation on AMS-LaTeX. If we go
for:
$texmf/doc/<package>/<language>
then the situation is reversed. I find it unlikely that A. N. Punter
is going to be searching for AMS-LaTeX documentation in French and
would rather find French Babel documentation than English AMS-LaTeX
documentation.
In addition, so few packages have multi-lingual documentation that I
think it's pointless adding an extra directory level for the few that
do.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 06:33:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 28 Feb 1996 12:29:40 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <960228122940.21e4eeb0@vms.rhbnc.ac.uk>
Subject: Re: Which place for docs in French, German, etc?
>> using the 2 letter codes is also a good idea to prevent upset and
>> confusion. i am afraid we would have to have "us" for english, sigh.
^^
W H Y ? ? ! ! ! for *%$#@!'s sake?
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 06:51:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 28 Feb 1996 12:47:55 GMT
Message-ID: <199602281247.MAA09358@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
CC: CHAA006@alpha1.rhbnc.ac.uk
Subject: Re: Which place for docs in French, German, etc?
References: <960228122940.21e4eeb0@vms.rhbnc.ac.uk>
Philip Taylor writes:
> >> using the 2 letter codes is also a good idea to prevent upset and
> >> confusion. i am afraid we would have to have "us" for english, sigh.
> ^^
>
> W H Y ? ? ! ! ! for *%$#@!'s sake?
>
cos more documentation is written by US than UK, and most non-english
speakers conform to US style, and do you want to distinguish between
us and uk?
making doc/english a special case is a bit arrogant :-}
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 06:55:34 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <9602281249.AA26155@uu3.psi.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
Date: Wed, 28 Feb 96 07:48:23 -0500
From: bob@microprograms.com
Reply-To: TWG-TDS@SHSU.edu
sebastian laments:
> i am afraid we would have to have "us" for english, sigh.
no, no. no! us for american, uk for english. the queen's english has
not been heard or seen in the us for decades (centuries?).
i am constantly amused each march at the number of yankees on our tour
to crufts dog show who cannot understand the british. i spend a
significant number of hours as an interpreter.
bob
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 07:26:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 28 Feb 1996 13:21:30 GMT
Message-ID: <199602281321.NAA12599@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: Which place for docs in French, German, etc?
References: <9602281249.AA26155@uu3.psi.com>
what is the ISO code for whatever dogs speak? do american dogs have
their own dialect? how many canine TeX users do we know? Phil, any
word from the equine side?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 08:12:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 28 Feb 1996 14:09:19 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: <960228140919.21e4eeb0@vms.rhbnc.ac.uk>
Subject: Re: Which place for docs in French, German, etc?
>> what is the ISO code for whatever dogs speak? do american dogs have
>> their own dialect? how many canine TeX users do we know? Phil, any
>> word from the equine side?
I have it on good authority that dogs speak some form of double-English,
although whether <Am.E> or <Br.E> remains moot: the following is
a transcription of a conversation between an experimental canine
linguist and his subject --
L: Describe the surface of a sheet of sandpaper.
S: Rough, rough.
L: What is the upper surface of a building called?
S: Roof, roof.
L: Who was the finest baseball pitcher this century?
S: Ruth, ruth.
L: From which species are you most recently descended?
S: Wolf, wolf.
As to equines, mine appears able to disobey commands no matter
in which language they are expressed.
** P.
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 10:14:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 28 Feb 1996 17:06:20 +0100
From: Michel LAVAUD <lavaud@centre.univ-orleans.fr>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199602281606.RAA22705@centre.univ-orleans.fr>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
Alan JEFFREY wrote:
> The documentation directory structure should be based around making
> it easy for A. N. Punter to find the documentation they're after.
I do agree with that...
> If we go for:
>
> $texmf/doc/<language>/<package>
>
> > then this makes it easy to find (e.g.) all French documentation, but
> difficult to find (e.g.) all documentation on AMS-LaTeX. If we go
> for:
>
> $texmf/doc/<package>/<language>
>
> then the situation is reversed. I find it unlikely that A. N. Punter
> is going to be searching for AMS-LaTeX documentation in French and
> would rather find French Babel documentation than English AMS-LaTeX
> documentation.
...but I do not undertand that point? If AMSLaTeX doc was in
$texmf/doc, then it would be in $texmf/us/doc. Why A. N. Punter
could not find it?
Michel Lavaud (lavaud@univ-orleans.fr)
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 10:40:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 28 Feb 1996 17:30:45 +0100
Message-ID: <199602281630.RAA00760@lancelot.thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Phil wrote:
> I have it on good authority that dogs speak some form of double-English,
> although whether <Am.E> or <Br.E> remains moot: the following is
> a transcription of a conversation between an experimental canine
> linguist and his subject --
[...]
> As to equines, mine appears able to disobey commands no matter
> in which language they are expressed.
ROTFL (for those who speak hackish ;-), but seriously I guess it
should be obvious that it would cause more inconveniences than anything
else if we tried to sort documentation by country-code, going so far
as to separete "us" and "uk" (or actually "gb") depending on who wrote
the manual and what dialect the author used. This would especially
cause problems for non-English speakers writing documentation for
their packages in English. Who is going to enlighten me whether my
English is more British or more American or some artificial mixture?
If you really have a look at the list of ISO country codes, e.g. at
http://www.nw.com/zone/iso-country-codes, you'll find that there are
currently some 253 territories, including e.g. 5 different codes for
France and various overseas French territories, 2 different codes for
the U.S. and U.S minor outlying islands, 2 different codes for the
Virgin Islands (British and U.S.), etc.
I think it should be pretty obvious that this is not an ideal system
for classifying documentation by language. Clearly labeling the
directories as "english", "german", "french", etc. would seem more
natural to me, especially if they coincide with the names already
used in various language-aware packages such as babel, varioref, etc.
Whether or not it is really such a good idea to introduce language
subdirectories below texmf/doc is another question I'm not fully
convinced of, since most documentation will usually be available
only in one language. Under these circumstances, I think it would
more important to make it easy to find whatever documentation is
available for some package rather than making it easy to find
all the documentation for one language and not finding the other
documentation at all in that language-specific subtree.
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 12:18:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 28 Feb 96 18:16:09 GMT
Message-ID: <9602281816.AA17755@r8h.cs.man.ac.uk>
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
> using the 2 letter codes is also a good idea to prevent upset and
> confusion. i am afraid we would have to have "us" for english, sigh.
Like Alan I'm not really convinced that doc/<language> is really an
improvement, but I could live with it.
However
doc/us
is fairly horrible (especially as I've gone to so much trouble to
spell colour correctly in the documentation, if not the in the command
names in the code sections:-)
Someone, somewhere, once posted a list of ISO language (as opposed to
country) codes, I have a feeling it was Joachim, to this list, but I
could be wrong.
I would have thought though it would be clearer all round if
understandable names for the directories were used, rather than codes,
after all the doc area is for humans. I suppose the codes are to avoid
deciding on whether to use the English name for the language, or the
native spelling. I would have though either (even inconsistly) would
be better than codes. One could take babel option names as a first
choice (which doesn't help in French as babel accepts both french and
francais...)
David
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 12:39:16 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0trqfb-0001iQC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 28 Feb 96 18:32 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
>...but I do not undertand that point? If AMSLaTeX doc was in
>$texmf/doc, then it would be in $texmf/us/doc. Why A. N. Punter
>could not find it?
If I'm looking for foobar documentation on my Mac then at the
moment I open the folder:
texmf:doc:latex
and look for something appropriate. Under your scheme I have to first
open the folder:
texmf:doc:latex:fr
then:
texmf:doc:latex:de
then:
texmf:doc:latex:us
then ...
On Unix you can use * patterns to get round this, but not under MacOs
(and possibly not PatioDoors95).
Alan.
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 14:16:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 28 Feb 1996 21:14:04 +0100 (MET)
From: Michel Goossens <Michel.Goossens@cern.ch>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
Message-ID: <Pine.A32.3.91b.960228210957.94409F-100000@sp053.cern.ch>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> If you really have a look at the list of ISO country codes, e.g. at
> http://www.nw.com/zone/iso-country-codes, you'll find that there are
> currently some 253 territories, including e.g. 5 different codes for
> France and various overseas French territories, 2 different codes for
> the U.S. and U.S minor outlying islands, 2 different codes for the
> Virgin Islands (British and U.S.), etc.
As with HTML, you probably need language (instead of country) groups,
see http://www.sil.org/sgml/iso639a.html, which can, if _really_ needed,
be turned into country-specific variants, eg,
EN-GB, EN-US or FR-CA, FR-FR, FR-BE, FR-CH, or DE-DE, DE-AT, DE-CH...
Michel
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 16:35:51 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 28 Feb 1996 14:34:33 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199602282234.OAA27081@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
Why us? Why not uk? On some of the multilingual packages
I have seen from Sun, the suffix is actually eng, which is
grossly misleading---I thought it meant engineering.
In the LOCALE directories, the suffix is en.
At least it is for cases of mutually unintelligible
dialects as: en_AU en_CA en_IE en_NZ. US English
is actually en_US, if anyone cares to use it instead of
C
UK English is en_UK
%=======================================================================%
| 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, 28 Feb 1996 16:38:28 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 28 Feb 1996 14:36:32 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199602282236.OAA27299@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
No problem with eq for horses, but ca for dogs might
cause problems
================================================================================
From owner-twg-tds@shsu.edu Wed, 28 Feb 1996 16:44:36 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 28 Feb 1996 14:43:46 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199602282243.OAA28360@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
The LOCALE designations I mentioned earlier use en_UK for
UK English. Homeland FR and DE have no extension, but I
see no problem with FR_FR ES_ES and DE_DE. Interesting,
and perhaps the price of taking on the responsibilities
of a lingua franca that there is no EN_EN.
================================================================================
From owner-twg-tds@shsu.edu Thu, 29 Feb 1996 03:50:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Feb 1996 10:28:04 +0100
From: Michel LAVAUD <lavaud@centre.univ-orleans.fr>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199602290928.KAA10337@centre.univ-orleans.fr>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
Alan JEFFREY wrote:
> If I'm looking for foobar documentation on my Mac then at the
> moment I open the folder:
>
> texmf:doc:latex
>
> and look for something appropriate. Under your scheme I have to first
> open the folder:
>
> texmf:doc:latex:fr
>
> then:
>
> texmf:doc:latex:de
>
> then:
>
> texmf:doc:latex:us
>
> then ...
>
> On Unix you can use * patterns to get round this, but not under MacOs
> (and possibly not PatioDoors95).
Ah, thanks; I see your point now. I think you misunderstood me.
Consider the practical case of an English-speaking user who knows
only English and French, but who does not know German, Dutch,
Chinese, Japanese etc. Under my scheme, he will have only two
folders, one pointing to doc/us (or doc/en) and another pointing
to doc/fr.
Now, he might name the icon/object/hieroglyph associated to this
folder "English doc" (or "English documentation for TeX-related
programs") and the other icon pointing to doc/fr "French doc".
To get doc, he will open first folder "English doc" and, if he
finds nothing ther, he will open "French doc".
Now consider a French-speaking user who speaks only French and
English. He will create exactly the same folders, the only
difference: he will name the icons "Doc en anglais" and "Doc en
francais". And he will open first the folder "Doc en francais",
then "Doc en anglais".
This scheme is completely insensitive to the increase of
informations irrelevant for a given user: only pertinent
information will be displayed, non-pertinent info is
automatically filtered out. If files in French of English have
been added on next revision of CD-ROM, the user will see it
automatically. But if German docs have been added, or other
information irrelevant for him, these will be filtered out. On
the contrary, a German-speaking user will see new doc files in
German, while new doc files in French will be filtered out if he
does not understand French.
With the scheme doc/package/language, all users see a hierarchy
with /package/english/file, package/french/file
package/german/file etc. If any doc in any language is added, any
user will see all new files, even those that are completely
irrelevant for him, and display will become more and more
clobbered with information useless for him.
Michel Lavaud (lavaud@univ-orleans.fr)
================================================================================
From owner-twg-tds@shsu.edu Thu, 29 Feb 1996 04:07:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Feb 1996 10:58:52 +0100
From: Michel LAVAUD <lavaud@centre.univ-orleans.fr>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199602290958.KAA10624@centre.univ-orleans.fr>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
David CARLISLE wrote:
> I would have thought though it would be clearer all round if
> understandable names for the directories were used, rather than codes,
> after all the doc area is for humans. I suppose the codes are to avoid
> deciding on whether to use the English name for the language, or the
> native spelling. I would have though either (even inconsistly) would
> be better than codes. One could take babel option names as a first
> choice (which doesn't help in French as babel accepts both french and
> francais...)
Well, I agree completely that doc area is for humans, and that
"french" or "francais" are clearer than "fr". But choosing "fr"
or "french" or "francais" is a problem only with the scheme
doc/package/language, not for the scheme I propose.
With the doc/package/language scheme, it is a problem because,
each time the user goes into the doc folder, he will see
explicitly the name "fr" or "french" or "francais", for each doc
file.
With the doc/language/package scheme, the user has to know what
means "fr" or "french" or "francais" only once, at installation
time. After that, he has not to bother any more with it, he uses
the name he has coined himself for the doc folder. So, it would
be even completely innocuous to assign names "l1" to English,
"l2" to German, "l3" to French, etc. ISO codes of languages seem
the best choice for me (especially because my installation
scripts use "en" for English, "fr" for French and "de" for
German, which appear to be ISO codes, according to M. Goossens
and Pierre MacKay ?).
Just for the sake of comparison, the CD-ROM "Bonus pak" for OS/2
has the following directories, under the root of the CD:
br Bresil
cf Canada francophone
dk Denmark
fr France
gr Germany
it Italy
la Latin America
nl Nederland
no Norway
po Portugal
sp Spain
su Finland
sv Sweden
uk United Kingdom
us USA
"uk" and "us" reflects here, I suppose, the fact that this CD-ROM
is related both to language and country, as it deals also with
hardware (fax and connection to Internet) which have probably
different specifications for different countries (?).
Michel Lavaud (lavaud@univ-orleans.fr)
================================================================================
From owner-twg-tds@shsu.edu Thu, 29 Feb 1996 04:22:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Feb 96 10:11:56 GMT
Message-ID: <9602291011.AA18656@r8h.cs.man.ac.uk>
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: Michel LAVAUD <lavaud@centre.univ-orleans.fr>
Subject: Re: Which place for docs in French, German, etc?
> only pertinent
> information will be displayed, non-pertinent info is
> automatically filtered out.
I think this is where I (and presumably Alan and Ulrick) disagree.
Currently almost all the primary documentation is in English, so the
differences between the suggested layouts are currently small, but it
may be that more packages become documented in other languages.
However I can take one current example.
The primary documentation for picins happens to be in german. If I
were looking for the documentation for the package under the
doc/<package> scheme then I find the documentation, and well I can't
read German, but that is my fault, and I could probably get enough out
of the examples to get by. However under the doc/<language> system
that you suggest, then either I have to search all the directories (as
I may not know which language the documentation is written in) or if I
use your `filtering' example, then I dont see the documentation at
all.
[Actually picins now has a small summary documention in English, but
that is beside the point, one could imagine some package with
documentation in some language...]
As Alan pointed out the doc/<language> system is better for if someone
wants to `browse' the general documentation, (or for cases like your
microwave example, where *all* the documentation is available in *all*
the languages) but in this case it is technical documentation of
specific packages, which may appear in one or more, but almost never
all, of the languages. Therefore it seems better to have a `package
first' organisation, as it is better to find some documentation in a
language you don't understand, than to find no information at all.
David
PS
I have no pets, children or microwaves, so I can not contribute to
the sub-plot of this thread.
================================================================================
From owner-twg-tds@shsu.edu Thu, 29 Feb 1996 04:22:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Feb 96 10:11:03 GMT
Message-ID: <9602291011.AA18648@r8h.cs.man.ac.uk>
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: Michel LAVAUD <lavaud@centre.univ-orleans.fr>
Subject: Re: Which place for docs in French, German, etc?
> only pertinent
> information will be displayed, non-pertinent info is
> automatically filtered out.
I think this is where I (and presumably Alan and Ulrick) disagree.
Currently almost all the primary documentation is in English, so the
differences between the suggested layouts are currently small, but it
may be that more packages become documented in other languages.
However I can take one current example.
The primary documentation for picins happens to be in german. If I
were looking for the documentation for the package under the
doc/<package> scheme then I find the documentation, and well I can't
read German, but that is my fault, and I could probably get enough out
of the examples to get by. However under the doc/<language> system
that you suggest, then either I have to search all the directories (as
I may not know which language the documentation is written in) or if I
use your `filtering' example, then I dont see the documentation at
all.
[Actually picins now has a small summary documention in English, but
that is beside the point, one could imagine some package with
documentation in some language...]
As Alan pointed out the doc/<language> system is better for if someone
wants to `browse' the general documentation, (or for cases like your
microwave example, where *all* the documentation is available in *all*
the languages) but in this case it is technical documentation of
specific packages, which may appear in one or more, but almost never
all, of the languages. Therefore it seems better to have a `package
first' organisation, as it is better to find some documentation in a
language you don't understand, than to find no information at all.
David
PS
I have no pets, children or microwaves, so I can not contribute to
the sub-plot of this thread.
================================================================================
From owner-twg-tds@shsu.edu Thu, 29 Feb 1996 07:37:56 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0ts8H2-0001iQC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 29 Feb 96 13:20 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
>Ah, thanks; I see your point now. I think you misunderstood me.
>Consider the practical case of an English-speaking user who knows
>only English and French, but who does not know German, Dutch,
>Chinese, Japanese etc. Under my scheme, he will have only two
>folders, one pointing to doc/us (or doc/en) and another pointing
>to doc/fr.
That assumes that the user would rather have no documentation at all
rather than documentation in (eg) German. I for one would rather have
documentation in any language than none at all (I can still read the
code examples if nothing else).
And I'll say it again: most packages are only documented in one
language. Very few have documenation in many languages, and most of
those would (like David's example) have most of the documentation in
one language, with a little summary in another (so splitting the
documentation makes no sense). I see no reason to make 99% of
people's lives inconvenient in order to make the 1% of packages with
documentation in more than one language better.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Thu, 29 Feb 1996 10:23:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Feb 1996 17:12:46 +0100
From: Michel LAVAUD <lavaud@centre.univ-orleans.fr>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199602291612.RAA07893@centre.univ-orleans.fr>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
David CARLISLE wrote:
> The primary documentation for picins happens to be in german. If I
> were looking for the documentation for the package under the
> doc/<package> scheme then I find the documentation, and well I can't
> read German, but that is my fault, and I could probably get enough out
> of the examples to get by. However under the doc/<language> system
> that you suggest, then either I have to search all the directories (as
> I may not know which language the documentation is written in) or if I
> use your `filtering' example, then I dont see the documentation at
> all.
Ah yes, thanks, I can understand you better now. I remember
bm2font only had doc in German, in its first versions; there is
also a translator from Winword to LaTeX whose doc is only in
French, too. However:
- I am not convinced it is a good idea to encourage users to use
a package if they have no documentation? I fear it could spread
the idea that TeX is "amateur" software.
- When such packages are really very interesting, somebody (if
not the author) will soon provide a doc in English (cf. the
example of bm2font, whose complete doc is now available in
English). The status of "excellent package with no doc in
English" is just a transient state, and their number stays
permanently close to zero. IMHO, better let users wait for next
version of the package, with a doc they can understand.
If it seems really mandatory: maybe add a file doc/en/no_en.doc
where these few packages with no English doc are listed, with a
short description of what they do, for those who would like to
test ?
Michel Lavaud (lavaud@univ-orleans.fr)
From owner-twg-tds@shsu.edu Fri, 01 Mar 1996 00:21:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 1 Mar 1996 07:21:58 +0100
From: Michel LAVAUD <lavaud@centre.univ-orleans.fr>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199603010621.HAA19713@centre.univ-orleans.fr>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
Alan JEFFREY wrote:
> That assumes that the user would rather have no documentation at all
> rather than documentation in (eg) German. I for one would rather have
> documentation in any language than none at all (I can still read the
> code examples if nothing else).
One question about doc/package scheme: where would you put doc of
dvips in English, French, and German? In:
doc/dvips/english/dvips.tex for English doc,
doc/dvips/francais/dvips.tex for French doc,
doc/dvips/deutsch/dvips.tex for German doc
or would you put English doc in doc/dvips/dvips.tex?
For picins doc, would you put it in
doc/.../picins/deutsch/picins.tex
or in
doc/.../picins/picins.tex,
and translation in English in
doc/.../picins/english/picins.tex
Michel Lavaud (lavaud@univ-orleans.fr)
================================================================================
From owner-twg-tds@shsu.edu Fri, 01 Mar 1996 05:28:53 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0tsSup-0001iQC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 1 Mar 96 11:22 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
>One question about doc/package scheme: where would you put doc of
>dvips in English, French, and German? In:
I think this should be up to the package writer. Personally I'd use
something like:
doc/dvips/dvips.tex (master)
doc/dvips/dvips-fr.tex (french translation)
doc/dvips/dvips-de.tex (german translation)
etc. possibly with a symbolic link dvips-en.tex -> dvips.tex.
The only thing we have to standardize is the directory structure. If
we say `doc/dvips/<files>' then we can leave the contents up to Tom.
Alan.
================================================================================
From owner-twg-tds@shsu.edu Fri, 01 Mar 1996 11:44:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 1 Mar 1996 18:42:10 +0100
From: Michel LAVAUD <lavaud@centre.univ-orleans.fr>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199603011742.SAA17638@centre.univ-orleans.fr>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
> >One question about doc/package scheme: where would you put doc of
> >dvips in English, French, and German? In:
>
> I think this should be up to the package writer. Personally I'd use
> something like:
>
> doc/dvips/dvips.tex (master)
> doc/dvips/dvips-fr.tex (french translation)
> doc/dvips/dvips-de.tex (german translation)
>
> etc. possibly with a symbolic link dvips-en.tex -> dvips.tex.
Ah! So, Adobe and other commercial editors would be generously provided
with complete subtrees in TDS, while frog-eaters and beer-drinkers ought to
be content with a few patches :-) No, seriously: your proposal would raise
more problems than it would solve. What about TexShell and other packages
with 6 to 8 letters, how would you truncate them? How could you manage
automatically with scripts, a mass of hand-made patches? And, if this is
acceptable for languages, why TDS at all: just put back all the tfm files
in one directory as it was before, all metafont files in another, etc.
I think that the problems are quite clear now, after this
discussion. It is better, for the time being, I forget about TDS
proposals for doc, go on translating important docs into French
with other members of AsTeX association, and try to organize
these the way we think could be best for French users. Then, back
again to TDS to see if/how work done can fit into it (or its
future state, I am confident it will be improved).
And thanks to everybody for remarks, it was a pleasure to
discuss.
Michel Lavaud (lavaud@univ-orleans.fr)
================================================================================
From owner-twg-tds@shsu.edu Sat, 02 Mar 1996 06:07:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 2 Mar 96 12:06:00 GMT
Message-ID: <9603021206.AA13726@r8d.cs.man.ac.uk>
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: Michel LAVAUD <lavaud@centre.univ-orleans.fr>
Subject: Re: Which place for docs in French, German, etc?
> It is better, for the time being, I forget about TDS
> proposals for doc, go on translating important docs into French
> with other members of AsTeX association, and try to organize
> these the way we think could be best for French users.
I hope that this does not imply that you were upset with the reaction
on this list to your suggestion. As anyone who has followed this list
for any time will confirm, the style of discussion here is rather
argumentative:-) but that doesn't mean agreement can not be reached...
In fact this comment of yours perhaps suggests your different viewpoint
(and suggests you might be right after all) I think that I would
prefer to see a `package first' organisation if the availabilty of
documentation in other languages was very low, as otherwise the
doc/<language> trees are very sparse, and I do think it would make it
harder rather than easier for people to find information, however if
as you hint above, plans are underway to provide rather large amounts
of non-English docs then a doc/<language> scheme looks a lot more
attractive as it would make sense for a native french speaker (say) to
look first in doc/french and have some reasonable chance of finding
some relevant documentation.
David
================================================================================
From owner-twg-tds@shsu.edu Sat, 02 Mar 1996 17:28:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 3 Mar 1996 00:26:27 +0100
Message-ID: <199603022326.AAA18808@spelunke.iti.informatik.th-darmstadt.de>
From: Joachim Schrod <jschrod@acm.org>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
References: <9602281816.AA17755@r8h.cs.man.ac.uk>
>>>>> "DC" == David Carlisle <carlisle@cs.man.ac.uk> writes:
>> using the 2 letter codes is also a good idea to prevent upset and
>> confusion. i am afraid we would have to have "us" for english, sigh.
DC> Like Alan I'm not really convinced that doc/<language> is really an
DC> improvement, but I could live with it.
DC> However
DC> doc/us
DC> is fairly horrible
Why? Doesn't this mean docs 'r' us?
Joachim
PS: I don't like the language subdirectories, as I don't see many
packages with documentation in multiple languages.
================================================================================
From owner-twg-tds@shsu.edu Sat, 02 Mar 1996 20:04:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 3 Mar 1996 03:04:06 +0100
Message-ID: <199603030204.DAA21338@spelunke.iti.informatik.th-darmstadt.de>
From: Joachim Schrod <jschrod@acm.org>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
References: <199603011742.SAA17638@centre.univ-orleans.fr>
>>>>> "ML" == Michel LAVAUD <lavaud@centre.univ-orleans.fr> writes:
ML> Ah! So, Adobe and other commercial editors would be generously provided
ML> with complete subtrees in TDS,
ML> I think that the problems are quite clear now, after this
ML> discussion. It is better, for the time being, I forget about TDS
ML> proposals for doc, go on translating important docs into French
ML> with other members of AsTeX association, and try to organize
ML> these the way we think could be best for French users.
I think, that would be a bad decision.
_When_ there is a large amount of french documentation translations
available, we should _add_ doc/french/<package>/ to our doc/<package>/
scheme. As long as this is future not existing stuff, I'm reluctant to
lobby for its addition.
You moan that we provide Adobe and other commercial editors with space
in the TDS tree. The difference is plain and simple: Their stuff
exists right _now_ -- and it was a principle in the TDS development
that we don't standardize future stuff, but concentrate on the
consolidation of existing material. Provide the TeX community with
french translations of all major documentation parts, they will surely
thank you many times for that. _Then_ we'll add a french/ subdir to
doc/. (Actually, that is already part of the TDS: then you'll provide
a package called `french' where you decide for the structure beneath.)
I have seen three translation projects started and not finished in the
past, and would rather like to wait for results before we change the
doc/ structure in the radical manner you came up with. Please note
that that comment shall not degrade your effort, they will be a big
enhancements to the current state of affairs -- but the last dozen
years I have been involved in TeX projects have taught me to be
careful in changing existing working stuff due to announcements.
Regards,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: jschrod@acm.org
Roedermark, Germany
Net & publication consultant
================================================================================
From owner-twg-tds@shsu.edu Mon, 04 Mar 1996 03:58:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 4 Mar 1996 09:51:29 GMT
Message-ID: <199603040951.JAA08164@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
CC: lavaud@centre.univ-orleans.fr
Subject: Re: Which place for docs in French, German, etc?
References: <9603021206.AA13726@r8d.cs.man.ac.uk>
what we could do is have a TDS agreement that a
doc/<language>
tree can be used if appropriate, but that it is intended only
for translations. the *definitive* documentation should appear in
doc/<package>
as before, regardless of language. if the original documentation is in
French, it could be linked to
doc/francais/<package>
if the site is building a
doc/francais
documentation tree
it would equally apply that a site might well create a
doc/english
tree, and populate it with translations or links
summary:
- doc/<package> is for the author's documentation, in any language
- doc/<language>/<package> is for translations or links or
configurations (the latter could include US paper size in PS
files)
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 04 Mar 1996 03:58:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 4 Mar 1996 10:57:13 +0100
Message-ID: <9603040957.AA17504@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Alan wrote:
> I think this should be up to the package writer. Personally I'd use
> something like:
>
> doc/dvips/dvips.tex (master)
> doc/dvips/dvips-fr.tex (french translation)
> doc/dvips/dvips-de.tex (german translation)
>
> etc. possibly with a symbolic link dvips-en.tex -> dvips.tex.
Given that only very few packages have documentation in multiple
languages, I'd tend to support this approach of putting all the
available documentation for some package into the same directory.
However, I doubt whether Alan's naming scheme is a workable solution
if the package name is too long (i.e. longer than 5 characaters)
or if the documentation sources (possibly consisting of multiple
files per language) should be kept along with the .dvi/.ps files.
In that case there could be good reasons to use subdirectories
per language below doc/<category>/<package>/, but only for those
packages where documentation in multiple languages exists, i.e.
something like
texmf/doc/<category>/<package>/[<language>/]...
where <language> would be an optional level, only if needed.
In principle, I wouldn't have anything against a doc/<language>/...
approach either, if documentation were generally available in
multiple languages, but since that is currently not the case,
it seems not worthwhile at present. Better find documentation
in whatever language it is available than nothing at all.
What I really wouldn't like, however, is an inconsistent approach
of having a doc/<language>/ directory as a fallback or catch-all
in between the doc/<category>/ directories, as it is currently
the case in teTeX and Sebastian's CD. Here, doc/german/<package>
mostly corresponds to doc/latex/<package>, but doc/german/misc
also includes stuff that really belongs into doc/general/.
I'd really like to see that sorted out before the CD comes out.
Cheers, Ulrik.
P.S. Even if a German translation of an English manual or book
is available, I'd personally tend to prefer the English version,
since that is the original and therefore probably more accuarate
and reliable than any translation. Besides, German translations
of Computer English often tend to be somewhat awkward since many
technical terms don't have a good translation in German, so one
ends up with Anglicized German (or Germanized English?), which
might be much worse to read than the original in real English.
(My preferences might be slightly different for a German original
with an English translation, in which case I'd use both versions.)
================================================================================
From owner-twg-tds@shsu.edu Mon, 04 Mar 1996 04:26:46 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 4 Mar 1996 11:25:11 +0100
From: Michel LAVAUD <lavaud@centre.univ-orleans.fr>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199603041025.LAA07926@centre.univ-orleans.fr>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
> I hope that this does not imply that you were upset with the reaction
> on this list to your suggestion. As anyone who has followed this list
> for any time will confirm, the style of discussion here is rather
> argumentative:-) but that doesn't mean agreement can not be reached...
No, I am not at all upset, I was just joking about frogs and
beer. I was just serious in saying "dvips-fr" would be a bad
choice, in my opinion. It is quite normal in science, to use
different solutions to solve different problems. If a colleague
tells me it is not necessary to use quantum mechanics to solve
his problem, I do agree, of course. Why would he be bothered with
unnecessary complications? On the other hand, the fact that my
colleague has no necessity of QM does not mean I have not to use
it, if my problem requires it. As for French doc, the scheme
"dvips-fr" is not satisfactory, so people who will translate have
to use something else, I did not imply more than that.
> I have seen three translation projects started and not finished in the
> past, and would rather like to wait for results before we change the
> doc/ structure in the radical manner you came up with. Please note
> that that comment shall not degrade your effort, they will be a big
> enhancements to the current state of affairs -- but the last dozen
> years I have been involved in TeX projects have taught me to be
> careful in changing existing working stuff due to announcements.
Yes, I do agree, and this is precisely what I said: let TDS as it
is, do the translation work with our own internal organization of
files, then go back to TDS and see what we can do.
Michel Lavaud (lavaud@univ-orleans.fr)
================================================================================
From owner-twg-tds@shsu.edu Mon, 04 Mar 1996 04:32:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 4 Mar 96 10:30:52 GMT
Message-ID: <9603041030.AA23811@r8h.cs.man.ac.uk>
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: lavaud@centre.univ-orleans.fr
Subject: Re: Which place for docs in French, German, etc?
summary:
- doc/<package> is for the author's documentation, in any language
- doc/<language>/<package> is for translations or links or
configurations (the latter could include US paper size in PS
files)
sebastian
Sounds OK to me.
David
================================================================================
From owner-twg-tds@shsu.edu Mon, 04 Mar 1996 05:18:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 4 Mar 1996 12:16:49 +0100
From: Michel LAVAUD <lavaud@centre.univ-orleans.fr>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199603041116.MAA08980@centre.univ-orleans.fr>
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
> summary:
> - doc/<package> is for the author's documentation, in any language
> - doc/<language>/<package> is for translations or links or
> configurations (the latter could include US paper size in PS
> files)
>
> sebastian
>
> Sounds OK to me.
>
> David
This sounds OK to me too.
Michel Lavaud (lavaud@univ-orleans.fr)
================================================================================
From owner-twg-tds@shsu.edu Mon, 04 Mar 1996 05:32:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 4 Mar 1996 11:29:17 GMT
Message-ID: <199603041129.LAA09109@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: Which place for docs in French, German, etc?
References: <199603041116.MAA08980@centre.univ-orleans.fr>
> > summary:
> > - doc/<package> is for the author's documentation, in any language
> > - doc/<language>/<package> is for translations or links or
> > configurations (the latter could include US paper size in PS
> > files)
> >
> > sebastian
> >
> > Sounds OK to me.
> This sounds OK to me too.
come, two OKs in one day. this is progress. now, if Alan, Michel and Joachim
agree (as being people who have commented), then we can assume
consensus, and work up a new paragraph for TDS 1.0. Do NOT forget that
we have to produce this! what we just published in TUGboat is not the
end yet.
One thing i would like added is an explicit statement about
subdirectories for bibtex/bst and bibtex/bib
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 04 Mar 1996 06:30:13 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0ttZJ4-0001iQC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 4 Mar 96 12:24 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@shsu.edu
Subject: Re: Which place for docs in French, German, etc?
>come, two OKs in one day. this is progress. now, if Alan, Michel and Joachim
>agree (as being people who have commented), then we can assume
>consensus, and work up a new paragraph for TDS 1.0.
Seems as good a compromise as we're likely to get...
Alan.
================================================================================
From owner-twg-tds@shsu.edu Mon, 04 Mar 1996 06:35:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 4 Mar 1996 13:35:07 +0100
Message-ID: <199603041235.NAA26022@spelunke.iti.informatik.th-darmstadt.de>
From: Joachim Schrod <jschrod@acm.org>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Which place for docs in French, German, etc?
References: <199603041116.MAA08980@centre.univ-orleans.fr> <199603041129.LAA09109@cadair.elsevier.co.uk>
>>>>> "SR" == Sebastian Rahtz <s.rahtz@elsevier.co.uk> writes:
>> > summary:
>> > - doc/<package> is for the author's documentation, in any language
>> > - doc/<language>/<package> is for translations or links or
>> > configurations (the latter could include US paper size in PS
>> > files)
>> >
>> > sebastian
>> >
>> > Sounds OK to me.
>> This sounds OK to me too.
SR> come, two OKs in one day. this is progress. now, if Alan, Michel
SR> and Joachim agree
As this is exactly my previous statement on this thread, why should I
disagree?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: jschrod@acm.org
Roedermark, Germany
Net & publication consultant
================================================================================
From owner-twg-tds@shsu.edu Mon, 04 Mar 1996 09:08:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 4 Mar 1996 14:49:55 GMT
Message-ID: <199603041449.OAA10553@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: Which place for docs in French, German, etc?
References: <199603041116.MAA08980@centre.univ-orleans.fr> <199603041129.LAA09109@cadair.elsevier.co.uk> <199603041235.NAA26022@spelunke.iti.informatik.th-darmstadt.de>
> As this is exactly my previous statement on this thread, why should I
> disagree?
innate bloody-mindedness? curiousity to see what would happen?
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 14 Mar 1996 12:30:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Mar 96 18:18:37 GMT
Message-ID: <9603141818.AA08431@r8h.cs.man.ac.uk>
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: tanmoy@gita.lanl.gov
Subject: [tanmoy@gita.lanl.gov: CTAN archives]
I have already replied to Tanmoy pointing at the TDS draft report on
ctan (and the FILES.bydate file) but some others on this list may
also want to comment....
David
------- Start of forwarded message -------
Return-Path: <tanmoy@gita.lanl.gov>
Date: Thu, 14 Mar 1996 10:13:20 -0700 (MST)
From: Tanmoy Bhattacharya <tanmoy@gita.lanl.gov>
To: David Carlisle <carlisle@cs.man.ac.uk>
Subject: CTAN archives
Hi,
I do not know who to send this to, but I thought you would certainly
know the right person ... so I send it to you. I apologize for this
intrusion.
I am the resident `texspert' for the e-print database we run at
LANL. Most of the submission we get are in different flavours of tex,
and we actually encourage this format from the authors. As we like to
keep the restrictions on authors at the minimum level compatible with
automatic processing of their submissions, what we receive tends to be
in a wide variety of formats. This poses some special problems for us,
and we are looking to see if we can get some help in this regard.
Basically, we need to maintain a complete upto-date version of all the
widely used standardized macro packages currently available alongwith
previous versions if the current one is not backward compatible. Even
after thinking long and hard, I could not find any way to automate the
process of upgrading our LaTeX distribution. The base files are fine:
but the contributed software seems to be a mess.
I have three suggestions:
1) Could one set up a mailing list where _all_ upgrades to the
packages (base/packages/contrib-supported/contrib-others) will
receive notification. This will at least allow me to upgrade only
those packages that need upgrading. (Currently I spend a day every
year upgrading everything!)
2) A `quote site list <date> <root>' command at the CTAN
sites which lists for me every package in the directory tree under
<root> that has changed since <date>?
3) Could the packages be made more consistent? i.e. Require that every
supported package have a .ins file with the following properties:
a) It always writes out in a consistent format what files are
produced and where they should go. A suggestion would be that
it end with lines of output which say, for example:
The following files should be installed:
file.cls LATEXINPUTS
file.sty LATEX209INPUTS
file.tex LATEXINPUTS
file.fd LATEXINPUTS
file.mf LAMFINPUTS
file.bst INDEXINPUTS
It turns out that relying on the extension is not always the
best.
b) Instead of (a) a Makefile which includes ../../paths.mk (or
something similar) and uses no hardwired program or path names
(i.e. uses $(LATEXINPUTS), $(LATEXPROGRAM) etc.) is an
alternative. I would like to be able to not produce
documentation: we do not need it ... our authors do :-)
c) It has a machine readable file which tells me if the change
from the last version is backward compatible or not.
d) An unrelated issue: if the package writer knows that the
package conflicts with others, a machine readable file
documenting that fact. This should actually be implemented in
the code (i.e. like RequirePackage, there should be an
InhibitPackage command).
Could you please pass this on to the right people?
Thanks a lot
Tanmoy
------- End of forwarded message -------
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Mar 1996 02:49:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 15 Mar 1996 08:37:51 GMT
Message-ID: <199603150837.IAA23257@cadair.elsevier.co.uk>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
CC: tanmoy@gita.lanl.gov
Subject: Re: [tanmoy@gita.lanl.gov: CTAN archives]
References: <9603141818.AA08431@r8h.cs.man.ac.uk>
David Carlisle writes:
> previous versions if the current one is not backward compatible. Even
> after thinking long and hard, I could not find any way to automate the
> process of upgrading our LaTeX distribution. The base files are fine:
> but the contributed software seems to be a mess.
well, the key word is "contributed"; thats why there is a distinction
between what the core team write and maintain, and what others offer
out of goodwill.
> 1) Could one set up a mailing list where _all_ upgrades to the
> packages (base/packages/contrib-supported/contrib-others) will
> receive notification. This will at least allow me to upgrade only
we have ctan-ann for this purpose, though its not used enough
> 2) A `quote site list <date> <root>' command at the CTAN
> sites which lists for me every package in the directory tree under
> <root> that has changed since <date>?
we can do this, i guess. if someone else wrote the script, it would
get done faster! (work on the basis of processing FILES.byname)
> 3) Could the packages be made more consistent? i.e. Require that every
> supported package have a .ins file with the following properties:
we're still awaiting adoption of the guidelines, i am afraid
> file.cls LATEXINPUTS
> file.sty LATEX209INPUTS
> file.tex LATEXINPUTS
> file.fd LATEXINPUTS
> file.mf LAMFINPUTS
> file.bst INDEXINPUTS
>
> It turns out that relying on the extension is not always the
> best.
> b) Instead of (a) a Makefile which includes ../../paths.mk (or
> something similar) and uses no hardwired program or path names
> (i.e. uses $(LATEXINPUTS), $(LATEXPROGRAM) etc.) is an
all thats needed is a defintion of TEXMF, and then follow the TDS
guidelines
> Could you please pass this on to the right people?
hang on, there *are* no "right people"; the LaTeX community is all of
us, not a committee. the CTAN maintainers could publish guidelines
and refuse things that didnt meet them, but we have no resources for
testing submissions.
you might be amused, tanmoy, to hear that i am creating a Unix
readytorun CD for TUG; among other things i wrote a Perl script to
process all latex contrib packages consistently and install them in a
TDS layout. it can be done, even with what we have now.
if we want a well-managed LaTeX world, we have to invest time and
money into managing it. This group (the TDS) represents many many
hours of people's free time, and i suspect that in many cases it has
used up their mental allocation of time they can spend on such
matters. the TDS was a vital stage in the development of a rational
LaTeX world, now we have to start over again and develop guidelines
for authors. Can i be the only one who simply feels *tired*? this is
too big an operation to do in people's spare time.
tanmoy could always ask paul ginsparg to put some of his NSF Grant
towards maintaining the LaTeX stup, of course :-}
sebastian
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Mar 1996 11:23:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 15 Mar 1996 12:20:20 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199603151720.AA14943@terminus.cs.umb.edu>
To: s.rahtz@elsevier.co.uk
CC: TWG-TDS@shsu.edu, tanmoy@gita.lanl.gov
Subject: Re: [tanmoy@gita.lanl.gov: CTAN archives]
> 1) Could one set up a mailing list where _all_ upgrades to the
> packages (base/packages/contrib-supported/contrib-others) will
> receive notification. This will at least allow me to upgrade only
we have ctan-ann for this purpose, though its not used enough
The main announcement list I know of, and try to use consistently, is
tex-archive@math.utah.edu. I think it would be a good thing if every
new release of anything that goes on ctan (or elsewhere!) was
accompanied by a message to tex-archive.
Aside: I could even envision some folks (me, for instance) liking an
automatically generated message -- ``the files on ctan that changed
today'' (or this week, or this month).
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Mar 1996 11:23:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 15 Mar 1996 12:20:19 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199603151720.AA14907@terminus.cs.umb.edu>
To: CHAA006@alpha1.rhbnc.ac.uk
CC: TWG-tds@SHSU.edu
Subject: Re: VMS & TDS: a summary so far
I can't agree with this: speed is purely a function of the processor,
I believe the speed of the disk is the limiting factor.
what do non-VMS TDS systems do?
As Sebastian said, web2c supports a file (ls-R) that contains a recursive
directory listing of all files in the tree. ls-R is read at the first
reference and serves as the ``cache''.
In the default configuration, if a file is not found in the cache, it is
then looked for on disk. Thus, if you install a new file in the tree, it
will be found (just very slowly, by comparison). (Many people disable
this, though, and use only the cache file -- their choice.)
If on the other hand you install a new file in the tree and an old file
by the same name (that can be found along the same paths) still exists
in the cache file and on the disk, then the old file will be
found. That's the price you pay.
is a compliant TeX required to do the same thing for TFM files?).
I don't understand what you mean. Caching is not required for TDS
compliance, because when we asked all the developers we could find, most
of them didn't want to commit to implementing it.
I want to be able to edit a file, create a new version, and _know_
TeX will find the new version the very next time it runs.
In that case, you obviously can't have a simple cache file as outlined
above. Your call.
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Mar 1996 12:56:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 15 Mar 1996 18:54:37 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: <960315185437.21e4130a@vms.rhbnc.ac.uk>
Subject: Re: VMS & TDS: a summary so far
Karl --
>> I can't agree with this: speed is purely a function of the processor,
>>
>> I believe the speed of the disk is the limiting factor.
True: I over-simplified.
>> what do non-VMS TDS systems do?
>> As Sebastian said, web2c supports a file (ls-R) that contains a recursive
>> directory listing of all files in the tree. ls-R is read at the first
>> reference and serves as the ``cache''.
>> In the default configuration, if a file is not found in the cache, it is
>> then looked for on disk. Thus, if you install a new file in the tree, it
>> will be found (just very slowly, by comparison).
A good algorithm: I like that.
>> (Many people disable
>> this, though, and use only the cache file -- their choice.)
Hmmm...
>> If on the other hand you install a new file in the tree and an old file
>> by the same name (that can be found along the same paths) still exists
>> in the cache file and on the disk, then the old file will be
>> found. That's the price you pay.
Not so good...
>> is a compliant TeX required to do the same thing for TFM files?).
>>
>> I don't understand what you mean. Caching is not required for TDS
>> compliance, because when we asked all the developers we could find, most
>> of them didn't want to commit to implementing it.
I wasn't referring to cacheing but to tree-searching: is a TDS-compliant
TeX required to tree-search for TeX files, TFM files _and_ format files?
>> I want to be able to edit a file, create a new version, and _know_
>> TeX will find the new version the very next time it runs.
>>
>> In that case, you obviously can't have a simple cache file as outlined
>> above. Your call.
It will be interesting to see whether the VMS file system cache could be
tuned to provide the functionality and performance that we need.
** Phil.
================================================================================
From owner-twg-tds@shsu.edu Fri, 15 Mar 1996 13:26:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 15 Mar 96 19:23:49 GMT
Message-ID: <9603151923.AA10219@r8h.cs.man.ac.uk>
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Subject: Re: VMS & TDS: a summary so far
> Not so good...
Actually it works out OK in practice, it is just that if you use a
`cache only' search path, then you should not use a basic copy command
to put a new file into the tree but rather always use a script that
updates the cache file.
As at most sites the `system' tree is not updated so often this is not
really a problem. The local directory is normally set to be searched
first in anycase, so files that you are working on their are found.
David
================================================================================
From owner-twg-tds@shsu.edu Sat, 16 Mar 1996 09:56:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 16 Mar 1996 14:26:59 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: [tanmoy@gita.lanl.gov: CTAN archives]
To: TWG-TDS@SHSU.edu
Message-ID: <01I2ER3ZRIMA8WW1AG@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
The major announce list I am on is CTAN-ANN (@shsu.edu), it gives a rather
comprehensive account of the CTAN News.
However, if you want to get daily change information, maybe you should set
up a mirror an get mirror update notices. The university of Mainz has a
partial mirror from which I get such notices (of course for the respective
part only).
--J"org Knappen.
================================================================================
From owner-twg-tds@shsu.edu Mon, 18 Mar 1996 03:47:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 18 Mar 1996 10:46:34 +0100
Message-ID: <9603180946.AA27705@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: [tanmoy@gita.lanl.gov: CTAN archives]
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Joerg writes:
> The major announce list I am on is CTAN-ANN (@shsu.edu), it gives a rather
> comprehensive account of the CTAN News.
Yes, definitely. I'm also subscbribed to "tex-archive", but that list
seems to be mostly idle quite unlike "ctan-ann". The only people I've
ever seen posting on "tex-archive" were Karl Berry and Nelson Beebe,
i.e. people maintaining their own archive sites independent from CTAN.
Judging from the volume, moving *all* announcements to "ctan-ann" would
seem more reasonable.
> However, if you want to get daily change information, maybe you should set
> up a mirror an get mirror update notices. The university of Mainz has a
> partial mirror from which I get such notices (of course for the respective
> part only).
There are other ways to get daily updates. For about a year or so my
daily morning routine (besides reading mail and news) included ftp'ing
the latests FILES.last07days. Now, I've set up a cron job to do it at
6 o'clock in the morning, sort it appropriately, and mail it to me,
so that I can read it with my other mail. Very convenient, I must say.
Cheers, Ulrik.
---- cut here ----
# Ulrik Vieth's crontab file
# (last modified 1995/08/29)
#
# Every moring at 6:00 get the most recent "FILES.last07days" from ftp.dante.de,
# sort the contents and send it by mail.
0 6 * * 1-5 /home/vieth/bin/ftpscript.last07days >/dev/null 2>&1
0 6 * * 0 /home/vieth/bin/ftpscript.byname >/dev/null 2>&1
---- cut here ----
#!/bin/sh
## This shell script is intended to be run from cron every night.
##
filename=FILES.last07days
# Connect to ftp.dante.de and retrieve the file FILES.last07days.
#
cd /home/vieth/FTP
ftp ftp.dante.de << EOF
cd tex-archive
get FILES.last07days
EOF
# Sort the list of file by date (reversed order) and by file name.
#
/opt/gnu/bin/sort -o $filename -k1,2r -k5 $filename
# If the file isn't too big, mail it to me, so that i can read it
# together with my other mail in the morning
#
if [ `wc -c $filename | awk '{print $1}'` -lt 60000 ];
then
cat $filename |\
/usr/ucb/mail -s "FILES.last07days as of `date | awk '{print $1,$2,$3,$NF}`" vieth
else
echo "Something big has arrived on ftp.dante.de" |\
/usr/ucb/mail -s "FILES.last07days is too big today" vieth
fi
---- cut here ----
#!/bin/sh
## This shell script is intended to be run from cron every weekend.
##
filename=FILES.byname.gz
# Connect to ftp.dante.de and retrieve the file FILES.byname.gz.
#
cd /home/vieth/FTP
ftp ftp.dante.de << EOF
bin
cd tex-archive
get FILES.byname.gz
EOF
From owner-twg-tds@shsu.edu Wed, 17 Apr 1996 12:24:12 CDT
Sender: owner-twg-tds@SHSU.edu
X-MX-Warning: Warning -- Invalid "From" header.
From: Dr. C. Michael McCallum <mccallum@dogbert.cop.uop.edu>
Reply-To: TWG-TDS@SHSU.edu
Subject: TDS
To: twg-tds@shsu.edu
Date: Wed, 17 Apr 1996 10:22:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hello, I am looking at the TDS document, and I am glad
that some uniform structure is being suggested for TeX;
however, I have one dislike, for both asthetics and ease-of-use.
The latex packages (such as "seminar" and "fancyheadings") belong
in texmf/tex/latex/{package}. But, aren't the latex .sty and .cls
files (among others) put there too? It can be a pain if you wish to
examine packages, and you have to wade through all the .fd, .clo, etc
files in the texmf/tex/latex directory. Has there been any discussion
about putting the "latex-package" files into a sub-dir, such as
texmf/tex/latex/latex ? I know this seems a bit silly, but at the moment
I am putting packages one level up, which is a TDS no-no, and I
am not completely happy with that either (especially since teTeX follows
the TDS).
This may have been addressed already, as I only have the Nov. 1995 TDS
here. I am retrieving the newest one now.
Thanks for listening!
Cheers,
Mike
--
C. Michael McCallum
| ...we don't have to pay
(209) 946-2393 Voice | for freedom, because
(209) 946-2607 Fax | Freedom is *free*, and
http://dogbert.cop.uop.edu/mccallum | that's as free as it gets!!
| --The Tick
================================================================================
From owner-twg-tds@shsu.edu Wed, 17 Apr 1996 12:44:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 17 Apr 96 18:42:31 BST
Message-ID: <9604171742.AA15748@r8h.cs.man.ac.uk>
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC:
Subject: Re: TDS
> Has there been any discussion
> about putting the "latex-package" files into a sub-dir, such as
> texmf/tex/latex/latex
Yes the core LaTeX files should go in
texmf/tex/latex/base
David
From owner-twg-tds@shsu.edu Tue, 07 May 1996 05:39:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 7 May 1996 11:38:14 +0100
Message-ID: <199605071038.LAA25313@lochnagarn>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@shsu.edu
Subject: TeX CD
Despite the lack of public comment from me, the TDSized CD (now called
"TeX Live") is nearly done. I shall be sending it for pressing next
weekend, ie in about 5 days time. If anyone wants to see the current
contents, see CTAN:info/tdscd/FILES.{ls-r,find}. There is still time
to change it, but not much.
What may be of interest to people here is the categorisation of
packages into "collections". The install program gets these from the
CD and onto local hard disk for you, and for each collection offers
you 3 types: "basic", "recommended" and "other". I append the list of
collections, and packages, in them (for contents see
CTAN:info/tdscd/lists.tar.gz), where 1, 2 and 3 are the types.
You will see that the distinction between "recommended" and "other" is
really my personal judgement (with input from Thomas). I'd appreciate
any (constructive!) thoughts to make this better.
the CD goes on sale in Paris on May 29th
sebastian
ams2/amstex
ams2/amslatex
ams2/amsfonts
bibtex1/bbtbase
bibtex2/beebe
bibtex2/harvard
bibtex2/natbib
bibtex2/bbtdoc
doc1/makeindex
doc1/general
doc2/tugboat
doc2/html
doc2/info
doc2/knuth
dvips3/aurora
dvips3/multi
dvips3/colorsep
fonts1/cm
fonts1/fontmisc
fonts2/dc
fonts2/bakoma
fonts2/cmbright
fonts2/cmextra
fonts2/concmath
fonts2/concrete
fonts2/ot2cyr
fonts2/stmaryrd
fonts2/wsuipa
fonts2/psnfss
fonts3/gray
fonts3/ascii
fonts3/astro
fonts3/barcodes
fonts3/bbm
fonts3/cherokee
fonts3/cirth
fonts3/cmpica
fonts3/dancers
fonts3/duerer
fonts3/elvish
fonts3/engwar
fonts3/fc
fonts3/futhark
fonts3/hands
fonts3/koma-script
fonts3/logic
fonts3/malvern
fonts3/oca
fonts3/ocr_a
fonts3/ocr_b
fonts3/ogham
fonts3/osmanian
fonts3/pandora
fonts3/phonetic
fonts3/plfonts
fonts3/punk
fonts3/sauter
fonts3/tengwar
fonts3/wasy
fonts3/adobe
fonts3/bh
fonts3/monotype
fonts3/urw
fonts3/bitstrea
fonts3/gothic
fonts3/pk-canonex
fonts3/pk-cx
fonts3/pk-deskjet
fonts3/pk-epson
fonts3/pk-ibmvga
fonts3/pk-ljfour
fonts3/pk-qms
fonts3/pk-toshiba
formats2/eplain
formats2/latex209
formats3/alatex
formats3/blue
formats3/lamstex
formats3/lollipop
formats3/phyzzx
formats3/psizzl
formats3/texip
formats3/text1
generic1/dvips
generic2/tugboat
generic3/ean
generic3/genmisc
generic3/midnight
generic3/musictex
generic3/musixtex
generic3/plgraph
generic3/siam
graphics2/pstricks
graphics2/xypic
graphics2/pictex
graphics2/eepic
graphics2/psfrag
graphics3/barr
graphics3/borceux
graphics3/circ
graphics3/curves
graphics3/dratex
graphics3/feynmf
graphics3/kuvio
graphics3/qobitree
graphics3/sprite
graphics3/taylor
graphics3/texdraw
lang1/babelformats
lang2/french
lang3/arabtex
lang3/devanagari
lang3/croatian
latex1/fonts
latex1/babel
latex1/mflogo
latex1/ltxbase
latex1/ltxdoc
latex1/lshort2e
latex2/carlisle
latex2/changebar
latex2/arseneau
latex2/seminar
latex2/wasysym
latex2/pspicture
latex2/ntgclass
latex2/misc209
latex2/fancyheadings
latex2/fancyvrb
latex2/rotating
latex2/ltxmisc
latex2/booktabs
latex2/calc
latex2/cite
latex2/jknappen
latex2/float
latex2/caption
latex2/custom-bib
latex2/german
latex2/graphics
latex2/tools
latex2/mfnfss
latex3/achemso
latex3/acronym
latex3/adrlist
latex3/aguplus
latex3/alg
latex3/algorithms
latex3/answers
latex3/beton
latex3/biblist
latex3/fontinst
latex3/calrsfs
latex3/camel
latex3/chemsym
latex3/cmcyralt
latex3/codepage
latex3/count1to
latex3/deleq
latex3/dialogl
latex3/dinbrief
latex3/dotseqn
latex3/draftcopy
latex3/elsevier
latex3/endfloat
latex3/envbig
latex3/eqnarray
latex3/euler
latex3/everyshi
latex3/exams
latex3/expdlist
latex3/fax
latex3/floatfig
latex3/floatflt
latex3/foiltex
latex3/footnpag
latex3/fp
latex3/g-brief
latex3/gb4e
latex3/harpoon
latex3/hh
latex3/hyper
latex3/hyperref
latex3/ieeepes
latex3/ifacmtg
latex3/inputenc
latex3/ipa
latex3/labels
latex3/lastpage
latex3/levy
latex3/lgreek
latex3/lineno
latex3/localloc
latex3/ltablex
latex3/mailing
latex3/mapcodes
latex3/maple
latex3/mcite
latex3/mdwtools
latex3/minitoc
latex3/monster
latex3/mslapa
latex3/piff
latex3/myletter
latex3/newalg
latex3/niceframe
latex3/nomencl
latex3/numline
latex3/objectz
latex3/ogonek
latex3/oldstyle
latex3/paper
latex3/parallel
latex3/pb-diagram
latex3/picinpar
latex3/prelim2e
latex3/prettyref
latex3/progkeys
latex3/program
latex3/qsymbols
latex3/rcs
latex3/realcalc
latex3/refman
latex3/revtex
latex3/rotfloat
latex3/rplain
latex3/script
latex3/semantic
latex3/textfit
latex3/setspace
latex3/shadethm
latex3/showlabels
latex3/siggraph
latex3/slidenotes
latex3/ssqquote
latex3/subeqnarray
latex3/subfigure
latex3/supertabular
latex3/textcomp
latex3/textmerg
latex3/thesis
latex3/treesvr
latex3/typehtml
latex3/ucthesis
latex3/ulsy
latex3/umlaute
latex3/utthesis
latex3/uwthesis
latex3/vdm
latex3/vector
latex3/vita
latex3/vrb
latex3/vrsion
latex3/williams
latex3/xymtex
latex3/yhmath
latex3/youngtab
latex3/zed-csp
latex3/koma-script
latex3/swift
latex3/apa
latex3/footnote
plain1/plaintex
plain1/plainmisc
plain3/calendar
plain3/cellular
plain3/harvmac
plain3/jsmisc
plain3/mnras
plain3/mtbe
plain3/newsletr
plain3/pdcmac
plain3/realcalc
plain3/tbe
plain3/treetex
plain3/vertex
plain3/patch
systems1/rs6000-aix3.2
systems1/sparc-solaris2.4
systems1/sparc-solaris2.5
systems1/sparc-sunos4.1.3
systems1/mips-irix5.2
systems1/mips-irix5.3
systems1/mips-ultrix4.4
systems1/i486-linux
systems1/i486-linuxaout
systems1/m68k-linux
systems1/m68k-linuxoldld
systems1/hppa1.1-hpux9.01
systems1/alpha-osf2.0
systems1/alpha-osf3.2
systems1/i386-bsdi2.0
systems1/i386-freebsd2.0.5
systems1/i386-freebsd2.1.0
systems1/i386-netbsd1.0
systems1/i386-netbsd1.1
systems1/m68k-nextstep3
systems1/rs6000-aix4.1.1
systems1/hppa1.1-hpux10.01
systems1/mab-nextstep3
tetex1/tetex
tetex1/config
tetex1/fontname
tetex1/tetexdoc
tetex1/faq
tetex2/extrabin
tetex2/auctex
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 May 1996 08:10:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 7 May 1996 15:09:15 +0200
Message-ID: <9605071309.AA29713@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: TeX CD
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sebastian wrote:
> You will see that the distinction between "recommended" and "other" is
> really my personal judgement (with input from Thomas). I'd appreciate
> any (constructive!) thoughts to make this better.
> doc1/makeindex
> doc1/general
> doc2/tugboat
> doc2/html
> doc2/info
> doc2/knuth
I'd consider moving doc/tugboat and possibly doc/knuth to category 3.
Who's going to look at TUGboat contents other than ``hard-core TeXies''?
Same for {tex,mf}book.tex, webman or {trip,trap}man.
> generic3/genmisc
Hmm, not sure what's inside, but perhaps it includes some stuff deservers
higher priority (cf. plain1/plainmisc)?
> fonts2/bakoma
> fonts2/cmbright
> fonts2/cmextra
> fonts2/concmath
> fonts2/concrete
> fonts2/ot2cyr
> fonts2/stmaryrd
> fonts2/wsuipa
> fonts2/psnfss
I'd more or less agree with that -- perhaps not with everything but
with most of it. However, I see a problem here. What use will be
fonts/concrete in category `2' when the supporting macros latex/beton
and latex/euler are in `3'. Similarly, what use will be the macros
in latex/mfnfss in `2' when the required fonts/pandora are in `3'.
This ought to be sorted out better and made more consistent.
> latex3/revtex
This is arguable depending on one's background. In a physics department
latex/revtex is equally important as ams/amslatex or even much more so.
It might be a good idea to put all kinds of publisher macros in the same
category to be fair to users in all fields. However, I'm not sure myself
if they should go in category `2' or `3'.
OK, these are my first quick comments. I might look at the stuff on
CTAN:info/tdscd more closely later if I find the time.
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Tue, 07 May 1996 08:47:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 7 May 1996 14:46:23 +0100
Message-ID: <199605071346.OAA04321@lochnagarn>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: TeX CD
References: <9605071309.AA29713@macbeth.uni-duesseldorf.de>
Ulrik Vieth writes:
> I'd consider moving doc/tugboat and possibly doc/knuth to category
> 3. Who's going to look at TUGboat contents other than ``hard-core
> TeXies''? Same for {tex,mf}book.tex, webman or {trip,trap}man.
i dont quarrel with that. ok will do
> > generic3/genmisc
> Hmm, not sure what's inside, but perhaps it includes some stuff
> deservers higher priority (cf. plain1/plainmisc)?
it looks like rubbish to me, but then what do i know? who uses plain
anyway?
> with most of it. However, I see a problem here. What use will be
> fonts/concrete in category `2' when the supporting macros
> latex/beton and latex/euler are in `3'. Similarly, what use will
> be the macros in latex/mfnfss in `2' when the required
> fonts/pandora are in `3'.
whoops. thats the kind of thing i needed help on, just as you have
provided. thanks! i have moved it all to 3
> This ought to be sorted out better and made more consistent.
> > latex3/revtex
> This is arguable depending on one's background. In a physics
> department latex/revtex is equally important as ams/amslatex or
> even much more
but i *hate* revtex so much :-}
ok it moves to 2
> It might be a good idea to put all kinds of publisher macros in the
> same category to be fair to users in all fields.
i didnt even put in Springer ;-}
> However, I'm not sure myself
> if they should go in category `2' or `3'.
2, probably, if in doubt
> OK, these are my first quick comments. I might look at the stuff
> on CTAN:info/tdscd more closely later if I find the time.
dont get me *too* upset, i only have a few days :-}
thanks
sebastian
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 May 1996 04:51:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 May 1996 11:49:37 +0200
Message-ID: <9605080949.AA00400@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: TeX CD
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
> Despite the lack of public comment from me, the TDSized CD (now called
> "TeX Live") is nearly done. I shall be sending it for pressing next
> weekend, ie in about 5 days time. If anyone wants to see the current
> contents, see CTAN:info/tdscd/FILES.{ls-r,find}. There is still time
> to change it, but not much.
A few more comments regarding Sebastian's CD contents. I had a quick
through tdscd/FILES.find (which I had to retrieve from ftp.tex.ac.uk
since it was missing on ftp.dante.de) and here's what I spotted:
./texmf/doc/tex/astro/astrosym.doc
./texmf/doc/tex/astro/astrosym.tex
./texmf/doc/tex/astro/astrosym.dvi
./texmf/doc/tex/tengwar/quenya.dvi
./texmf/doc/tex/tengwar/sindarin.dvi
./texmf/doc/tex/tengwar/quenya.tex
./texmf/doc/tex/tengwar/sindarin.tex
What are these doing here? I'd say they belong into texmf/doc/fonts/...
In my understanding temxf/doc/tex is only for documentation about TeX
itself, i.e. mostly Knuth's own stuff.
./texmf/doc/pdf/index/style/style.ddd
./texmf/doc/pdf/index/style/style.did
./texmf/doc/pdf/index/style/style.plc
./texmf/doc/pdf/index/style/style.pdd
./texmf/doc/pdf/index/style/style.stp
./texmf/doc/pdf/index/style/style.wld
./texmf/doc/pdf/index/trans/data.trn
./texmf/doc/pdf/index/trans/acrocat.cat
./texmf/doc/pdf/index/work/tb5df567.wrk
./texmf/doc/pdf/index/work/tb5df6a9.wrk
./texmf/doc/pdf/index/work/acrocat.cat
./texmf/doc/pdf/index/morgue/acrocat.cat
./texmf/doc/pdf/index/pdd/00000001.pdd
./texmf/doc/pdf/index/parts/00000000.ddd
./texmf/doc/pdf/index/parts/00000000.did
./texmf/doc/pdf/index/temp/t572ebb1.abt
./texmf/doc/pdf/index/temp/t572e97b.abt
./texmf/doc/pdf/index/temp/acrocat.cat
./texmf/doc/pdf/index/temp/t0756243.abt
./texmf/doc/pdf/index/assists/00000001.wld
./texmf/doc/pdf/index/assists/00000001.abt
./texmf/doc/pdf/index/assists/00000002.abt
./texmf/doc/pdf/index/assists/00000003.abt
./texmf/doc/pdf/index/assists/acrocat.cat
./texmf/doc/pdf/index/topicidx/acrocat.cat
What's this stuff? Does it have any deeper meaning or is this some
temporary junk left over from PDF distillation runs? At least to me
it sort of looks like junk, but I'm certainly not an Acrobat guru.
./texmf/fonts/pk/cx/tmp/dpi518/yinitdd.pk
./texmf/fonts/pk/cx/tmp/dpi518/yinit.pk
./texmf/fonts/pk/cx/tmp/dpi300/cirth.pk
./texmf/fonts/pk/cx/tmp/dpi300/cmb10.pk
./texmf/fonts/pk/cx/tmp/dpi432/tengwar.pk
./texmf/fonts/pk/cx/tmp/dpi329/cmb10.pk
./texmf/fonts/pk/cx/tmp/dpi360/cmb10.pk
./texmf/fonts/pk/cx/tmp/dpi240/cmb10.pk
./texmf/fonts/pk/cx/tmp/dpi660/cmb10.pk
./texmf/fonts/pk/cx/tmp/dpi420/cmb10.pk
./texmf/fonts/pk/ljfour/tmp/dpi600/cmbr10.pk
./texmf/fonts/pk/ljfour/tmp/dpi600/cmbr17.pk
./texmf/fonts/pk/ljfour/tmp/dpi600/cmbr8.pk
[...]
Hmm, why fonts/pk/<mode>/tmp? Perhaps, something misconfigured or
missing in fontnames/special.map?
./texmf/fonts/pk/ljfour/ams/extracm/dpi600/pktmp.15458
This looks like something went wrong during a MakeTeXPK run once.
/texmf/fonts/tfm/tmp/cirbf.tfm
./texmf/fonts/tfm/tmp/cirsl.tfm
./texmf/fonts/tfm/tmp/cirss.tfm
./texmf/fonts/tfm/tmp/cirth.tfm
./texmf/fonts/tfm/tmp/cherokee.tfm
./texmf/fonts/tfm/tmp/dancers.tfm
./texmf/fonts/tfm/tmp/cdb10.tfm
./texmf/fonts/tfm/tmp/cdtt10.tfm
./texmf/fonts/tfm/tmp/teng10.tfm
./texmf/fonts/tfm/tmp/hands.tfm
./texmf/fonts/tfm/tmp/ogham.tfm
./texmf/fonts/tfm/tmp/tengwar.tfm
./texmf/fonts/tfm/tmp/devpn10.tfm
./texmf/fonts/tfm/tmp/dvng10.tfm
./texmf/fonts/tfm/tmp/dvng8.tfm
./texmf/fonts/tfm/tmp/dvng9.tfm
./texmf/fonts/tfm/tmp/musikn20.tfm
./texmf/fonts/tfm/tmp/musikn16.tfm
./texmf/fonts/tfm/tmp/musikn13.tfm
./texmf/fonts/tfm/tmp/musikn11.tfm
./texmf/fonts/tfm/tmp/musicbra.tfm
Again why fonts/.../tmp? Same as above.
./emacs/lisp/auctex/style/amsart.elc
./emacs/lisp/auctex/style/amsbook.elc
./emacs/lisp/auctex/style/amstex.elc
./emacs/lisp/auctex/style/article.elc
./emacs/lisp/auctex/style/book.elc
./emacs/lisp/auctex/style/dinbrief.elc
./emacs/lisp/auctex/style/dk.elc
./emacs/lisp/auctex/style/dutch.elc
./emacs/lisp/auctex/style/epsf.elc
./emacs/lisp/auctex/style/foils.elc
./emacs/lisp/auctex/style/german.elc
./emacs/lisp/auctex/style/harvard.elc
[...]
For which Emacs have these .elc files been byte-compiled? If you're
unlucky, files compiled with a recent GNU Emacs might be completely
unusuable with XEmacs or with some older versions of GNU Emacs, etc.
Since this is a very situation, just providing the raw .el files
would be safer, i.e. more portable, albeit a little slower to use.
Another alternative might be using subdirectories emacs/<system>
just as we have bin/<system>.
That's all I noted so far on a quick review. I haven't got time at
the moment to study things in detail, so I might well have overlooked
something. However, there must be always be room for improvements
in the second edition ;-) According to Murphy's law, you'll probably
discover the first bug as soon as you unpack the first copy of the
final product. Never mind, that's life.
Cheers, Ulrik.
================================================================================
From owner-twg-tds@shsu.edu Wed, 08 May 1996 09:52:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 May 1996 15:51:27 +0100
Message-ID: <199605081451.PAA23433@lochnagarn>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
Subject: Re: TeX CD
References: <9605080949.AA00400@macbeth.uni-duesseldorf.de>
> ./texmf/doc/tex/astro/astrosym.doc
> ./texmf/doc/tex/astro/astrosym.tex
> ./texmf/doc/tex/astro/astrosym.dvi
> ./texmf/doc/tex/tengwar/quenya.dvi
> ./texmf/doc/tex/tengwar/sindarin.dvi
> ./texmf/doc/tex/tengwar/quenya.tex
> ./texmf/doc/tex/tengwar/sindarin.tex
>
> What are these doing here? I'd say they belong into texmf/doc/fonts/...
> In my understanding temxf/doc/tex is only for documentation about TeX
> itself, i.e. mostly Knuth's own stuff.
i shall poke at those, thanks
> ./texmf/doc/pdf/index/style/style.ddd
> temporary junk left over from PDF distillation runs? At least to me
this is an Acrobat Search index of PDF files made from all .dvi files
> ./texmf/fonts/pk/ljfour/tmp/dpi600/cmbr8.pk
> [...]
>
> Hmm, why fonts/pk/<mode>/tmp? Perhaps, something misconfigured or
> missing in fontnames/special.map?
yup, you guessed. special.map is fixed now. i'll zap these
> ./texmf/fonts/pk/ljfour/ams/extracm/dpi600/pktmp.15458
>
> This looks like something went wrong during a MakeTeXPK run once.
ahem
> /texmf/fonts/tfm/tmp/cirbf.tfm
as above. will zap
> For which Emacs have these .elc files been byte-compiled? If you're
> unlucky, files compiled with a recent GNU Emacs might be completely
they were emacs 19.30. but ..
> Since this is a very situation, just providing the raw .el files
> would be safer, i.e. more portable, albeit a little slower to use.
> Another alternative might be using subdirectories emacs/<system>
> just as we have bin/<system>.
i just did that in a hurry, i dont propose to aadvertise it at all.
we can do it `right' some other day
> something. However, there must be always be room for improvements
> in the second edition ;-) According to Murphy's law, you'll probably
> discover the first bug as soon as you unpack the first copy of the
> final product. Never mind, that's life.
which is why i am only asking for 500 copies to be made....
sebastian
================================================================================
From owner-twg-tds@shsu.edu Mon, 13 May 1996 07:37:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 May 1996 11:33:44 +0100
Message-ID: <199605131033.LAA01436@lochnagarn>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-tds@shsu.edu
Subject: TeX Live frozen
Last night I finished the TeX Live CD. I'll put updated FILES files on
CTAN in a moment.
Any mistakes in the TDS part of the CD, which goes on sale in 2 weeks
(all being well with manufacturing), are mine :-}
sebastian
================================================================================
From owner-twg-tds@shsu.edu Thu, 30 May 1996 01:50:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 30 May 1996 07:48:55 +0100
Message-ID: <199605300648.HAA21409@lochnagarn>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: tetex@informatik.uni-hannover.de, twg-tds@shsu.edu
Subject: teTeX TeX Live CD launched
References: <9605291536.AA02510@wega.informatik.uni-hannover.de>
I am very glad to announce the launch in Paris yesterday of TeX Live, a new
CD published by the TeX Users Group, the UK TeX Users Group and
GUTenberg (French TeX Users), with help from NTG (Dutch TeX Users) and
many individuals from other groups.
TeX Live's 649 megabytes contains:
- a ready to run Unix TeX setup, Thomas Esser's teTeX (based on Karl
Berry's Web2c). It has binaries for:
Linux on Intel and m68k platforms;
Irix 5.2, 5.3 on MIPS (SGI Indy/Indigo)
SunOS 4.1.3 on Sun
Solaris 2.3, 2.4, 2.5 on SPARC
HPUX 9.01, 10.01 for HP workstations
Digital Unix (OSF/1) 2.0 and 3.2 for DEC Alpha machines
FreeBSD and NetBSD on Intel platforms
Ultrix 4.3, for DEC Decstation machines
AIX 3.2, 4.1.1, for IBM RS6000 machines
NeXTStep on Intel platforms
- a large support tree of macros, fonts and documentation
arranged according to the TeX Directory Structure layout
- the GUTenberg Mac, DOS and Windows distributions (archived)
You can use the TeX system by running directly from the CD, installing
on your hard disk, or by adding packages to your existing system.
This is not a dump of CTAN full of compressed archives. This is a
*working* system. To make it useable under Unix, it uses the Rock
Ridge extensions to the ISO9660 file system. Ordinary systems can
still read it, but will not see the long file names or symbolic links.
If you are on any flavour of Unix, BUY this CD! There is no
complicated compilation or moving of installed files around, it will
just *WORK*.
More details, and ordering information, can be found at
http://www.tug.org/texlive.html. If you dont have WWW access, mail me
or tug@tug.org for details. Cost is around $20 for members of any TeX
users group, or $40 for others (the prices vary, depending on
postage). All profits from sales go back to fund new versions of the
CD, and to TeX-related development projects.
Sebastian Rahtz
Secretary, TeX Users Group
================================================================================
From owner-twg-tds@shsu.edu Thu, 30 May 1996 15:34:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 30 May 1996 13:52:19 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199605301752.AA06351@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
CC: rocky@panix.com
Subject: plethora of filetypes
I don't know how much effort we should expend on making a tds 1.0
document, but anyway, here's a filetype glossary courtesy of Rocky
Bernstein that we could maybe adapt. I wanted to get it into the light
of day before I forgot, anyway.
K
\newcommand{\ttlistlabel}[1]{\mbox{\FTIND{#1}}\hfil}
\newenvironment{ttlist}[1]{%
\begin{list}{}
{
\let\makelabel\ttlistlabel
\settowidth{\labelwidth}{#1}
\setlength{\leftmargin}{1.1\labelwidth}%
% We're going to use \underline a lot in this environment, so we
% define a short abbreviation for it: \. This is already
% defined in LaTeX as an overdot accent, but we're not going to need
% that inside this environment. Because this definition is done
% inside an environment the definition is local to this list
% environment only. Thus \. outside does act like an accent, should
% we need them elsewhere.
% Also note that `\.abc' puts the underline under the `a' and
% not `abc', because parameter of \. is the next single token which
% is `a'. We make use of this fact to make things neater.
% Occasionally we need to make use of the \vphantom trick to
% get underbars to line up correctly across letters. This is
% described in Appendix A of the TeX book, the answer to 18.26.
\def\.{\underline}
}
}{%
\end{list}}
%\IndexMarkStop
\begin{ttlist}{{\tt list38pp}}
\item[afm]
Input by {\tt afm2tfm} to be convert to a {\TeX} font
metric (\tfm); output by the Adobe Type 1 Font Manager or
whatever program was used to create the Adobe font.
An \.{A}dobe \.{f}ont \.{m}etric.
\item[aux]
Input and output by {\LaTeX}.
An ``\.{aux}iliary'' text file for {\LaTeX}'s for cross
references. The \LTEXCMDINDE{cite}, \LTEXCMDINDE{ref}, and
\LTEXCMDINDE{pageref} commands refer to entries defined in this file.
these. Sectioning commands like \LTEXCMDINDE{chapter},
\LTEXCMDINDE{section}, or \LTEXCMDINDE{label},
write to this file. {\BibTeX} also inputs
this file to extract the entries written by the
\LTEXCMDINDE{cite}, \LTEXCMDINDE{nocite}, and
\LTEXCMDIND{bibliographystyle} {\tt \BS bib\-lio\-graphy\-style}
commands.
For more information, see Section~C.10.1 of the {\lrm}.
\item[bbl]
Output by {\BibTeX} and input by some flavor of
{\LaTeX} or {\eplain}. A text file containing a
{\BibTeX}-formated \.bi\.b\-li\-og\-ra\-phy
\.list of citations. This is derived from the
information in the {\tt aux} file. It is input via
the {\LaTeX}/{\eplain} \LTEXCMDINDE{bibliography}
command. For more information, see section C.10.1 of the \lrm.
\item[bib]
Input by {\BibTeX}; written by authors. A text file containing
a \.{bib}\-li\-og\-ra\-phic database of reference
materials such as manuals, books, articles, proceedings.
\item[blg]
Output by {\BibTeX} and read by humans when
{\BibTeX} fails. {\BibTeX}'s
\.{\vphantom{g}b}ibliograpic \.{\vphantom{g}l}o\.{g} file. See
also the entries for ``{\tt log}'' and ``{\tt ilg}.''
\item[bst]
Input by {\BibTeX}; read and written by bibliographic
style-designers. A \.bibliographic \.{st}yle format
dictating to {\BibTeX} how to format the entries in the
{\tt bib} file. See Section \refon{sec:bst} for a
list of bibliographic styles.
\item[cp]
Output by {\TeX} in its {\texinfo} flavor and input by {\texindex}. This text file
contains the entries of a {\texinfo} \.{\vphantom{p}c}once\.pt index.
See Section 15.4 of the {\texinfo} reference manual \cite{man:texinfo}.
\item[cps]
Input by {\TeX} in its {\texinfo} flavor and output by {\texindex}. This text
file contains the index entries sorted and prepared
for {\TeX} input. The output of a {\texindex} file
has an `s' appended to the name of the input file.
\item[doc]
Input by {\tt docstrip}; read and written by
{\LaTeX} style designers (and other users when the
need arises). If the filetype is renamed to
{\tt sty}, it could also be input by {\LaTeX},
albeit more slowly than if the comments were removed
by {\tt docstrip}. This text file is
commented, \.{doc}umented or
``readable'' {\LaTeX} document style or document-style option.
\item[dvi]
Input by {\dvi} conversion programs (e.g. {\dvips}) or
{\dvi}-to-{\dvi} converters (like {\dvicopy}),
{\dvi} previewers (like {\xdvi}), and
miscellaneous, utility routines (like
\CMDINDE{dvitype}). It is usually first output by
{\TeX}, but other packages can produce this too;
notable cases include \CMDINDE{gftodvi} and \CMDINDE{grodvi},
the latter is part of the \INDE{Free Software Foundation}'s
\CMDINDE{groff} package. A {\dvi} file
contains \.de\.vice
\.independent page-description commands. In
this respect it is similar to a {\tt ps} file containing
{\Ps} commands, or a {\tt list3820} containing AFPDS commands.
The output is in a form that is
independent of any particular output device, even
more so that a {\Ps} file.
\item[fn]
Text file containining index entries of a {\texinfo}
function index. See {\tt cp}.
\item[fns]
Text file containining function index entries of a {\texinfo} file
sorted and ready for inclusion into the index. See {\tt cp}.
\item[font3812]
Input by the 3812-compatible (PMP) printers.
Output by {\mf} conversion programs on VM/CMS.
Contains the rasters of a font for these printers.
\item[font3820]
Input by the 3820-compatible or AFPDS printers.
Written by {\mf} conversion programs on VM/CMS.
Contains the rasters of a font for these printers.
\item[gf]
Output by {\mf}; input by some of the {\dvi}-previewers (like
\CMDINDE{xdvi}, some of the {\dvi}-converters (like
{\dvips}) when a {\tt pk} font file is not available),
and utility programs (like \CMDINDE{gftopk}).
Contains a ``{\.{g}eneric \.{\vphantom{g}f}ont.''
See Appendix~G of {\sl The \mf book} \cite{book:mfbook}}.
\item[glo]
Input and output by {\LaTeX}.
A text file containing ``\.{glo}ssary'' commands.
The \LTEXCMDIND{glossary}{\tt \BS gloss\-ary} commands add
\LTEXCMDINDE{glossaryentry} lines to this file and
the \LTEXCMDIND{makeglossary}{\tt \BS make\-glossary} command causes this
file to be read in.
For more information, see Section~C.10.1 of the \lrm.
\item[idx]
Output by {\LaTeX} and input by {\MakeIndex}. A text file containing
\.{i}n\.{d}e\.{x}ing
commands. The \LTEXCMDINDE{index} command causes entries
to this file to be output.
\item[ilg] Output by {\MakeIndex} and read by authors when
{\MakeIndex} fails. {\MakeIndex}'s
\.{\vphantom{g}i}ndex \.{\vphantom{g}l}o\.{g} file.
See Section 3 of The
{\MakeIndex} manual \cite{man:MakeIndex}.
\item[ind] Output by {\MakeIndex} and input by {\LaTeX}.
A text file containing the sorted and processed
entries \.{ind}ex entries. See Section 3 of The
{\MakeIndex} manual \cite{man:MakeIndex}.
\item[ky] Output by {\texinfo} and input by {\texindex}.
A text file containining index entries of a {\texinfo}
\.{\vphantom{y}k}e\.y index. See {\tt cp}.
\item[kys] Output by {\texindex} and input by {\texinfo}.
A text file containing
\.{\vphantom{y}k}e\.y index entries which have
been \.{\vphantom{y}s}orted and are
and ready for inclusion into the
index by {\texinfo}. See {\tt cp}.
\item[latex] A {\LaTeX} source file.
\item[ltx] A {\LaTeX} source file. The three-letter file
extension facilitates portability between DOS and
OS/2 filesystems (that don't use the newer HPFS).
\item[mf] A {\mf} source file. Read by {\mf} and
{\mf}-converters.
\item[lab] List of label references for use by the {\tt lablst} programs.
\item[list3820]
Written by {\dvilist} and read by one of the print
commands such as {\tt out} or {\tt prt}.
A file which is ready to be sent to a printer
understanding this kind of AFPDS format.
The filename inventors who created this
name (as well as {\tt font3820}, and {\tt font3812})
did not have much forethought. Even though these name
have vestiges of specific IBM printers, these file formats are for a
{\em generic\/} class of printers. To make things worse, some of
the older IBM 3820 printers do {\em not\/} understand the full AFPDS
(or {\tt LIST3820} command language.
\item[lof]
Input and output by {\LaTeX}. A text file containing
a ``\.list \.of \.figures.''
For more information, see Section~C.10.1 of the \lrm.
\item[log]
Output by {\TeX} and read by humans\footnote{perhaps
first pre-processed in a text-editor macro as in the case of {\tt
auc-tex}'s {\tt TeX-next-error} macro} when something goes wrong.
On VM/CMS the filetype {\tt texlog} is used instead.
A text file where error messages and
warnings from the {\TeX} run are \.{log}ged.
\item[lot]
Input and output by {\LaTeX}. A text file containing
a ``\.{l}ist \.{o}f \.{t}ables.''
For more information, see Section~C.10.1 of the \lrm.
\item[pg]
Text file containining index entries of a {\texinfo}
\.{\vphantom{g}p}ro\.{\vphantom{p}g}ram index. See {\tt cp}.
\item[pgs]
Text file containining program index entries of a {\texinfo} file
sorted and ready for inclusion into the index. See {\tt cp}.
\item[pk] Input by {\dvi}-conversion programs such as {\dvips}.
Output by {\tt gftopk} and some graphics programs.
A {\mf}-created font in a \.pac\.{\vphantom{p}k}ed format
invented by \NAMEINDE{Tomas}{Rokicki}. For a complete
description of this format, see~\cite{tug:pk}.
\item[pl] Output by \CMDINDE{tftopl} and input by \CMDINDE{pltotf}
and read by font hackers.
A human-readible format of a {\tfm} file
(\.property \.{\vphantom{p}l}ist).
It may be edited to create or modify {\tfm} files.
\item[pfb] Input but {\Ps} devices. Output by the Adobe Type Manager.
{\Ps} Type 1 font program.
\item[pxl] An obsolete compressed form of {\tt pk}. See the entry
{\tt pk} entry. For a complete description of this format,
see~\cite{tug:pxl}.
\item[sty] Input by {\LaTeX}; output by \CMDINDE{docstrip}, {\LaTeX}
style designers, or style-option designers. (Also read by the
style designers and others on occasion when
no {\tt doc} version is around.)
A document or document \.{sty}le
option which dictates to {\LaTeX} how to do the layout
of the document.
\item[tex] Input by {\TeX}; output by {\tt weave}, something-to-{\TeX}
converters, (like \CMDINDE{tr2tex}) and authors.
A {\TeX} text file of some sort.
It is frequently used in places that
{\tt latex}, {\tt slitex}, {\tt sty}, or {\tt doc},
filetypes might be more appropriate. That is either, a {\LaTeX},
{\FoilTeX}, {\AmSLaTeX}, ... source file that is to be
fed into one of the flavors of {\TeX}.
The main reason this filetype seems to be in widespread
misuse (for example this file has extension {\tt tex}), is
because when {\TeX} asks for input, the \verb|tex| extension is
automatically appended when none is given. Furthermore,
if another extension is given {\LaTeX} may add its
extension in addition rather than instead of yours when
writing its files. On the DOS and non-HPSF OS/2 files
systems (these only allow 3-character file extensions),
the extension is truncated at 3 characters which can
be disasterous! In particular, your file my be overwritten by
{\LaTeX} in writing any one of its auxilliary files.
However we recommend that in cases where it is possible to
be more precise about the type of file used, you do so.
Also it is helpful to clearly mark at the top of
the file what format is used and how to process the file.
\item[texlog] VM/CMS only. See {\tt log}.
\item[texi] A {\tt \.{texi}nfo} source file.
\item[tfm] \FIND{tfm}{\tfm} Input by {\TeX}, {\em any}
{\dvi}-processor; output by {\mf},
and font-con\-version utilities like and \CMDINDE{pltotf} or
\CMDINDE{afm2tfm}. A ``
{\.T\kern -.1667em\lower .5ex\hbox {E}\kern -.125emX}
\.Font \.Metric'' file containing
information about the font such as its bounding box,
character encoding, or how pairs of glyphs kern and form ligatures.
\item[toc] Input and output by {\LaTeX}.
A text file containing a \.table \.of \.contents.
For more information, see Section~C.10.1 of the \lrm.
\item[vf] Input by the newer {\dvi} converters such as {\dvips} and
some utility programs like \CMDINDE{vftovp};
output by \CMDINDE{vptovf}. A ``\.virtual \.font'' metric
file. For a complete description, see~\cite{tug:vf}.
\item[vp] Output by \CMDINDE{vftovp} and input by \CMDINDE{vptovf}.
A human-readible format of a \.{\vphantom{p}v}irtual-font
\.property list. For a complete description, see~\cite{tug:vf}.
It may be edited to create or modify virtual fonts.
\item[vr] Text file containining index entries of a {\texinfo}
\.va\.riable index. See {\tt cp}.
\item[vrs] Text file containining variable index entries of a {\texinfo} file
sorted and ready for inclusion into the index. See {\tt cp}.
\item[web] A ``literate'' source file of many of the {\TeX} system
programs.
\end{ttlist}
================================================================================
From owner-twg-tds@shsu.edu Thu, 30 May 1996 17:12:32 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Thu, 30 May 1996 15:11:13 -0700 (PDT)
Message-ID: <199605302211.PAA00491@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: plethora of filetypes
CC: rocky@panix.com
> I don't know how much effort we should expend on making a tds 1.0
> document, but anyway, here's a filetype glossary courtesy of Rocky
> Bernstein that we could maybe adapt. I wanted to get it into the light
> of day before I forgot, anyway.
How about adding .fli files (font libraries for emtex; contain numerous
mf-created font (raster) files).
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
From owner-twg-tds@shsu.edu Thu, 30 May 1996 21:34:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 30 May 1996 22:33:30 -0400 (EDT)
From: "R. Bernstein" <rocky@panix.com>
Message-ID: <199605310233.WAA28024@panix2.panix.com>
To: vojta@math.berkeley.edu (Paul Vojta)
CC: TWG-TDS@SHSU.edu
Subject: Re: plethora of filetypes
References: <199605302211.PAA00491@tashkent.berkeley.edu>
Reply-To: TWG-TDS@SHSU.edu
Paul Vojta writes:
> > I don't know how much effort we should expend on making a tds 1.0
> > document, but anyway, here's a filetype glossary courtesy of Rocky
> > Bernstein that we could maybe adapt. I wanted to get it into the light
> > of day before I forgot, anyway.
>
> How about adding .fli files (font libraries for emtex; contain numerous
> mf-created font (raster) files).
Probably much more useful and more relevant than the descriptions of
list3820 and list38pp files.
To justify those arcane filetypes: that excerpt was from a "local" TeX
document of the kind Leslie Lamport suggested local maintainers
provide. At the time I, was working at IBM where there were such
arcane printers. .fli files were available back in '94 (or '92 when
this we first started), I just forgot to mention them. Also emtex on
OS/2 was not used at IBM Watson in favor of an emx! port of the Unix
TeX distribution---that way hyphenation tables, and other tables were
the same size across all architectures.
================================================================================
From owner-twg-tds@shsu.edu Fri, 31 May 1996 03:37:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 31 May 1996 10:32:29 +0200
Message-ID: <9605310832.AA14016@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: rocky@panix.com
Subject: Re: plethora of filetypes
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Karl wrote:
> I don't know how much effort we should expend on making a tds 1.0
> document, but anyway, here's a filetype glossary courtesy of Rocky
> Bernstein that we could maybe adapt. I wanted to get it into the light
> of day before I forgot, anyway.
Nice idea. I'll have a closer look at it when I have more time.
Quite a long time ago, I had the plan of writing two HTML pages
explaining a) the purpose of all the TeX-related programs and
b) the role of all the TeX-related file types with many hyperlinks
in between those two documents. Unfortunately, I've never found
the time to pursue this idea. Perhaps, this might be the basis
for a new start of such a project.
Cheers, Ulrik.
From owner-twg-tds@shsu.edu Tue, 04 Jun 1996 04:40:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 4 Jun 1996 11:38:11 +0200
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9606040938.AA13492@wega.informatik.uni-hannover.de>
To: taupin@lps.u-psud.fr
CC: TWG-TDS@SHSU.edu
Subject: Re: Another trick
I am about to answer some questions from Danuiel Taupin
<taupin@lps.u-psud.fr>. Since some TDS issues are touched, I Cc'ed to
the list. Maybe other list members want to comment on that, too.
> The question is simple: does the "texhash" routine look at "texmf.cnf",
> or does it simply scan de subdirs of teTeX/texmf ?
It does
ls -LAR
in $TEXMF.
Scanning texmf.cnf does not make any sense, since the current Kpathsea
implementation would ignore any files in ls-R that are outside $TEXMF.
> Suppose I get updates of latex styles, music styles, various *.tex common
> things (e.g. docstrip.tex or something.ins), then how can I know where they
> have to be put according to the TDS. In practice, is there a script that
> puts the given files into the right directory in an automatic way?
No, there is no mechanism to put files automatically into a TDS tree.
We all hope for such a feature in the future, but we still have no
general concept about how it could be done.
If you aim TDS compliance for the styles you install, all you can do is
to read the TDS paper. If the instructions are unclear, you should ask
the TWG-TDS for clarification.
Thomas
================================================================================
From owner-twg-tds@shsu.edu Tue, 04 Jun 1996 05:20:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 4 Jun 1996 12:18:37 +0200
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9606041018.AA13648@wega.informatik.uni-hannover.de>
To: taupin@lps.u-psud.fr
CC: TWG-TDS@SHSU.edu
Subject: Re: Another trick
> > It does
> > ls -LAR
> > in $TEXMF.
> >
> This means that, if I want teTeX to find some specific styles
> (e.g. musixtex.sty or french.sty) which I do not want to duplicate (safety
> reasons), then I should not modify texmf.cnf but rather build a symboly link
> to that other directory, inside the $TEXMF tree. Obvious but more obvious
> when sais explicitely.
Wrong. You can change texmf.cnf and put your file into directories
outside $TEXMF. But you may not prefix the search component with !! and
you cannot make use of the ls-R optimization. Besides these restrictions,
it does work.
> simple way would consist in taking the standard ls-R of the TDS
> distrib, and at least make a shell moving the known files in their std
> TDS directory. Then, the user would choose what to do with the remainder
> (possibly => misc)
There is no such "standard ls-R". Anyway: it was no good idea to remove
TWG-TDS@SHSU.edu from the Cc: field. There are people who are interested
these ideas...
> Yes, but nothing forbids the teTeX doc to provide additional information
> about how to comply with TDS.
Sure. Any volunteers?
Thomas
================================================================================
From owner-twg-tds@shsu.edu Tue, 11 Jun 1996 04:27:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 11 Jun 1996 10:59:52 +0200
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9606110859.AA26902@wega.informatik.uni-hannover.de>
To: taupin@lps.u-psud.fr
CC: gut@ens.fr, tetex@informatik.uni-hannover.de, twg-tds@shsu.edu
Subject: Re: [TETEX 643] Another problem with tetex/dvips
> Awful: I have hunderds of pk fonts already made (e.g. the DC1.3 of sizes
> 0500 0600 0700 0800 0900 1000 1095 1200 1440 1728 20pts 25pts 30pts 36pts
> 43pts 51.60pts plus some others not at 300pk but 360pk 418pk, plus the sames
> in the 600 dpi resolution: I need to be able to put them inside the TDS
> structure.
You told me, you have read the documentation. Cannot be:
- TETEXDOC: 3.6 point 3.
\item Import font files from a different \TeX -Installation. This can
be done through the program {\tt fontimport}. We even provide a
...
- fontimport(1):
...
fontimport imports font files into the teTeX directory
tree and copies them to their appropriate places. With
given -d flag the files are deleted in the other place
afterwards.
...
- teTeX FAQ:
12) Is there an easy way to copy .tfm or .pk fonts from a temporal directory
to their standard directory below $TEXMF?
Yes. Use the fontimport utility...
So, please stop to ask questions that are well explained in the
documentation!
The solution is so easy. Run
fontimport .
in the directory containing the fonts to import.
fontimport is a simple shell-script that allows to "import" tfm and pk
files. It can copy or move the files to their proper TDS location. It
uses the fontname maps and inspects pk files to find out their mode
if possible.
> > Why did I never see any posting of you in the TDS list? You seem to
> > have major problems in accepting that structure.
>
> Because I did not know there was a list. And because I (and many other
You asked me about TDS and I directed you to the TDS manual. The *is* the
adress of the mailinglist. On the first page of that paper:
Please send questions or suggestions by email to
\literal{twg-tds@shsu.edu} or by postal mail to Karl Berry / 135 Center
Hill Road / Plymouth, MA\ \ 02360 / USA\@. We welcome all comments.
> French people consider, after experiment, that TDS is NOT a good thing for
> practical use: my feeling is that TDS is good for CTAN postings, so that you
Oh, you are speaking for all French people... It seems to me, that you
should read some docs, before you can have an opinion about TDS.
> can find out what is "latex"-related, what is "plain"-related, what is
> DC-related, etc. But of local implementation and local updated, having a
> straight TFM directory, s atraight PK directory and a straight TEXINPUT
> directory is much better.
You can easily drop-in new stuff, but you never find out which files
belong logically together.
> Of course this seems in contradiction with your philosophy: you provide
> teTeX as a READY-TO-USE thing, a black box NEVER to be changed as Word n.p!
> But practical users need everyday to add new fonts (greek, cambodgian,
> music, pictograpms of any kind) and they want to add new styles (french.sty,
> revtex.sty, jphys.sty, anything.sty...). This means that I (and many others)
> want to have an OPEN tool box, not a CLOSED black box! This is the
> explanation of my requests and disagreements.
No, just because I want to make adding/removing things easier, I decided
to go the TDS way.
Thomas
================================================================================
From owner-twg-tds@shsu.edu Tue, 11 Jun 1996 05:22:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 11 Jun 1996 11:08:29 +0100
Message-ID: <199606111008.LAA24801@lochnagarn>
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@shsu.edu
CC: taupin@lps.u-psud.fr, gut@ens.fr, tetex@informatik.uni-hannover.de, twg-tds@shsu.edu
Subject: Re: [TETEX 643] Another problem with tetex/dvips
References: <9606110859.AA26902@wega.informatik.uni-hannover.de>
> > French people consider, after experiment, that TDS is NOT a good thing for
> > practical use: my feeling is that TDS is good for CTAN postings, so that you
good gracious, this is almost worthy of a British mad cow politician!
> > But practical users need everyday to add new fonts (greek, cambodgian,
> > music, pictograpms of any kind) and they want to add new styles (french.st > > revtex.sty, jphys.sty, anything.sty...). This means that I (and many other
> > want to have an OPEN tool box, not a CLOSED black box! This is
i simply cannot understand this. the whole rationale behind
the TDS structure, and teTeX which adopted it, was precisely to make it
easy to maintain a working, dynamic system. what we had before, the
monolithic directories, was a black box to me.
i have been maintaining TeX since about 1986 on various systems, and i
can honestly say that the TDS (with Karl Berry's kpathsea which makes
it efficient) is by far the most important development to make the
process easier for me. i wouldnt go back to the (old) emTeX morass if
you paid me
sebastian
================================================================================
From owner-twg-tds@shsu.edu Tue, 11 Jun 1996 07:03:02 CDT
Sender: owner-twg-tds@SHSU.edu
From: Bernard GAULLE <gaulle@idris.fr>
Reply-To: TWG-TDS@SHSU.edu
Date: Tue, 11 Jun 1996 13:16:08 +0200
Message-ID: <199606111116.NAA00385@murnau.idris.fr>
To: GUT Distribution List <gut@ens.fr>
CC: TWG-TDS@shsu.edu, gut@ens.fr, taupin@lps.u-psud.fr, tetex@informatik.uni-hannover.de, twg-tds@shsu.edu
Subject: Re: [TETEX 643] Another problem with tetex/dvips
>>>>> On Tue, 11 Jun 1996 11:08:29 +0100,
>>>>> Sebastian Rahtz <s.rahtz@elsevier.co.uk> write about "Re: [TETEX 643] Another problem with tetex/dvips":
> > French people consider, after experiment, that TDS is NOT a good thing for
> > practical use [...]
SR> i have been maintaining TeX since about 1986 on various systems, and i
SR> can honestly say that the TDS (with Karl Berry's kpathsea which makes
SR> it efficient) is by far the most important development to make the
SR> process easier for me.
AGREED! and i'm still French, as far as i know...
(Who is reporting French people opinions? Was it the general opinion
at the last GUTenberg meetting at the end of May?)
--bg
================================================================================
From owner-twg-tds@shsu.edu Tue, 11 Jun 1996 07:03:05 CDT
Sender: owner-twg-tds@SHSU.edu
From: Bernard GAULLE <gaulle@idris.fr>
Reply-To: TWG-TDS@SHSU.edu
Date: Tue, 11 Jun 1996 13:16:08 +0200
Message-ID: <199606111116.NAA00385@murnau.idris.fr>
To: GUT Distribution List <gut@ens.fr>
CC: TWG-TDS@shsu.edu, gut@ens.fr, taupin@lps.u-psud.fr, tetex@informatik.uni-hannover.de, twg-tds@shsu.edu
Subject: Re: [TETEX 643] Another problem with tetex/dvips
>>>>> On Tue, 11 Jun 1996 11:08:29 +0100,
>>>>> Sebastian Rahtz <s.rahtz@elsevier.co.uk> write about "Re: [TETEX 643] Another problem with tetex/dvips":
> > French people consider, after experiment, that TDS is NOT a good thing for
> > practical use [...]
SR> i have been maintaining TeX since about 1986 on various systems, and i
SR> can honestly say that the TDS (with Karl Berry's kpathsea which makes
SR> it efficient) is by far the most important development to make the
SR> process easier for me.
AGREED! and i'm still French, as far as i know...
(Who is reporting French people opinions? Was it the general opinion
at the last GUTenberg meetting at the end of May?)
--bg
================================================================================
From owner-twg-tds@shsu.edu Tue, 11 Jun 1996 07:12:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 11 Jun 1996 14:07:51 +0200
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9606111207.AA27501@wega.informatik.uni-hannover.de>
To: gaulle@idris.fr
CC: TWG-TDS@shsu.edu, gut@ens.fr, taupin@lps.u-psud.fr, tetex@informatik.uni-hannover.de
Subject: Re: [TETEX 654] Re: Another problem with tetex/dvips
> > > French people consider, after experiment, that TDS is NOT a good thing for
> > > practical use [...]
> SR> i have been maintaining TeX since about 1986 on various systems, and i
> SR> can honestly say that the TDS (with Karl Berry's kpathsea which makes
> SR> it efficient) is by far the most important development to make the
> SR> process easier for me.
>
> AGREED! and i'm still French, as far as i know...
:-)
> (Who is reporting French people opinions? Was it the general opinion
> at the last GUTenberg meetting at the end of May?)
As for your second question: I was at the GUTenberg meetting
as keynote speaker. Topics of my talk have been: teTeX, TeX Live CD
and *TDS*. As for the slides, see:
http://www.informatik.uni-hannover.de/~te/talks/paris-96.05.29.ps.gz
I am not aware of such a "general opinion" about TDS at all.
Thomas
================================================================================
From owner-twg-tds@shsu.edu Fri, 14 Jun 1996 18:08:32 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 14 Jun 1996 15:53:05 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199606142253.PAA02821@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@shsu.edu, taupin@lps.u-psud.fr, gut@ens.fr, tetex@informatik.uni-hannover.de, twg-tds@shsu.edu
Subject: Re: [TETEX 643] Another problem with tetex/dvips
As one who is deep into problems of Greek, Greek prosody, and other
similar fonts and tex inputs I can heartily support Sebastian's reaction.
The TDS (disclaimer, I was in on developing it too) is completely
open-ended in such matters, and provides superior guidance to a
reasonable location for any new package. I have a couple of very minor
quibbles with it, but the consistency it provides has made it very
much worth while to yield on these and to follow the TDS line as closely as
possible.
--
%=======================================================================%
| 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, 14 Jun 1996 18:08:35 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 14 Jun 1996 15:53:05 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199606142253.PAA02821@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@shsu.edu, taupin@lps.u-psud.fr, gut@ens.fr, tetex@informatik.uni-hannover.de, twg-tds@shsu.edu
Subject: Re: [TETEX 643] Another problem with tetex/dvips
As one who is deep into problems of Greek, Greek prosody, and other
similar fonts and tex inputs I can heartily support Sebastian's reaction.
The TDS (disclaimer, I was in on developing it too) is completely
open-ended in such matters, and provides superior guidance to a
reasonable location for any new package. I have a couple of very minor
quibbles with it, but the consistency it provides has made it very
much worth while to yield on these and to follow the TDS line as closely as
possible.
--
%=======================================================================%
| 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, 03 Jul 1996 02:33:14 CST
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 3 Jul 1996 09:34:04 +0200
Message-ID: <199607030734.JAA11576@aragorn.ci.tuwien.ac.at>
From: Kurt Hornik <Kurt.Hornik@tuwien.ac.at>
To: twg-tds@shsu.edu
Subject: TDS
Reply-To: TWG-TDS@SHSU.edu
Hi,
Is there any easy way of obtaining state-of-the-art information on the
TeX Directory Standard and Web2c 7? (I tried the TDS mailing list
archive, but could not access anything later than late October 1995.)
Thanks,
-kh
================================================================================
From owner-twg-tds@shsu.edu Wed, 03 Jul 1996 03:34:40 CST
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 3 Jul 1996 10:30:01 +0200
Message-ID: <9607030830.AA00916@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: Kurt Hornik <Kurt.Hornik@tuwien.ac.at>
Subject: Re: TDS
From: Ulrik Vieth <vieth@thphy.uni-duesseldorf.de>
Reply-To: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Kurt Hornik:
> Hi,
> Is there any easy way of obtaining state-of-the-art information on the
> TeX Directory Standard and Web2c 7? (I tried the TDS mailing list
> archive, but could not access anything later than late October 1995.)
Hi,
thanks for your interest in the work of the TWG-TDS. Concerning
state-of-the-art information, I'd like to point the following:
1.) The latest official TDS draft (version 0.999 as of November 1995)
should be available on CTAN archvies (e.g. ftp.dante.de from Austria)
in the directory tex-archive/tds/draft-standard. This is more-or-less
the final version as published in TUGboat 16#4. Nothing has changed
since then and it isn't clear if there'll ever be a final version 1.0.
2.) Concerning mailing list archives: If the official archives at SHSU.EDU
are unreliable (Did you also try FILESERV requests by E-Mail?),
I'd recommend to try some other unofficial archive sites maintained
by some of the working group members. One of these sites (maintained
by Phil Taylor at vms.rhbnc.ac.uk) is listed in the TDS draft itself.
My own private archives (not listed there) are availabe via WWW from
http://www.thphy.uni-duesseldorf.de/~vieth/subjects/tex/projects/tds-mail/
Note however, that most of the discussion since the release of
version 0.999 has been centered around administrative issues
such as converting the TDS draft to other formats (e.g. HTML)
or producing a TDS CD (see http://www.tug.org/texlive.html).
Very few real organizational issues have been discussed since then.
Hope this helps,
Ulrik Vieth.
(Just speaking for myself as a group member, not for TWG-TDS in general.)
================================================================================
From owner-twg-tds@shsu.edu Wed, 03 Jul 1996 13:13:48 CST
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 3 Jul 1996 17:03:38 +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: <960703170338.27e06735@vms.rhbnc.ac.uk>
Subject: Re: TDS
>> One of these sites (maintained
>> by Phil Taylor at vms.rhbnc.ac.uk) is listed in the TDS draft itself.
Dear Ulrik -- thank you for reminding me of this function: in reducing
the number of lists which I read manually, I have forgotten to keep
this archive up-to-date; if there is another site which is maintaining
an archive, it would be better to change the documentation to refer to
that site; if not, let me know and I will do my best to re-create the
missing archives (I do archive all messages, but had forgotten to
create the files referred to). ** Phil.
================================================================================
From owner-twg-tds@shsu.edu Wed, 03 Jul 1996 15:38:26 CST
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 3 Jul 1996 16:37:58 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199607032037.AA16903@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: TDS
Is there any easy way of obtaining state-of-the-art information on the
TeX Directory Standard and Web2c 7? (I tried the TDS mailing list
archive, but could not access anything later than late October 1995.)
What Ulrik says is correct, afaik. There is an archive on shsu.edu, and
the archive listed in the TDS standard itself. Probably the tds list &
archive, like everything else, should migrate off shsu ...
As far as web2c 7 goes, it's still in pretest. I can't predict when it
will be ready for release. Not this week.
================================================================================
From owner-twg-tds@shsu.edu Mon, 29 Jul 1996 10:48:44 CST
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 29 Jul 1996 11:48:35 -0400
Message-ID: <199607291548.AA15262@terminus.cs.umb.edu>
From: kb@terminus.cs.umb.edu
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@shsu.edu
Subject: move this list?
Any objections if I put this list (twg-tds@shsu.edu) at mail.tug.org, to
make (un)subscriptions easier (I think, can't remember if the listserv
at shsu thinks twg-tds is public) and archiving (hopefully) more
reliable?