TeX directory structures
Eberhard Mattes
mattes@azu.informatik.uni-stuttgart.d400.de
Wed, 12 Oct 94 14:27:44 +0100
NAME: Eberhard Mattes
EMAIL: mattes@azu.informatik.uni-stuttgart.de
TEX IMPLEMENTATION: emTeX
This version of TeX currently supports (delete ones which don't apply):
* a list of directories for each sort of file (for example, you can
specify fonts/tfm/adobe and fonts/tfm/monotype)
* one level of subdirectory searching (for example, you can
speficify fonts/tfm and it will find fonts/tfm/adobe/ptmr7t.tfm(
* many-level subdirectory searching (for example, you can
specify fonts/tfm and it will find fonts/tfm/adobe/times/ptmr7t.tfm)
* many-level subdirectory searching with a cache to avoid
searching the whole directory structure for every file (for
example, the ls-R file in kpathsea).
* something else (please specify!)
One-level subdirectory searching is enabled by appending a single !
to the end of the path, many-level subdirectory searching is
enabled by appending !! to the end of the path, for instance:
c:\emtex\tfm!!;d:\fonts\tfm!
The paths are expanded at program start and all directory names
(but not the file names) are kept in memory.
By this time next year, this version of TeX should (don't worry, we
won't hold you to this one!) support:
If the TUG technical working group ask us to, we will implement:
* many-level subdirectory searching with pruning
Any other comments:
HOWEVER, the syntax for pruning isn't unambigous under OS/2 and
MS-DOS: // (or \\) has a special meaning for accessing network
servers by name, therefore I prefer not to implement pruning with
that syntax. (I think Apollo Unix has something similar.)
Fortunately, // (and \\) are handled specially only at the very
beginning of a path name, for instance:
\\server\directory\file
That is, it's technically possible to specify pruning with //, but
it will confuse users.
================================================================================
Archive-Date: Thu, 13 Oct 1994 09:53:12 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qvROs-00007IC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 13 Oct 94 15:44 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Robertson's Rules of Order (or something like that)
> - Eberhard doesn't seem anxious to support it either (based upon
> Alan's posting---though maybe it was only a comment about
> syntax). Three down?
One back up again. EM was just commenting on the syntax.
But otherwise (unsurprisingly) I agree.
Alan.
================================================================================
Archive-Date: Thu, 13 Oct 1994 10:47:54 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Robertson's Rules of Order (or something like that)
Date: Thu, 13 Oct 1994 16:47:31 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:242940:941013154742"@cl.cam.ac.uk>
Alan's chart so far is interesting. at least people seem to have
understood what he was asking. on the basis so far, I'm becoming a
fonts/type convert, simply cos i want to see this TDS succeed. and i
find Christian's argument that non-pruneed directories is trivial
under VMS, but pruned requires work, quite convincing. I know JS says
he will offer a POSIX library kit, but thats just not going to cut ice
with people for one reason or another.
if i can second guess peoples views, JS thinks that fonts/type is an
abortion and not needed, but also wants to see this thing off the
ground; Pierre thinks its philosophically *BAD*; Karl thinks its
inefficient because a cache will always be needed on real
systems. Thene there are the vaguer group, lke me, who think
fonts/type is untidy.
Strikes me that fewer people will scream if we reverse the decision...
Given that fonts/type doesnt preclude caching, can Karl live with
this? otherwise, do JS and PM now have apopplexy?
sebastian
================================================================================
Archive-Date: Thu, 13 Oct 1994 11:36:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 13 Oct 1994 11:36:32 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00985E17.22FA2FA0.165@SHSU.edu>
Subject: Re: draft document
On Thu, 13 Oct 1994 08:07:25 -0400, norm@ora.com (Norman Walsh), posted:
> As I recall, it's a script that builds the ZIP files so I think that
> martian-tds.zip is equally doable (and it doesn't violate the 8.3 rule so
> dramatically (if n.3 is less evil than n.m, I dunno)).
Will have to think further about how to get the .tds-zip (needs to be an
extension to toggle into special handling, but that's a trifle) to get the
proper hierarchical scheme (may require some linking, which might be
easier, but again, that's a mechanical trifle at the moment). As far as
the 8.3 (or whatever), that's one of the absolute beauties of the ZIP
utility which I don't want to get into changing. It uses whatever the
"proper" filename syntax is upon unpacking based on the operating system it
is UNZIPping on even though it used whatever restrictions were required on
the system doing the ZIPping. If it's an 8.3 system, the names magically
become 8.3; if it's a one-dot-only system, the names magically come out
with one dot; if it's a mono-case system,the naes magically....... In
other words, that is already taken care of for us, more of less.
--George
================================================================================
Archive-Date: Fri, 14 Oct 1994 06:39:13 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141139.MAA15583@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Alternate suggestion for LaTeX directory trees.
To: TWG-TDS@SHSU.edu
Date: Fri, 14 Oct 1994 12:39:15 +0100 (MEZ)
Content-Type: text
Joerg wrote:
>
> I don't see a real problem in the test files coming with the Computer
> Modern fonts.
Of course.
> So they are placed under tex_root:[mf.cm.test].
Actually, tex_root:[mf.public.cm.test]
I.e., fonts/<source>/<type>
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 14 Oct 1994 06:41:52 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141141.MAA16880@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Alternate suggestion for LaTeX directory trees.
To: TWG-TDS@SHSU.edu
Date: Fri, 14 Oct 1994 12:41:52 +0100 (MEZ)
Content-Type: text
Alan wrote:
>
> Although if Joachim's response is anything to go by I may as well not
> have bothered, since it looks like he's all set to ignore whatever the
> implementors have to say...
In contrary. I will reside with the implementors and with you and
will agree to fonts/<type>/ in the future. More on this in later mail,
when I've looked at my backlog completely.
Of course, I will not use this in my own installation. After all, I'm
using Unix.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 14 Oct 1994 06:48:05 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141148.MAA19714@spice.iti.informatik.th-darmstadt.de>
Subject: Re: draft document
To: TWG-TDS@SHSU.edu
Date: Fri, 14 Oct 1994 12:48:05 +0100 (MEZ)
Content-Type: text
David wrote:
>
> > No, if you look at the typical LaTeX2e distribution, it does not have
> > the file that are installed. They are created during installation.
>
> True, and this is actually a general problem, where to put the dtx
> files. under doc seems the obvious place
Hmm, for me the `obvious place' is the source tree. (Which we don't
say anything upon by intent.) doc/ was explicitely marked as `for
_user_ documentation'. I don't consider program source as user
documentation. Currently, my doc/latex/ holds
-rw-rw-r-- 1 tex software 55237 Oct 11 00:38 clsguide.tex
-rw-rw-r-- 1 tex software 51600 Oct 11 00:38 fntguide.tex
-rw-rw-r-- 1 tex software 5472 Oct 11 00:38 ltnews01.tex
-rw-rw-r-- 1 tex software 7247 Oct 11 00:38 sample2e.tex
-rw-rw-r-- 1 tex software 1700 Oct 11 00:38 small2e.tex
-rw-rw-r-- 1 tex software 48703 Oct 11 00:38 usrguide.tex
Perhaps one should add DVI or PS versions for some of these
documents, too. There might be more in the future, like lkurz.tex,
etc. I'd have to sort out the CTAN stuff for that.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 14 Oct 1994 06:53:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 94 12:52:12 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410141152.AA01530@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Alternate suggestion for LaTeX directory trees.
> Actually, tex_root:[mf.public.cm.test]
> I.e., fonts/<source>/<type>
> Joachim
Er, no type here is `mf' isn't it? The VMS path looks like
fonts/mf/public/cm/tex
fonts/type/source/typeface/test
??
================================================================================
Archive-Date: Fri, 14 Oct 1994 06:59:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 94 12:59:58 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410141159.AA01537@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
>
> David wrote:
> >
> > > No, if you look at the typical LaTeX2e distribution, it does not have
> > > the file that are installed. They are created during installation.
> >
> > True, and this is actually a general problem, where to put the dtx
> > files. under doc seems the obvious place
>
> Hmm, for me the `obvious place' is the source tree. (Which we don't
> say anything upon by intent.) doc/ was explicitely marked as `for
> _user_ documentation'. I don't consider program source as user
> documentation. Currently, my doc/latex/ holds
>
> -rw-rw-r-- 1 tex software 55237 Oct 11 00:38 clsguide.tex
> -rw-rw-r-- 1 tex software 51600 Oct 11 00:38 fntguide.tex
> -rw-rw-r-- 1 tex software 5472 Oct 11 00:38 ltnews01.tex
> -rw-rw-r-- 1 tex software 7247 Oct 11 00:38 sample2e.tex
> -rw-rw-r-- 1 tex software 1700 Oct 11 00:38 small2e.tex
> -rw-rw-r-- 1 tex software 48703 Oct 11 00:38 usrguide.tex
>
> Perhaps one should add DVI or PS versions for some of these
> documents, too. There might be more in the future, like lkurz.tex,
> etc. I'd have to sort out the CTAN stuff for that.
>
> Joachim
This is in fact a problem, I have the site wide setup at Manchester
something similar to you have. Although I was planning to move some
more dtx files into the doc area once I get time. While it is true
that lterror.dtx might be viewed a source that you never want to
bother the users with, something like array.dtx or longtable.dtx (or
at least the dvi files produced from them with \OnlyDescription set)
*are* user documentation.
I do keep dvi and (html if the translation looks reasonable)
forms in (the equivalent of) the texmf/doc area.
David
================================================================================
Archive-Date: Fri, 14 Oct 1994 07:11:00 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141211.NAA14533@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Alternate suggestion for LaTeX directory trees.
To: TWG-TDS@SHSU.edu
Date: Fri, 14 Oct 1994 13:11:02 +0100 (MEZ)
Content-Type: text
You wrote:
>
>
> > Actually, tex_root:[mf.public.cm.test]
> > I.e., fonts/<source>/<type>
> > Joachim
>
> Er, no type here is `mf' isn't it?
Yeah, you're right. I misinterpretet that.
> fonts/mf/public/cm/tex
>
> fonts/type/source/typeface/test
>
> ??
Not nice. That would mean we keep in fonts/type/source/typeface both
lots of files and one directory. I have to say I don't like that.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 14 Oct 1994 07:13:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 1994 08:09:57 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199410141209.IAA26179@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Alternate suggestion for LaTeX directory trees.
References: <199410141211.NAA14533@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 14 October 1994 at 13:11:02, Joachim Schrod wrote:
> > fonts/mf/public/cm/tex
> >
> > fonts/type/source/typeface/test
> >
> > ??
>
> Not nice. That would mean we keep in fonts/type/source/typeface both
> lots of files and one directory. I have to say I don't like that.
I suppose the obvious answer is
fonts/test/source/typeface
since 'test' files are just a 'type' of file. Not in exactly the same
sense, unfortunately, but...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | In science, "fact" can only mean "confirmed to
Production Tools Specialist | such a degree that it would be perverse to
O'Reilly & Associates, Inc. | withhold provisional assent." I suppose that
90 Sherman Street | apples might start to rise tomorrow, but the
Cambridge, MA 02140 | possibility does not merit equal time in physics
(617) 354-5800/661-1116 FAX | classrooms. -- Stephen J. Gould
================================================================================
Archive-Date: Fri, 14 Oct 1994 07:13:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141213.NAA16845@spice.iti.informatik.th-darmstadt.de>
Subject: Re: draft document
To: TWG-TDS@SHSU.edu
Date: Fri, 14 Oct 1994 13:13:29 +0100 (MEZ)
Content-Type: text
David wrote:
>
> Although I was planning to move some
> more dtx files into the doc area once I get time. While it is true
> that lterror.dtx might be viewed a source that you never want to
> bother the users with, something like array.dtx or longtable.dtx (or
> at least the dvi files produced from them with \OnlyDescription set)
> *are* user documentation.
Actually, that's what I do. I use a perl script to add
\OnlyDescription after \begin{document} of the *.dtx files, LaTeX them
and store them in doc/latex-styles/.
Now, that directory name is another problem I'd like to address in
another mail that is a direct critic on the current draft.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 14 Oct 1994 08:17:43 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141317.OAA19738@spice.iti.informatik.th-darmstadt.de>
Subject: Report on the DANTE Meeting
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Fri, 14 Oct 1994 14:17:42 +0100 (MEZ)
Content-Type: text
At the DANTE meeting I had the opportunity to speak with some
developers of TeX software; in particular with Peter Breitenlohner
(PublicTeX) and Lutz Birkhahn (Atari TeX). A few driver developers
were there as well.
There was a general overall-agreement with the TDS proposal. I
learned that the DANTE DOS distribution -- with PublicTeX -- uses a
subdirectory organization for TeX input files already. Actually,
PublicTeX supports subdirectory searching and uses doubled directory
separators to mark the places where this should happen. I.e., the
example on p.3 of the draft is actually the method used by PublicTeX.
In case it is not well known enough: PublicTeX was the first
freely distributable port of TeX to DOS, done by Klaus-Peter Thull
and now supported by Peter Breitenlohner (who has abandoned his
involvement in sbTeX). It's distributed under the GPL. I.e., it's
the *only* pure-DOS port where source is available. (With pure-DOS I
mean: it runs on any 80x86 class machines.)
Both persons were reluctant in adapting fonts/<source>, they prefered
fonts/<type>. I think it's not uncorrelated to the fact that they
use _only_ CM fonts and none else. The driver developers were not as
reluctant as long as they get a well-tested module they can plug in
their systems.
I did a straw poll (about 70 attendees, 25 responded) about the usage
of fonts. All but three use at maximum two font families. 17 people
use only CM. The rest use CM and one of standard Adobe fonts. IMO
care must be taken to interpret this data point; 25 people are too
few to make factual statements -- and we must look at the
installations of the future, not only at today. Nevertheless, one
has to take into account that these attendees are not of the
clueless-newbie type but are very engaged in TeX. So I don't think
any more that the critical mass of `font junkies' has been
accumulated. It seems to be too early for full-fledged systems,
(too) many people are still very satisfied with the things they have
today. (As one can also show by other examples.)
So I decided to withdraw my objection against fonts/<type>.
I abstain. (Not my opinion, I won't shut up... :-)
The `abstain' is for the sake of a straw poll.
I would like to see a reflexion on this topic in the TDS, 'though.
My proposal is to use similar wordings as in the package/format
discussion. From the top of my head: ``fonts/<type>/<source>/ does
reflect current usage more and is more likely to be adopted by both
the developers and the users community. But there was a strongly
voiced opinion in favor of fonts/<source>/<type>. The proponents of
that alternative are Unix users with large installations; in
particular, Karl Berry, Pierre MacKay, and Joachim Schrod. They argue
that large font sets will be a common case for future TeX
installations, due to performance reasons one will need a directory
cache for the subdirectory search implementation anyhow, and with
that cache the directory layout can be more oriented towards the need
of the installation maintainer and not towards the need of the TeX
software developer.''
I would like to have my name appended to such a statement instead of
writing about some anonymous knowledgable-experienced-or-whatever
people. While I don't expect that happen here in this TWG, I have
experienced enough gossip, spread of false information, and
behind-ones-back imputations in the past. (From suits of TeX users
groups, both TUG and local ones.) Therefore I would like to attach
my name to my opinion, I stand by it...
Sorry, that this gets so long, but I'm still not finished. :-) :-)
DANTE has agreed to obey (dare one say support? ;-) TDS in all future
TeX distributions they prepare and that are maintained or recommended
to people. (As a background: Due to political reasons -- the suits
I'm writing above -- it's not so easy to get such a statement. But
after three hours discussion it was agreed upon. Perhaps they got too
tired then. :-)
Btw, in the light of the current discussions and information, I start
to withdraw my statement on the to-be-expected non-acceptence of TDS.
(George, are that enough hyphens?)
I was asked if it is really necessary to give the root of the TDS tree
a fixed name. Peter and others prefered some kind of abstract notion
like <texmf> or $TEXMF or similar. He talked about syntactic
placeholder, not a fixed name. As a DOS person, he's reluctant to
add one directory level if one might use a complete partition for TeX
anyhow. I.e., he'd like to be able to use "t:" or similar for <texmf>
and still conform to the TDS.
That's the report from the meeting. I'll send my comments on the
current draft tonight.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 14 Oct 1994 08:39:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 94 14:37:23 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410141337.AA01613@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: cd lowercase 8+3 filenames
I said:
> > <para>
> > The most troubling limitation is monocase names because &LaTeX;
> > uses mixed case names for font descriptor files. However, this
> > problem is surmountable.
>
> Half a dozen lines inserted in texsys.cfg would remove this problem
> .....
>
> [ I havent actually got these `half dozen lines' to hand, but I
> could commission Alan Jeffrey to produce them if required:-]
I couldn't afford to commission A.J. so I have produced the following
muself:-) Norm, have you actually got one of these cd thingies hooked
on to unix box to see whether this actually works:-)
If you run the test file, it the \input{} should input the file
lowercase 8+3, and similarly the \selectfont should find the lowercase
0t1foo.fd file.
David
PS That was much more fun than thinking about where fonts should go..
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% An example that truncates all filenames to 8+3 lowercase.
%%% if they are not found with their natural name.
\makeatletter
\def\input@path{{}}
\def\LowercaseFile#1 {%
\edef\@tempa{#1}%
\expandafter\lowercase\expandafter
{\expandafter\EightPlusThree\@tempa..\\}}
\def\EightPlusThree#1.#2.#3\\{%
\edef\@filef@und{%
\TruncateEight#1%
\@empty\@empty\@empty\@empty\@empty\@empty\@empty\@empty\\%
.\TruncateThree#2\@empty\@empty\@empty\\ }}
\def\TruncateEight#1#2#3#4#5#6#7#8#9\\{#1#2#3#4#5#6#7#8}
\def\TruncateThree#1#2#3#4\\{#1#2#3}
\def\@file@name@handler#1{\LowercaseFile#1 }
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Currently the internal command \@iffileonpath
% does not call \@file@name@handler, so patch it so that it does.
\let\@@iffileonpath\@iffileonpath
\def\@iffileonpath#1{%
\@file@name@handler{#1}%
\expandafter\@@iffileonpath\expandafter{\@filef@und}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% just to show it works:
%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{filecontents}{abcdefgh.xyz}
\typeout{^^J***I love MSDOS!^^J}
\end{filecontents}
\makeatletter
\begin{filecontents}{ot1foo.fd}
\typeout{^^J***lowercase_fd_file_for_cd!^^J}
\DeclareFontFamily{OT1}{foo}{}
\DeclareFontShape{OT1}{foo}{m}{n}{<->ssub * cmtt/m/n}{}
\end{filecontents}
\input{aBcDeFgHiJkLm.xYzW}
\fontfamily{foo}\selectfont
\stop
================================================================================
Archive-Date: Fri, 14 Oct 1994 08:54:41 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Report on the DANTE Meeting
Date: Fri, 14 Oct 1994 14:54:17 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:181090:941014135430"@cl.cam.ac.uk>
Joachim's attitude seems very reasonable to me. I am extremely glad
indeed that he has got a public support from DANTE, thats really good
work. I can promise UKTUG will do the same, co si make up theire disk
sets :-}
lets be clear that using fonts/type doesnt preclude the use of a cache
for very large installations; its just that in that case the setup is
inelegant
s
================================================================================
Archive-Date: Fri, 14 Oct 1994 09:28:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 1994 15:18:01 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Alternate suggestion for LaTeX directory trees.
To: TWG-TDS@SHSU.edu
Message-ID: <01HI9RH8IOPU96VRI4@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Actually, I'm maintaining a traditional VMS installation where
tex_root:[fonts] contained only the tfm files (there was no
directory named tfm.dir anywhere).
So tex_root:[mf.cm.test] reads
^ ^
| typeface, with subdirectories
type of the font (METAFONT).
It is easy to migrate to tex_root:[fonts.mf.cm.test] and to introduce a
directory tex_root:[fonts.tfm], if the TDS stabilises this way, I'll surely
do it. For practical reasons, I probably merge several TDS directories into
one (e.g. just having one directory for the famous 35 built-in PostScript
fonts of the laserjet). However, for compatibility reasons with LaTeX2.09,
there are two sets of tfms for those, one I have termed ``afmtotfm'' and
one ``fontinst'' by the method of generation. Fortunately there is no name
clash between the tfm files in those two directoies, but if there were any
I can easily configure the tfm searching path differently for LaTeX and
LaTeX2.09.
--J"org Knappen.
================================================================================
Archive-Date: Fri, 14 Oct 1994 10:20:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 1994 10:20:04 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Message-ID: <00985ED5.9EA9E8C0.405@SHSU.edu>
Subject: Re: Report on the DANTE Meeting
On Fri, 14 Oct 1994 14:54:17 +0100, Sebastian Rahtz
<Sebastian.Rahtz@cl.cam.ac.uk> posted:
> Joachim's attitude seems very reasonable to me. I am extremely glad indeed
> that he has got a public support from DANTE, thats really good work. I can
> promise UKTUG will do the same, co si make up theire disk sets :-}
Good work, indeed! On both your parts!! Definitely, whatever is finally
proposed will face a (at least initially) tough road as it means that some
people do have to change. Having two groups supporting it as a default
will definitely be a feather in the cap of this TWG. Thanks, gentlemen.
> lets be clear that using fonts/type doesnt preclude the use of a cache for
> very large installations; its just that in that case the setup is inelegant
While I agree with this sentiment to a large extent, this is also an area
where existing critical mass simply has to be listened to. Not that it's
necessarily the "right" approach nor the most elegant, but that it may be
the hardest single sell of the entire project in the event that it is not
followed initially. However, it might be worthwhile to include parts of
the debate in the document as providing fertile grounds for extensibility.
As a side (and probably immaterial if not ignorant) question, based on VMS
only, I don't see caching as a problem nor design of structure (except as
in the criticla mass issues which Christian has already provided). When
discussing caching (here's the truly ignorant part), how would that differ
from, say, VMS concepts of dynamically defined RMS indexing of directory
(*.DIR) files? I'm openly admitting ignorance on the concepts of caching
being discussed, but I thought that was one of the kinda implicit ideas
behind RMS concepts. If so, might a semi-port of the RMS concepts be all
that is required to get the performance issues under control?
--George
================================================================================
Archive-Date: Fri, 14 Oct 1994 10:55:02 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141555.QAA21363@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Report on the DANTE Meeting
To: TWG-TDS@SHSU.edu
Date: Fri, 14 Oct 1994 16:55:04 +0100 (MEZ)
Content-Type: text
George wrote:
>
> As a side (and probably immaterial if not ignorant) question, based on VMS
> only, I don't see caching as a problem nor design of structure (except as
> in the criticla mass issues which Christian has already provided). When
> discussing caching (here's the truly ignorant part), how would that differ
> from, say, VMS concepts of dynamically defined RMS indexing of directory
> (*.DIR) files?
It wouldn't. One can add some heuristics, but most probably this
will win only a few percent.
> If so, might a semi-port of the RMS concepts be all
> that is required to get the performance issues under control?
Sigh. ``be all that is required''. Yes, you got it. Please explain
this to the others, I tried and failed.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 14 Oct 1994 11:31:00 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qvlzK-0006WSC@rsuna.crn.cogs.susx.ac.uk>
Date: Fri, 14 Oct 94 13:43 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: draft document
>Actually, that's what I do. I use a perl script to add
>\OnlyDescription after \begin{document} of the *.dtx files, LaTeX them
>and store them in doc/latex-styles/.
Meep meep meep. Please don't do this! This sort of site-wide
configuration is what the .cfg file is for. Editing the source is
specifically not allowed in the distribution conditions.
And as far as I'm concerned, doc/latex is the right place for the .dtx
files. Either that or doc/latex for the user documentation and
doc/ltxsrc (or ltxkernel or ltxbase or something) for the source.
Alan.
================================================================================
Archive-Date: Fri, 14 Oct 1994 11:31:14 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qvm2X-0006WTC@rsuna.crn.cogs.susx.ac.uk>
Date: Fri, 14 Oct 94 13:47 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Alternate suggestion for LaTeX directory trees.
>> Although if Joachim's response is anything to go by I may as well not
>> have bothered, since it looks like he's all set to ignore whatever the
>> implementors have to say...
>In contrary.
I think I owe you an apology for that message---I wrote it as an
immediate reaction without engaging brain too much.
>Of course, I will not use this in my own installation. After all, I'm
>using Unix.
What people get up to in the privacy of their own installations is
their own business :-)
Alan.
================================================================================
Archive-Date: Fri, 14 Oct 1994 11:46:57 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qvoEA-0006WtC@rsuna.crn.cogs.susx.ac.uk>
Date: Fri, 14 Oct 94 16:07 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: cd lowercase 8+3 filenames
>I couldn't afford to commission A.J. so I have produced the following
>muself:-)
I appear to have priced myself out of this particular market...
Serves me right for insisting on my right to a minimum wage...
Alan.
PS: If you're not British, that's probably not funny.
PPS: Even if you are British, it's more sad than funny.
PPPS: That's enough PSs, ed.
================================================================================
Archive-Date: Fri, 14 Oct 1994 11:47:29 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qvoK3-0006WkC@rsuna.crn.cogs.susx.ac.uk>
Date: Fri, 14 Oct 94 16:13 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: Report on the DANTE Meeting
>There was a general overall-agreement with the TDS proposal.
This is good news!
Most of the comments I've had from developers seem to be reasonably
TDS-friendly as well. So I'm reasonably optimistic about uptake of
TDS.
>I would like to see a reflexion on this topic in the TDS, 'though.
Agreed. The form of words you suggested looked good to me.
>I was asked if it is really necessary to give the root of the TDS tree
>a fixed name. Peter and others prefered some kind of abstract notion
>like <texmf> or $TEXMF or similar. He talked about syntactic
>placeholder, not a fixed name. As a DOS person, he's reluctant to
>add one directory level if one might use a complete partition for TeX
>anyhow. I.e., he'd like to be able to use "t:" or similar for <texmf>
>and still conform to the TDS.
I'd also like to back this. I'd *much* prefer to call our TeX area
/local/tex, since this is what it's been called for years and years
and years (OK, it used to be /usr/local/tex).
Alan.
================================================================================
Archive-Date: Fri, 14 Oct 1994 12:39:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 1994 13:36:24 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199410141736.NAA27465@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Report on the DANTE Meeting
References: <m0qvoK3-0006WkC@rsuna.crn.cogs.susx.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 14 October 1994 at 16:13, Alan Jeffrey wrote:
> >I was asked if it is really necessary to give the root of the TDS tree
> >a fixed name. Peter and others prefered some kind of abstract notion
> >like <texmf> or $TEXMF or similar. He talked about syntactic
> >placeholder, not a fixed name. As a DOS person, he's reluctant to
> >add one directory level if one might use a complete partition for TeX
> >anyhow. I.e., he'd like to be able to use "t:" or similar for <texmf>
> >and still conform to the TDS.
>
> I'd also like to back this. I'd *much* prefer to call our TeX area
> /local/tex, since this is what it's been called for years and years
> and years (OK, it used to be /usr/local/tex).
Fine by me. But what's it to be called in the document. I find
<texmf>/<format>/<package>
and the like a little daunting. $TEXMF is a bit unix-specific, but is
that what we'd all like?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Knowing how things work is the basis for
Production Tools Specialist | appreciation, and is thus a source of civilized
O'Reilly & Associates, Inc. | delight." -- William Safire
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Fri, 14 Oct 1994 12:46:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 94 18:46:02 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410141746.AA01836@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Report on the DANTE Meeting
> Fine by me. But what's it to be called in the document. I find
> <texmf>/<format>/<package>
> and the like a little daunting. $TEXMF is a bit unix-specific, but is
> that what we'd all like?
There is anyway a difference: <format> is a variable within the tree
but in any given tree <texmf> is constant. why not just keep texmf
throughout the document, but in the section `rooting the tree'
say that the document, for concreteness, will use the texmf as the
root (and that this is a suggested name in practice) but that the root
can be anything (eg a DOS partition t:)
David
================================================================================
Archive-Date: Fri, 14 Oct 1994 12:48:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 1994 13:45:01 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199410141745.NAA27551@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Report on the DANTE Meeting
References: <9410141746.AA01836@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 14 October 1994 at 18:46:02, David Carlisle wrote:
> There is anyway a difference: <format> is a variable within the tree
> but in any given tree <texmf> is constant. why not just keep texmf
> throughout the document, but in the section `rooting the tree'
> say that the document, for concreteness, will use the texmf as the
> root (and that this is a suggested name in practice) but that the root
> can be anything (eg a DOS partition t:)
Sounds good to me.
================================================================================
Archive-Date: Fri, 14 Oct 1994 12:50:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 94 10:47:55 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410141747.AA08684@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: tree placement
PLEASE do not build in a fixed location for the TDS tree. Each site
administrator will have reasons for putting the tree in some location
or another, and should not be forced to mess with symbolic links, etc.
Norm and I will also get hung up by it, because our CD-ROMs will not
necessarily be able to be mounted in the designated location.
If you feel compelled to tie things down, pick a default location, but
allow it to be overridden by an environment variable or somesuch. In
fact, it should really be possible to specify multiple parallel trees
(e.g., local, network, CD-ROM, project, ...) so this capability should
already be present.
-r
================================================================================
Archive-Date: Fri, 14 Oct 1994 13:20:46 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 14 Oct 94 18:55:04 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410141755.AA01851@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Report on the DANTE Meeting
I said:
> but that the root can be anything (eg a DOS partition t:)
It ought to stress though that the root should *only* consist of TDS
material.
using c: (or /usr/local/lib on unix) and mixing everything up with
other system files isnt quite the idea...
================================================================================
Archive-Date: Fri, 14 Oct 1994 13:38:11 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 14 Oct 1994 11:38:15 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141838.LAA11514@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Robertson's Rules of Order (or something like that)
> If Karl/Pierre/Joachim feel that they could support a TDS document
> proposing fonts/type then that would be ideal.
It depends what is meant by support. I could probably rearrange the
UnixTeX distribution (which goes out to about one site a month, so it still
has some marginal value) to do fonts/type, but that would create
such a wall between the way I more or less have to work with my font
library and the distribution archive, that I think it would have the
effect of freezing things at the present level---which since I have lost
the support from Elizabeth Tachikawa is a risk anyway.
One subversive suggestion occurs to me. The pressure for fonts/type
comes often associated with the suggestion that fd and font-related
sty files should somehow be stuck into the font tree. Since this seems
to be associated almost exclusively with the use of LaTeX, and with
an assumption (which I continue to regard as dubious) that LaTeX users
will never want to go beyond CM and Times, maybe the LaTeX tfm set
should be given honorary status as macros and stuck into the texmf/tex/latex
tree. Then there is no problem of files required for the source->dvi
stage of production residing in different trees.
The fonts tree seems to be falling into complete chaos, which is odd,
because when Karl, Elizabeth and I started thinking about a more systematic
handling of directory trees, it was fonts more than anything else that
made us feel it was necessary.
Among the assumptions behind fonts/type, explicitly stated in some of the
past discussion, is that hardly anyone gives a damn about typefaces, which
may very well be true even for TeX users, and seems, to judge by the
past three months of comments to most definitely true of the vast
majority of LaTeX users.
This being the case, I wonder whether we are really trying to set
the net too wide. It appears more and more as if we are looking
exclusively at the Latex Directory Standard, not at the TeX Directory
Standard. LaTeX involves the notion of standard layouts, formats, etc.
and is an obvious candidate for association with a Directory standard.
I don't think any outside reader of the TWG-TDS correspondence could
miss the implication that except for Joachim, the people who cause
all the trouble are the TeX anarchists.
Leave the anarchists out, and it looks as if a TWG-LDS could be put
together with very little trouble. I think that if LaTeX users ever
develop a taste for fonts, the fonts side of such a LDS will become a
real nightmare to manage, but for the present there seems to be no
indication that that taste will ever develop.
So I would be perfectly prepared to set up a LDS tree for shipment
to outside sources. But I would assume that the font resources in such
a tree would always remain severely limited. Perhaps it should be limited
to fonts that have no licensing problems, either because they
are public domain, or because the license goes with the printer
so that only metrics appear in the tree.
That would be manageable.
I hope the structure stabilizes fairly soon. I have a couple of
half-baked packages and upgrades I would like to send out, and
I don't want to put them out until the preferred organization is clear.
(The horror stories of increases in typesetting time by factors of
800% when kpathsea is used keep flowing in. I don't understand it at
all. I have to do most of my work on a Sun 3-50 with only 4MB of
memory, a notoriously slow configuration these days, and while I am
quite aware of head-motion and thrashing at the startup of dvipsk (the only
program where the problem is really serious) it is never enough of a
problem to overcome the obvious advantages.) On a "real" machine, the
problem just isn't there.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
Archive-Date: Fri, 14 Oct 1994 13:50:42 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 14 Oct 1994 11:50:45 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141850.LAA14021@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Report on the DANTE Meeting
Joachim's very useful message from DANTE includes one point that
we should certainly make clear. The root of the $TEXMF tree
is whatever is convenient on any given system. The explicit
existence of a "texmf" directory was not, to be best of my
recollection, ever required. For a DOS environment it seems
entirely reasonable that $TEXMF -> T:\
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
Archive-Date: Fri, 14 Oct 1994 13:58:09 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 14 Oct 1994 11:58:11 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410141858.LAA15491@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Report on the DANTE Meeting
Agreement again. If a DOS installation uses T: for $TEXMF
I guess we have to specify that T: contains *only* $TEXMF directories
and files.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
Archive-Date: Fri, 14 Oct 1994 14:24:36 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qvsGD-0006PXC@rsuna.crn.cogs.susx.ac.uk>
Date: Fri, 14 Oct 94 20:25 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Robertson's Rules of Order (or something like that)
>This being the case, I wonder whether we are really trying to set
>the net too wide. It appears more and more as if we are looking
>exclusively at the Latex Directory Standard, not at the TeX Directory
>Standard.
Well, we're looking for the people-who-are-too-busy-doing-their-real-
jobs-to-worry-about-such-things directory standard, which a lot of the
time == LaTeX directory standard.
As far as fonts go, the LaTeX Way seems to be `all fonts welcome, as
long as they're drop-in replacements for CM' at the moment. So it's
not so much an issue of font families as font encodings, and I think
we can all agree that a font directory structure partitioned by
encoding is not on :-)
Does it seem reasonable to agree that font/type is currently the
easiest way to go for users who don't want to think very much, and
that other directory structures are open for powerusers such as
Pierre?
Alan.
================================================================================
Archive-Date: Sat, 15 Oct 1994 15:01:40 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410152001.VAA14246@spock.iti.informatik.th-darmstadt.de>
Subject: Re: draft document
To: TWG-TDS@SHSU.edu
Date: Sat, 15 Oct 1994 21:01:44 +0100 (MEZ)
Content-Type: text
You wrote:
>
> >Actually, that's what I do. I use a perl script to add
> >\OnlyDescription after \begin{document} of the *.dtx files, LaTeX them
> >and store them in doc/latex-styles/.
>
> Meep meep meep. Please don't do this!
I hope you understood me correct. The `them' in the last line you
cited are DVI files, not sources.
> This sort of site-wide configuration is what the .cfg file is for.
Not practicable as it is not usable for all kinds of distributions.
Some of them (not by the LaTeX team) don't use ltxdoc.
> Editing the source is
> specifically not allowed in the distribution conditions.
Sorry, but I don't care for that. In my source (working) directory I
do what I want. Of course, I won't distribute changed copies.
> And as far as I'm concerned, doc/latex is the right place for the .dtx
> files. Either that or doc/latex for the user documentation and
> doc/ltxsrc (or ltxkernel or ltxbase or something) for the source.
With the TDS example distribution, I'll go for the latter strategy;
separating user documentation and source. (But since web2c & TeX
sources are not in the texmf tree until now, I won't place the LaTeX
source there as well.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Sat, 15 Oct 1994 15:14:51 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410152011.VAA14292@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Robertson's Rules of Order (or something like that)
To: TWG-TDS@SHSU.edu
Date: Sat, 15 Oct 1994 21:11:11 +0100 (MEZ)
Content-Type: text
Pierre wrote:
>
> I don't think any outside reader of the TWG-TDS correspondence could
> miss the implication that except for Joachim, the people who cause
> all the trouble are the TeX anarchists.
I don't think I like that statement.
Joachim, TeX Anarchist
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Sat, 15 Oct 1994 15:16:55 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410152016.VAA14064@spock.iti.informatik.th-darmstadt.de>
Subject: Re: tree placement
To: TWG-TDS@SHSU.edu
Date: Sat, 15 Oct 1994 21:16:59 +0100 (MEZ)
Content-Type: text
Rich wrote:
>
> PLEASE do not build in a fixed location for the TDS tree.
I think there's some communication problem here, most of us would
oppose such a step. The question at hand was ``Has the last
directory element of the TDS' location a fixed name (up to now
`texmf') or not?'' There seems to be agreement that such a fixed
name is not necessary, as long as only `TeX & friends' related files
are placed in this location.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Sun, 16 Oct 1994 10:41:06 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qwVrc-0006PiC@rsuna.crn.cogs.susx.ac.uk>
Date: Sun, 16 Oct 94 14:43 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: draft document
>> >Actually, that's what I do. I use a perl script to add
>> >\OnlyDescription after \begin{document} of the *.dtx files, LaTeX them
>> >and store them in doc/latex-styles/.
>>
>> Meep meep meep. Please don't do this!
>I hope you understood me correct. The `them' in the last line you
>cited are DVI files, not sources.
Oh okay, fine. As long as the modified sources are thrown away and
it's just the dvi files that are stored, I guess this is reasonable.
Better of course would be for authors to allow the .cfg file, hey ho.
Alan.
================================================================================
Archive-Date: Mon, 17 Oct 1994 07:44:02 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410171243.NAA16919@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Sample TDS installation at Darmstadt FTP server
To: TWG-TDS@SHSU.edu
Date: Mon, 17 Oct 1994 13:43:58 +0100 (MEZ)
Content-Type: text
Christian wrote:
>
> Joachim asked if he should supply a "ls-R" file, recently.
>
> I would like to have something like that in addition to the "map" file
> of the directory layout.
The file map.lst has been replaced by two files, map.dirs and
map.files.
> This way I could study his decisions on where to locate specific files,
It's quite important that these are really *my* decisions, as I still
struggle to fit a distribution into TDS; often it's quite a vague
notion where some files do belong.
Note also that the update frequence is roughly weekly, as I typically
work on the weekend at this stuff. I have added a new category, btw;
web2c-specific archives. The directories & files from these archives
are listed in map.{dirs,files}, actually.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 17 Oct 1994 08:46:21 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qwsPX-0006QCC@rsuna.crn.cogs.susx.ac.uk>
Date: Mon, 17 Oct 94 14:47 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: [mark@ei.ele.tue.nl: TeX implementors directory questionnaire]
Another questionnaire returned... again, can support fonts/type but
not fonts/source. Mainly entertaining for the stuff on how brain-dead
the ARM directory structure evidently is...
Alan.
--- cut here ---
From: mark@ei.ele.tue.nl (Mark Sinke)
Subject: TeX implementors directory questionnaire
To: alanje@cogs.susx.ac.uk
Date: Mon, 17 Oct 94 13:55:28 MET
Mailer: Elm [revision: 70.85]
Return-Path: alanje@cogs.susx.ac.uk
NAME: Mark J. Sinke
EMAIL: marks@stack.urc.tue.nl (or preferrably, when replied within 2 months:
mark@ei0.ele.tue.nl
TEX IMPLEMENTATION: ArmTeX 3.14 (Acorn RISC machines)
This version of TeX currently supports (delete ones which don't apply):
* a list of directories for each sort of file (for example, you can
specify fonts/tfm/adobe and fonts/tfm/monotype)
* one level of subdirectory searching (for example, you can
speficify fonts/tfm and it will find fonts/tfm/adobe/ptmr7t.tfm(
* something else (please specify!):
files with .sty added are also searched without .sty. Acorn systems
don't allow extensions, so a file latex.tex is in fact a directory
`latex' containing a file `tex'. Files without extension are stored
in the directory proper.
The 1-level search is a true search, i.e., the mechanism detailed above
for storing files with extensions is not part of the search.
By this time next year, this version of TeX should (don't worry, we
won't hold you to this one!) support:
* a list of directories for each sort of file
* one level of subdirectory searching
* something else -> detailed above
If the TUG technical working group ask us to, we will implement:
* many-level subdirectory searching
* something else
Any other comments:
Please mail this to alanje@cogs.susx.ac.uk.
--- end of form ---
================================================================================
Archive-Date: Mon, 17 Oct 1994 10:10:16 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410171510.QAA22640@spice.iti.informatik.th-darmstadt.de>
Subject: problems in current version of TDS
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Mon, 17 Oct 1994 16:10:18 +0100 (MEZ)
Content-Type: text
Hi, some comments on the current draft that might need discussion.
<sect1><title>Subdirectory Searching</>
[...]
<para>
To avoid different implementations having different syntaxes for
specifying recursive subdirectory searching, the TWG recommends
that subdirectory searching be specified by a doubled
directory separator. For example, the Unix-style pathname
<filename role=dir>/a/b//</>
would recursively search all directories under
<filename role=dir>/a/b</>; likewise for
<filename role=dir>c:\a\b\\</> under MS-DOS.
</para>
This should be formulated more vague, with the notation as an example.
In VMS, such a notation makes no sense at all, directory trees are
written as [...] there. As for DOS/PublicTeX, this notation is
already used, while Eberhard wrote he is not going to support this
notation in emTeX because \\ in DOS already has a different meaning,
and he thinks the users will be confused.
<para>
Implementations may also choose to implement single-level subdirectory
searching (i.e., all the subdirectories of a given directory, but not
subsubdirectories or any deeper level). Since this is not useful for the
&tds; we leave the syntax for this unspecified.
</para>
I suggest to omit this paragraph. As you write: This is not useful
for the TDS.
The implementation must do a breadth-first search of the subdirectories:
^^^^^^^^^^^^^
Really? Why did we decide on this (if we did?) We should consider that
a DFS is *much* easier to implement.
distribution for MS-DOS and OS/2 (although em&TeX; uses a slightly different
syntax for specifying recursive subdirectory searching).
</para>
<para>
This TWG recognizes that subdirectory searching places an extra burden
If we decide to recommend pruning, we should talk about it between
these two paragraphs. Btw, there are more implemenations with
subdirectory searching than you listed above.
<para>
It should be clear that subdirectory searching does not prevent
a site from having multiple different versions of a file with the same
name (for example, during testing or debugging). By specifying
subdirectory trees in the <systemitem class=environvar>TEXINPUTS</>
environment variable, the user can control the order in which &TeX;
will search for the file and consequently the version of the file
that it will find.
</para>
Not well understandable. Actually it *does* prevent multiple versions
in a tree that's searched at one time. In addition, the term
environment variable does not exist on many platforms.
How about:
As an immediate consequence of the search strategy outlined above one
cannot place variants of a file with the same name in a tree, it is
undefined which file would be found. If one wants to use different
versions, one has to specify a <systemitem
class=environvar>TEXINPUTS</> search path that lists the respective
subtrees in the search order as needed. Then the file must be only
unique in each subtree.
<sect1><title>Constraints</>
[...]
In addition, UNIX file systems
support symbolic links, which allows a CD-ROM to be accessed
through a ``link farm'' with little space overhead on a local disk.
I still think that people won't understand this. (This gripe was
already in my last comments.) A proposal:
Unix platforms can use symbolic links (that most of them support
nowadays) to overcome these restrictions. At installation time, a
script may produce a whole TDS tree with long, case-sensitive names
that consists only of symbolic links to the CD file system. The space
overhead produced by this ``link farm'' is neglectable.
<chapter><title>Rooting the Tree</>
[...]
many systems, this may be at the root of the filesystem; however,
on UNIX systems, this would traditionally be located in <filename
role=dir>/usr/local</>.
</para>
We should give more reasons here, and also mention that this root may
(should?) be used for network mounts. Peter Breitenlohner didn't
understand what was meant at first reading.
<para>
The <replaceable>system</replaceable> directories allow multiple
implementations to share the common directory structure. For example,
the binaries for em&TeX; might be installed in <filename
role=dir>/texmf/bin/emtex</>.
</para>
I suggest not to use a DOS example, but instead the placement of FMT &
Base files for UnixTeX in texmf/ini/web2c-<version>/. (The latter
name is not ISO-conform, I know...)
<chapter><title>Macros</>
[...]
<listitem><para>
The alternative arrangement spreads out the files needed by the system.
The files that must be found using subdirectory searching may be spread
out in a wide, shallow tree. Fonts are no longer in a directory of
their own (since they must be under the package). This spreading effect
could have a profound impact on the efficiency of subdirectory searching.
</para></listitem>
This para is a problem! We argue here quite in favor of the fonts/type
approach. If this is going to be the looser, we might want to change
this paragraph.
<chapter><title>Fonts</title>
[...]
<sect2><title>Valid Font Bitmaps</title>
<para>
There was considerable discussion about how the disadvantages of this
scheme could be minimized. One result of that discussion was the
decision to allow extensions to the basic naming scheme (such as
<filename>cmr10.300pk</>) provided that the basic scheme is also
supported. The following statement is the other:
^^^
I suggest to insert here:
But still multiple files with the same name would exist (for different
devices).
<chapter><title>Package Distribution</>
[...]
martian-1.0/fonts/martian/tfm/mart10.tfm
Two points:
First, the naming is not ISO 9660 conform -- do we regard this as
relevant? I won't, since it's a section for a package distributor,
who will most likely *not* distribute on CD. And such brave persons
should not be hindered too much.
Second, a structure like this will make CTAN unusable, cf. past mails
from David & me.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 17 Oct 1994 10:21:16 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410171521.QAA17790@spice.iti.informatik.th-darmstadt.de>
Subject: hyphen, still problems
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Mon, 17 Oct 1994 16:21:18 +0100 (MEZ)
Content-Type: text
Thanks to sebastian, we now have proper names for the hyphenation
files. But still, I have my problems with the respective TDS draft
item.
-- On second reading, I would recommend to discard all comments about
the names of hyphenation files. We do not fix any file name for
any other part of the TDS, why should we do that here? I think
the whole discussion I brought up muddied the water, sorry for
that. Specific file names should be outside the realm of this WG.
-- We discussed about introducing hyphen/ subdirectories for each
language. Actually, I did so for the TDS example distr. But
there I have the problem that I don't know how to restrict the
directory names to 8 chars. Truncating? Or shall I flatten the
tree?
Any comments on this topic would still be appreciated. (And it
will remain on my open problem list...)
-- I would prefer to rename tex/hyphen/ to tex/initex/hyphen, as I
have some INITEX-specific macro files that I don't know where I
should place them. If we introduce tex/initex/ I can create a
subdirectory there.
-- Peter Breitenlohner asks if one couldn't put _all_ INITEX-specific
files under tex/initex/. E.g., plain.tex, LaTeX's *.ltx files,
etc. He thinks that the usage intent is much clearer then. (Note
that currently LaTeX's *.ltx are *not* installed by default.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 17 Oct 1994 10:40:31 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410171540.QAA17805@spice.iti.informatik.th-darmstadt.de>
Subject: documentation
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Mon, 17 Oct 1994 16:40:32 +0100 (MEZ)
Content-Type: text
Chapter 6 (`Documentation') lists
texmf/doc/<package>/<files>
as the basic structure there. The usage of the term <package> is
problematic, as this is a different <package> than the one used in
chapter 3 (`macros'). I would recommend to substitute it by <system>
and explain that <system> encompasses both utilities, macro formats
and major packages. Another possibility might be <entity>.
Actually, IMO the name should be rather vague. One cannot really make
an abstract decision what would be a good directory structure for the
documentation area, this needs more experiments and usability tests,
of course.
I discussed it with some users that were around this morning (approx.
10). They prefer to have doc/ subdirectories that denote task
categories. They need docs for BibTeX and other bibliographic tools,
docs on available styles (aka LaTeX modules), on available plain
macros, etc. They did *not* prefer to have a directory for each
style, as most styles come with only one documentation file. They did
also not like the idea of lumping all single-file documentations in
one directory misc/, they complained that they won't find it then
easily enough.
As a result of this discussion (and others I had before), I've
started to use a directory doc/latex-styles/ for documentation on
LaTeX modules. I would like to get recommendations for an ISO 9660
conformant name that is still indicative (? evidential?). Did I tell
you that I hate DOS?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 17 Oct 1994 10:55:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 17 Oct 94 16:55:14 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410171555.AA03884@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: documentation
> As a result of this discussion (and others I had before), I've
> started to use a directory doc/latex-styles/ for documentation on
drwxrwsr-x 9 graham 512 Aug 26 14:04 LaTeX-doc-files/
Hmm seems like our name wouldnt quite fit in DOS either.
> I would like to get recommendations for an ISO 9660
> conformant name that is still indicative (? evidential?). Did I tell
> you that I hate DOS?
latexdoc/ ???
David
================================================================================
Archive-Date: Mon, 17 Oct 1994 11:20:50 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: hyphen, still problems
Date: Mon, 17 Oct 1994 16:52:53 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:069330:941017155324"@cl.cam.ac.uk>
>
> -- We discussed about introducing hyphen/ subdirectories for each
> language. Actually, I did so for the TDS example distr. But
> there I have the problem that I don't know how to restrict the
> directory names to 8 chars. Truncating? Or shall I flatten the
> tree?
lets change them permaenently on CTAN, with the cooperation of
authors. which ones bother you still?
> -- I would prefer to rename tex/hyphen/ to tex/initex/hyphen, as I
> have some INITEX-specific macro files that I don't know where I
> should place them. If we introduce tex/initex/ I can create a
> subdirectory there.
sounds plausible to me
> -- Peter Breitenlohner asks if one couldn't put _all_ INITEX-specific
> files under tex/initex/. E.g., plain.tex, LaTeX's *.ltx files,
> etc. He thinks that the usage intent is much clearer then. (Note
> that currently LaTeX's *.ltx are *not* installed by default.)
as in tex/initex/latex/latex.ltx? i must say i cant see anything
against that.
sebastian
================================================================================
Archive-Date: Mon, 17 Oct 1994 11:27:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410171627.RAA23328@spice.iti.informatik.th-darmstadt.de>
Subject: Re: hyphen, still problems
To: TWG-TDS@SHSU.edu
Date: Mon, 17 Oct 1994 17:27:30 +0100 (MEZ)
Content-Type: text
sebastian wrote:
>
> > -- We discussed about introducing hyphen/ subdirectories for each
> > language. Actually, I did so for the TDS example distr. But
> > there I have the problem that I don't know how to restrict the
> > directory names to 8 chars. Truncating? Or shall I flatten the
> > tree?
> lets change them permaenently on CTAN, with the cooperation of
> authors. which ones bother you still?
No, on CTAN you don't have subdirectories. I.e., all hyphen files are
in one directory on CTAN, but are distributed over many directories in
the TDS (named english, portuguese, icelandic, german, etc.) The
rationale for these directory was (once) that now administrators might
easier recognize for which languages they have patterns.
I'm happy to use just the hyphen/ directory as it is on CTAN, without
any subdirectories.
If the subdirectories remain, I must change names like `portuguese'
since they are too long.
> > -- Peter Breitenlohner asks if one couldn't put _all_ INITEX-specific
> > files under tex/initex/. E.g., plain.tex, LaTeX's *.ltx files,
> > etc. He thinks that the usage intent is much clearer then. (Note
> > that currently LaTeX's *.ltx are *not* installed by default.)
> as in tex/initex/latex/latex.ltx?
Exactly.
> i must say i cant see anything against that.
I think it's a neat idea, too.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 17 Oct 1994 12:12:52 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qwvdN-0006QBC@rsuna.crn.cogs.susx.ac.uk>
Date: Mon, 17 Oct 94 18:14 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: hyphen, still problems
>> as in tex/initex/latex/latex.ltx?
>> i must say i cant see anything against that.
Seems OK to me. Does this give us something like:
tex/initex/latex/* (latex.ltx, fontdef.cfg, etc.)
plain/* (plain.tex, er... eplain.tex?)
hyphen/* (hyphen.tex etc.)
amstex/* (etc)
fontinst belongs in tex/fontinst/* on sites which bother with it.
Alan.
================================================================================
Archive-Date: Tue, 18 Oct 1994 03:50:26 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: hyphen, still problems
Date: Tue, 18 Oct 1994 09:49:54 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:135330:941018085011"@cl.cam.ac.uk>
> No, on CTAN you don't have subdirectories. I.e., all hyphen files are
> in one directory on CTAN, but are distributed over many directories in
not quite. the intention is to populate hyphenation with links from
language subdirectories.
> the TDS (named english, portuguese, icelandic, german, etc.) The
> rationale for these directory was (once) that now administrators might
> easier recognize for which languages they have patterns.
>
> I'm happy to use just the hyphen/ directory as it is on CTAN, without
> any subdirectories.
>
> If the subdirectories remain, I must change names like `portuguese'
> since they are too long.
i am happy to wield my unilateral axe again and rename all language
directories to their babel names, how would that be?
sebastian
================================================================================
Archive-Date: Tue, 18 Oct 1994 05:24:03 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410181024.LAA16658@spice.iti.informatik.th-darmstadt.de>
Subject: Re: hyphen, still problems
To: TWG-TDS@SHSU.edu
Date: Tue, 18 Oct 1994 11:24:04 +0100 (MEZ)
Content-Type: text
You wrote:
>
> >> as in tex/initex/latex/latex.ltx?
> >> i must say i cant see anything against that.
>
> Seems OK to me. Does this give us something like:
>
> tex/initex/latex/* (latex.ltx, fontdef.cfg, etc.)
> plain/* (plain.tex, er... eplain.tex?)
> hyphen/* (hyphen.tex etc.)
> amstex/* (etc)
Yes, I like this. I'll do it.
But I would still put texinfo.tex in tex/plain/texinfo or
tex/texinfo/. (texinfo.tex is somewhat a chamaeleon; it's used by
most people as a macro file, but can be used to create a format,
too.) I.e., in tex/initex/ should only go files whose *sole* purpose
is to be processed by initex with the intent to produce an FMT file.
> fontinst belongs in tex/fontinst/* on sites which bother with it.
Fine -- the author decides. :-) I'd already started to think about
texmf/fontinst/, as it is more a kind of utility, like BibTeX or
Makeindex, that happens to be written in TeX. It's not really a TeX
macro file in the sense that it provides markup for documents, as far
as I understood it.
That brings me to the point that we need a definition section where
we define the terms used in the document. Do we mean with `macro
file' all files that have TeX code or do we mean only those that
deliver markup (be it procedural or generic) for documents?
The same goes for other terms like `search path', etc. (We should
use the term `environment variable' only in examples and in notes.
That's an unportable term, as there are many OSes where it's not
used.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Tue, 18 Oct 1994 07:30:07 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qxDhF-0006QUC@rsuna.crn.cogs.susx.ac.uk>
Date: Tue, 18 Oct 94 13:31 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: hyphen, still problems
>I.e., in tex/initex/ should only go files whose *sole* purpose
>is to be processed by initex with the intent to produce an FMT file.
This sounds like a good rule of thumb.
>Fine -- the author decides. :-) I'd already started to think about
>texmf/fontinst/, as it is more a kind of utility, like BibTeX or
>Makeindex, that happens to be written in TeX. It's not really a TeX
>macro file in the sense that it provides markup for documents, as far
>as I understood it.
I'd rather have it under tex/ so that if lazy people wish they can
just set TEXINPUTS to be everything under $TEXMF/tex.
Alan.
================================================================================
Archive-Date: Wed, 19 Oct 1994 05:19:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 19 Oct 1994 06:19:10 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410191019.AA28619@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
musictex and texinfo are often (usually?) not actually built as
formats. Especially musictex, which works, just about, with LaTeX.
Here you are only trying to give helpful examples, perhaps best just
to delete such marginal cases here
IMO, it is precisely the role of a document like this to define the
marginal cases. The easy cases are easy.
In this case, I sort of think Texinfo and MusicTeX should be treated as
separate formats, but don't have strong feelings about it. But I do
think the document should say where they go.
================================================================================
Archive-Date: Wed, 19 Oct 1994 05:19:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 19 Oct 1994 06:19:28 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410191019.AA28779@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: problems in current version of TDS
The implementation must do a breadth-first search of the subdirectories:
^^^^^^^^^^^^^
Really? Why did we decide on this (if we did?) We should consider that
a DFS is *much* easier to implement.
There should be no specification of either breadth-first or depth-first.
We've already discussed this ad nauseum. What you want is for it to find
the files that it *should* find (i.e., the fonts for the right mode),
and neither breadth- nor depth-first meets that criterion.
At least, it would be extremely difficult for me to implement any such
specification, and I see no advantage to doing so.
Base files for UnixTeX in texmf/ini/web2c-<version>/. (The latter
name is not ISO-conform, I know...)
I see no reason to recommend a version number here. We are avoiding the
whole issue of different versions everywhere else.
================================================================================
Archive-Date: Wed, 19 Oct 1994 06:20:06 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410191119.MAA14801@spice.iti.informatik.th-darmstadt.de>
Subject: Re: draft document
To: TWG-TDS@SHSU.edu
Date: Wed, 19 Oct 1994 12:19:43 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> In this case, I sort of think Texinfo and MusicTeX should be treated as
> separate formats,
Me, too.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 19 Oct 1994 06:21:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410191121.MAA20185@spice.iti.informatik.th-darmstadt.de>
Subject: Re: problems in current version of TDS
To: TWG-TDS@SHSU.edu
Date: Wed, 19 Oct 1994 12:21:26 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> Base files for UnixTeX in texmf/ini/web2c-<version>/. (The latter
> name is not ISO-conform, I know...)
>
> I see no reason to recommend a version number here. We are avoiding the
> whole issue of different versions everywhere else.
As usual, he's completely right. Nevertheless, I would like that
example more than the binaries. Where binaries are put is a highly
site-dependent decision. That FMT & Base files are stored in the texmf
tree, is much more likely. (Or is this opinion just because it's the
way we're doing it? :-)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Thu, 20 Oct 1994 04:10:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 20 Oct 94 10:09:54 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410200909.AA05830@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
> musictex and texinfo are often (usually?) not actually built as
> formats. Especially musictex, which works, just about, with LaTeX.
> Here you are only trying to give helpful examples, perhaps best just
> to delete such marginal cases here
>
> IMO, it is precisely the role of a document like this to define the
> marginal cases. The easy cases are easy.
>
> In this case, I sort of think Texinfo and MusicTeX should be treated as
> separate formats, but don't have strong feelings about it. But I do
> think the document should say where they go.
>
Hmm good point. OK, I think the TDS document should have a section
saying where these (and other difficult cases) should go. Hoewver I
dont think this shoould be `slipped in' in the sentence introducing
the notion of <format> as at present. The examples there should stick to
plain latex etc, so that people understand what <format> is. A later
section might discuss the positioning of certain specific items?
David
================================================================================
Archive-Date: Thu, 20 Oct 1994 05:06:47 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qxuNG-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 20 Oct 94 11:05 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: [vojta@math.berkeley.edu: Re: TeX directory structures]
Another reply, interesting for Paul's comments on subdirectory
searching and efficiency. Don't think he's going to be too pleased
with TDS. Hey ho.
Alan.
--- cut here ---
From: vojta@math.berkeley.edu (Paul Vojta)
Date: Wed, 19 Oct 1994 17:58:53 -0700
To: alanje@cogs.susx.ac.uk
Subject: Re: TeX directory structures
NAME: Paul Vojta
EMAIL: vojta@math.berkeley.edu
TEX IMPLEMENTATION: xdvi
This version of TeX ^H^H^H^H xdvi currently supports:
* only one directory for each sort of file (for example, all tfm
files have to be in fonts/tfm)
* a list of directories for each sort of file (for example, you can
specify fonts/tfm/adobe and fonts/tfm/monotype)
* one level of subdirectory searching (for example, you can
speficify fonts/tfm and it will find fonts/tfm/adobe/ptmr7t.tfm)
* many-level subdirectory searching (for example, you can
specify fonts/tfm and it will find fonts/tfm/adobe/times/ptmr7t.tfm)
By this time next year, this version of TeX ^H^H^H^H xdvi should support:
* only one directory for each sort of file
* a list of directories for each sort of file
* one level of subdirectory searching
* many-level subdirectory searching
* many-level subdirectory searching with pruning
somewhat reluctantly (see below)
* many-level subdirectory searching with a cache
somewhat reluctantly, again
* something else
.fli files, maybe
If the TUG technical working group ask us to, we will implement:
* only one directory for each sort of file
* a list of directories for each sort of file
* one level of subdirectory searching
* many-level subdirectory searching
* many-level subdirectory searching with pruning
* many-level subdirectory searching with a cache
* something else
Any other comments:
Yes. As noted above, I'm not entirely sold on the idea of putting files
into subdirectories _on end-user systems_. Certainly it's a good idea
for organizing the directories on CTAN, but beyond that point I disagree.
Let me elaborate.
First, I recall several people pointing out the necessity for run-time
efficiency. That is my primary concern.
Now some timings. These were done on a Linux 486-33 with IDE drive.
I was using ntex01 at the time, running amstex on a short (3-page) file.
1. Without ls-R:
1.870u 1.370s 14.39
2. With ls-R:
2.010u 0.430s 5.45
3. Without ls-R, but after doing the following:
cd /usr/lib/texmf
mkdir pv_tfm
mkdir pv_macros
find fonts -name \*.tfm -exec ln \{\} pv_tfm \;
find tex -type f -exec ln \{\} pv_macros \;
setenv TEXFONTS .:/usr/lib/texmf/pv_tfm
setenv TEXINPUTS .:/usr/lib/texmf/pv_macros
1.660u 0.570s 5.10
All timings were done immediately after rebooting (except for the setenv's
in 3). All reboots skipped fsck.
Note that the last number, elapsed time in seconds, is better with all files
in one directory. I've heard mention of some systems on which this would
be worse, but I'd like to hear specifics: names of systems, and timings
as above.
Of course, on a system where somebody is installing TeX from scratch
but expects only occasional use, then certainly pulling the CTAN directory
structure would be appropriate, and for that reason I plan to implement
subdirectory searching and (some form of) ls-R. But on the opposite extreme,
if somebody is assembling, e.g., a TeX distribution for linux, then they
should spare no effort in making it as efficient as possible. In that
case they should do as in #3, possibly with mv in place of ln. As for
the maintainability question, what people usually do with distributions
of TeX is they usually just replace the whole thing when they upgrade.
Perhaps it is instructive to compare this situation with the situation
for Unix as a whole. We don't have subdirectory searching for
/usr/man/man<n> or for /bin, yet they are big directories:
_tashkent% ls /usr/man/man1 | wc -l
497
_tashkent% ls /usr/man/man3 | wc -l
1169
_tashkent% ls /bin | wc -l
234
The way to manage this is to have a package installation tool; Unix
vendors actually, therefore, do have a "directory structure" as in TDS,
which no doubt exists on their development systems, but on user systems
it is represented implicitly in the installation procedure rather than
explicitly on disk.
--------------------
As a second comment (which also has a lot to do with my stated reluctance
to implement directory pruning and ls-R) is that I have already put quite
a bit of time into font searching in xdvi. Early on I implemented a search
strategy which allows you to put in printf-style descriptors %f, %d, and %p
(font, dpi, and pk/gf/pxl format, respectively) and which allowed you to
specify your own search path in addition to the default. I thought that
this would be sufficient until the end of time (and in fact it suffices
for #3 above). Then Karl asked me to put in subdirectory searching
(as indicated above), which I did with some reluctance. Now there's ls-R
and directory pruning. What next?
If TDS-II requires any changes to xdvi, it'll take quite a bit of convincing
to get me to make those changes. Time spent on font searching in xdvi
is time taken away from implementing the rotation and color specials for
LaTeX-2e, switching dvi files on-the-fly, etc.
--------------------
Please mail this to alanje@cogs.susx.ac.uk.
================================================================================
Archive-Date: Thu, 20 Oct 1994 05:20:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 20 Oct 1994 06:17:19 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199410201017.GAA21068@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: draft document
References: <9410200909.AA05830@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 20 October 1994 at 10:09:54, David Carlisle wrote:
> > musictex and texinfo are often (usually?) not actually built as
> > formats. Especially musictex, which works, just about, with LaTeX.
> > Here you are only trying to give helpful examples, perhaps best just
> > to delete such marginal cases here
> >
> > IMO, it is precisely the role of a document like this to define the
> > marginal cases. The easy cases are easy.
> >
> > In this case, I sort of think Texinfo and MusicTeX should be treated as
> > separate formats, but don't have strong feelings about it. But I do
> > think the document should say where they go.
>
> Hmm good point. OK, I think the TDS document should have a section
> saying where these (and other difficult cases) should go. Hoewver I
> dont think this shoould be `slipped in' in the sentence introducing
> the notion of <format> as at present. The examples there should stick to
> plain latex etc, so that people understand what <format> is. A later
> section might discuss the positioning of certain specific items?
Sounds good.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The First Amendment is often inconvenient. But
Production Tools Specialist | that is besides the point. Inconvenience does
O'Reilly & Associates, Inc. | not absolve the government of its obligation to
90 Sherman Street | tolerate speech." -- Justice Anthony Kennedy, in
Cambridge, MA 02140 | 91-155
(617) 354-5800/661-1116 FAX |
================================================================================
Archive-Date: Thu, 20 Oct 1994 05:25:48 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
Date: Thu, 20 Oct 1994 11:20:15 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:181060:941020102520"@cl.cam.ac.uk>
i dont think Paul Vojta is entirely out of court. i think we would all
regard it ias acceptable to locally configure TeX to be efficient in
whatever ways seemed right, so long as
a) we talk TDS language in public
b) we provides tools to help our users uses the system as if it were
TDS.
i see no harm in configuring xdvi to look at a flat directory setup
populated with links to a TDS tree
sebastian
================================================================================
Archive-Date: Thu, 20 Oct 1994 14:05:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 20 Oct 1994 15:04:35 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410201904.AA25973@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: vojta@math.berkeley.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
If the TDS is to be used only on CTAN and for interchange, and not for
installations, then the whole thing is pointless, as far as I can see.
We got into this so that package/implementation maintainers could all
have one directory standard for the default installation. If many sites
feel the need to flatten the tree, then we've failed.
I think there are very ``end user'' systems as Paul V. describes them,
and very few people putting together (or using) monolithic TeX
packages. For better or worse, the TeX software is a distributed entity,
maintained by many many different people, used by even more people, all
with their own circumstances. Our task is to find a directory structure
that can both be used *and* be maintainable. No subdirs wins on
usability, but not maintainability.
As I and others said long ago, the crucial turning point is not between
subdirectory searching with/without pruning, or with/without caching or
with/without anything else. It's whether there is subdirectories
*at all*. The only thing which is supported by all implementations, and
the only thing with no performance loss (except on VMS) is no subdir
searching.
Most texadmins certainly do not, so far as I know, replace the entire
tex tree when they upgrade; they have their own local packages and
fonts, their own favorite outside macro packages, etc. When they (I
should say `we') upgrade a macro package, we don't change the TeX
binary.
Then Karl asked me to put in subdirectory searching
(as indicated above), which I did with some reluctance.
Just as a point of fact, so far as I know I didn't just ask you to put
in that feature, I gave you the code to do it, integrated into the
then-current xdvi.
Now there's ls-R and directory pruning. What next?
Runtime configuration files :-)
Believe me, I would like nothing better than to stop working on file
searching. But I feel compelled to do it right.
Anyway, I have yet to be convinced that directory pruning is necessary,
given ls-R. My experience with ls-R is different from your times --
namely, that it is *far far* more necessary. Perhaps your document
didn't load many fonts/macros, or maybe your trees don't have all the
PostScript+LJ fonts subdir-ized. There are too many variables.
I've heard mention of some systems on which [all files in one dir] would
be worse, but I'd like to hear specifics: names of systems, and timings
as above.
George et al. said VMS was in this category.
However, I can personally vouch for the fact that it takes a noticeably
long time to search for a file in a directory with 30,000 files
... fortunately, TeX isn't quite there yet!
================================================================================
Archive-Date: Thu, 20 Oct 1994 14:49:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 20 Oct 1994 14:49:14 CDT
From: "George D. Greenwade" <bed_gdg@SHSU.edu>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: vojta@math.berkeley.edu
Message-ID: <009863B2.3761BB20.183@SHSU.edu>
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
On Thu, 20 Oct 1994 15:04:35 -0400, "K. Berry" <kb@cs.umb.edu> posted:
> I've heard mention of some systems on which [all files in one dir] would
> be worse, but I'd like to hear specifics: names of systems, and timings
> as above.
>
> George et al. said VMS was in this category.
VMS has a problem in handling directory files (*.DIR) which are in excess
of 128 512-byte blocks. The length of file names, as well as the number of
files, held in a directory impact directly the size of the *.DIR file.
Hence, there's no magic number of files in the directory which cause the
problem; instead, it's the number of characters in the filenames which are
of major concern. So long as the directory stays below 128 blocks, it is
effectively cached; once it hits the magic number of 128 or exceeds it,
each time a file in a directory is accessed, it requires a read of the
*.dir file. In other words, system performance takes a major whammy and
benchmarking is nearly out of the question as disk access is a function of
so many factors that replicating anything once you have to deal with disk
access issues, you're effectively hosed.
I'm sure that Christian, Phil, or others can say all of this much more
proficiently (and professionally!) than I can, but that is the effect.
--George
================================================================================
Archive-Date: Thu, 20 Oct 1994 19:15:45 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Thu, 20 Oct 1994 17:15:57 -0700
Message-ID: <199410210015.RAA12040@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
Karl Berry writes:
> I think there are very [many?] ``end user'' systems as Paul V. describes them,
> and very few people putting together (or using) monolithic TeX
> packages. For better or worse, the TeX software is a distributed entity,
> maintained by many many different people, used by even more people, all
> with their own circumstances. Our task is to find a directory structure
> that can both be used *and* be maintainable. No subdirs wins on
> usability, but not maintainability.
Well, I doubt that most users of TeX under linux compile their own TeX.
> Most texadmins certainly do not, so far as I know, replace the entire
> tex tree when they upgrade; they have their own local packages and
> fonts, their own favorite outside macro packages, etc. When they (I
> should say `we') upgrade a macro package, we don't change the TeX
> binary.
When you do install the TeX binary, do you put it into /bin or /usr/bin
and then complain that Unix is not maintainable? No, you put it in
/usr/local/bin (assuming you don't give TeX its own place on the standard
search path) and then you preserve /usr/local between O/S upgrades.
Likewise, one could (should?) put the standard TeX distribution in
/usr/lib/texmf/ and local stuff in /usr/local/lib/texmf/.
> Then Karl asked me to put in subdirectory searching
> (as indicated above), which I did with some reluctance.
>
> Just as a point of fact, so far as I know I didn't just ask you to put
> in that feature, I gave you the code to do it, integrated into the
> then-current xdvi.
Correct.
...
> Anyway, I have yet to be convinced that directory pruning is necessary,
> given ls-R. My experience with ls-R is different from your times --
> namely, that it is *far far* more necessary. Perhaps your document
> didn't load many fonts/macros, or maybe your trees don't have all the
> PostScript+LJ fonts subdir-ized. There are too many variables.
Have any numbers?
One way to look at what I'm saying is: why should TeX, etc. do its own
caching, when it can be done with existing mechanisms in the O/S (at
least under Unix)?
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
Archive-Date: Thu, 20 Oct 1994 19:37:32 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Thu, 20 Oct 1994 17:38:05 -0700
Message-ID: <199410210038.RAA12073@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
George D. Greenwade <bed_gdg@SHSU.edu> writes:
> On Thu, 20 Oct 1994 15:04:35 -0400, "K. Berry" <kb@cs.umb.edu> posted:
> > I've heard mention of some systems on which [all files in one dir] would
> > be worse, but I'd like to hear specifics: names of systems, and timings
> > as above.
> >
> > George et al. said VMS was in this category.
>
> VMS has a problem in handling directory files (*.DIR) which are in excess
> of 128 512-byte blocks. The length of file names, as well as the number of
> files, held in a directory impact directly the size of the *.DIR file.
> Hence, there's no magic number of files in the directory which cause the
> problem; instead, it's the number of characters in the filenames which are
> of major concern. So long as the directory stays below 128 blocks, it is
> effectively cached; once it hits the magic number of 128 or exceeds it,
> each time a file in a directory is accessed, it requires a read of the
> *.dir file.
Well, at our site, the tfm directory contains 671 fonts in a directory
that is 14848 bytes long. This suggests that the max. number of fonts
is about 65536 * 671 / 14848 or 2900 fonts. Of course VMS uses different
data structures no doubt, but I'm using the only figures that I can get
my hands on.
How quickly are TeX fonts proliferating?
> In other words, system performance takes a major whammy and
> benchmarking is nearly out of the question as disk access is a function of
> so many factors that replicating anything once you have to deal with disk
> access issues, you're effectively hosed.
I don't follow. If system performance takes a major whammy, then it would
seem to me that a benchmark would catch it :-). It's minor whammies that
get lost in the noise.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
Archive-Date: Fri, 21 Oct 1994 07:53:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 21 Oct 1994 08:51:57 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
To: TWG-TDS@SHSU.edu
Message-ID: <782743918.15927.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
regarding how many fonts (files) can be held in a single vms
directory, george greenwade has said that as long as the size of
the directory file "stays below 128 blocks, it is effectively
cached". there is also, though i don't remember the exact number,
an absolute maximum on the number of files that can be contained
in one directory -- we've hit it, and everything comes to a
screeching halt. i remember that this happened in a data, not
a font, directory, but getting things into shape to continue
operating was generally unpleasant and time-consuming, especially
since it wasn't expected, we were under a deadline, etc., etc.
i don't actually expect the number of fonts will go this high,
but the possibility is something that shouldn't be omitted
entirely from consideration. we have also, on one of our unix
systems, run out of what our unix guru called (i believe) "file
handles", i.e., named files. another case of lost time.
paul vojts has also questioned george's explanation of why
benchmarking is difficult, if not impossible:
> In other words, system performance takes a major whammy and
> benchmarking is nearly out of the question as disk access is a function of
> so many factors that replicating anything once you have to deal with disk
> access issues, you're effectively hosed.
I don't follow. If system performance takes a major whammy, then it would
seem to me that a benchmark would catch it :-). It's minor whammies that
get lost in the noise.
the problem is, as i see it, that vms systems are usually shared.
if a hundred other people are doing things on the system at the
same time, disk access is going to be entirely demand-fed, and
swapping and paging will affect the cpu time measured, never mind
the randomness of the elapsed time because of other unpredictable
activity. so although it may be obvious that kicking the font
directory over the 128-block boundary takes longer, as george says,
it will be essentially impossible to replicate the actual numbers.
(i don't think i've ever had one of our vms systems all to myself,
even at 3:00 in the morning. there's always something else going on.)
-- bb
================================================================================
Archive-Date: Fri, 21 Oct 1994 10:35:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 21 Oct 94 16:34:17 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410211534.AA07000@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: public discussion
How come our fonts/source/type discussion is being discussed on c.t.t
before we get the draft to the implementors?
David
=====================================================================
Newsgroups: comp.text.tex
From: pdc@comlab.ox.ac.uk (Damian Cugley)
Subject: Re: what ever happened to the TeX directory structure committee?
Originator: pdc@msc13.comlab
Organization: Computing Laboratory, Oxford University, UK
Date: Fri, 21 Oct 1994 14:10:13 GMT
In article <37tllj$13t0@rs18.hrz.th-darmstadt.de>
schrod@iti.informatik.th-darmstadt.de (Joachim Schrod) writes:
> In article <1994Oct13.153440.16546@msc13.comlab.ox.ac.uk>, pdc@comlab.ox.ac.uk (Damian Cugley) writes:
>> Seriously, how am I supposed to write a document on how to install
>> Malvern fonts when I just do not know what the names of directories
>> are supposed to be yet?
>
> I'll tell you what would have happened: You would have followed a
> draft where the particular issue of font directory layout is under
> discussion again.
In effect I *have* followed a "draft" (in the form of a TeX system I
installed) that was invalidated a week after I announced Malvern 1.2.
The TeX system I installed has "big-endian" font directories, meaning
that "big" entities like foundries are at the top of the tree. The
current status of the TDS discussion (according to my sources) is
little-endian, with the name of the type of file at the top.
(I read the draft -- it still specifies big-endian. don't use
big-endian and littl-endian in the draft, so here's a diagram saying
what I mean:
BIG-ENDIAN LITTLE-ENDIAN
fonts/ fonts/
adobe/ afm/
times/ adobe/
afm/ bitstream/
tfm/ ...
... tfm/
... adobe/
bitstream/ bitstream/
... malvern/
public/ ...
malvern/ mf/
tfm/ malvern/
src/ ...
...
I've used "malvern" as the family name in this example; it would be nice
to be able to include the version ID but then we run out of characters
in the file name.)
I agree that there is no point getting people to use a standard before
it is fully sorted out -- and I said so in part of my original message
deleted above... It's not that I don't appreciate the difficulty of
thrashing out these standards (since I've been peripherally involved in
discussion of 8-character font file names). It's just inconvenient if
this means I have to keep Malvern in limbo for ages. Malvern 1.1 was
delayed for months because I tried to wait for font names to be sorted
out.
"TWG-TDS"... Is there an on-line list of these TWGs and other TLAs?
--
P. Damian Cugley * * * * * * * * * * * * * * * <damian.cugley@comlab.ox.ac.uk>
Oxford University Computing Laboratory, Parks Road, Oxford OX1 3QD, UK
Alleged Literature, c/o Damian Cugley, 255B Banbury Road, Oxford OX2 7HN, UK
http://boothp1.ecs.ox.ac.uk:5705/people/pdc.html * My other computer is a Linux
================================================================================
Archive-Date: Fri, 21 Oct 1994 12:31:50 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qyNEP-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 21 Oct 94 17:54 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: public discussion
>How come our fonts/source/type discussion is being discussed on c.t.t
>before we get the draft to the implementors?
Arrrggghh, sorry about that. I'm the leak. I didn't think Damian
would send the contents of my natter on the phone with him to the
whole of c.t.t...
I'll mail him and point out that this is a slightly touchy subject...
Alan.
================================================================================
Archive-Date: Fri, 21 Oct 1994 12:44:13 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410211742.SAA19255@spice.iti.informatik.th-darmstadt.de>
Subject: Re: public discussion
To: TWG-TDS@SHSU.edu
Date: Fri, 21 Oct 1994 18:42:58 +0100 (MEZ)
Content-Type: text
David wrote:
>
> How come our fonts/source/type discussion is being discussed on c.t.t
> before we get the draft to the implementors?
I don't think it's discussed, just mentioned. If you read c.t.t, you
can skip the rest.
As I am cited below, some background: A person asked on c.t.t about
the TDS, I answered in email. Damian made a followup article where he
complained that nothing happens. I don't think that potential users
shouldn't know what happens in the TeX arena before it's finished and
released. (That view might be a bit different from the one the LaTeX
team holds [sorry, could not resist... ;-)].) But being an HCI guy, I
am a True Believer (tm) in a user-centered, iterative, open design
process. Well, I answered in a public f'up that there is still
discussion over that particular point (font dirs) and pointed out
where one can get more information. (This is not secret anyhow as the
mailing list backlog is available over George's gopher server.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 21 Oct 1994 12:53:36 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410211753.SAA19286@spice.iti.informatik.th-darmstadt.de>
Subject: Re: hyphen, still problems
To: TWG-TDS@SHSU.edu
Date: Fri, 21 Oct 1994 18:53:22 +0100 (MEZ)
Content-Type: text
sebastian wrote:
>
> > If the subdirectories remain, I must change names like `portuguese'
> > since they are too long.
>
> i am happy to wield my unilateral axe again and rename all language
> directories to their babel names, how would that be?
Seems nobody is interested except you and me. :-( I asked Christine
(my partner) and she said that from a user's point she would prefer a
directory with a README that lists all files over a lot of
subdirectories that have only one file.
As Christine is always right, I think we should mention in the TDS
draft that no subdirs are to be expected below tex/initex/hyphen/. (I
assume that the introduction of tex/initex/ is OK as no contrary
opinions were raised.)
Then sebastian doesn't have to run around with an axe, too. Perhaps
that would frighten his two women, and we won't get guilty for that,
do we?
Joachim
[Think I should stop posting in the mood I am today. ;-)]
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 24 Oct 1994 04:35:32 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: hyphen, still problems
Date: Mon, 24 Oct 1994 09:35:05 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:266920:941024093519"@cl.cam.ac.uk>
initex/hyphen? sounds ok. but Christina isnt quite right - the *users*
dont see this rubbish anyway, do they?
i still prefer to see separate direcories on CTAN, with the files
linking to a single directory for people buidling a Tedious.
sebastian
================================================================================
Archive-Date: Mon, 24 Oct 1994 12:00:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410241659.RAA20276@spice.iti.informatik.th-darmstadt.de>
Subject: Re: hyphen, still problems
To: TWG-TDS@SHSU.edu
Date: Mon, 24 Oct 1994 17:59:52 +0100 (MEZ)
Content-Type: text
You wrote:
>
> initex/hyphen? sounds ok. but Christina isnt quite right - the *users*
> dont see this rubbish anyway, do they?
Currently, Christine earns her money being sysadmin over a
heterogenous net of 40 Unix workstations. She is my first test person
when I want to see how new ideas arrive at this class of persons. So
`user' should be read as `admin person', actually.
Nevertheless I think that users will see this particular part of
rubbish. A sysadmin will install (and support) FMT files with a
certain set of hyphenation patterns. If some user wants more, she
may like to create her own FMT file and then she has to look what
pattern files are available in that installation.
> i still prefer to see separate direcories on CTAN, with the files
> linking to a single directory for people buidling a Tedious.
No. Either you want the thing you have now (all files in one
directory) or you want seperate directories. Let's ignore the point
that the files may originate from a complete other CTAN part for the
moment.
We have either:
hyphen/ukhyphen.tex
hyphen/README.ghyphen
hyphen/eshyph.tex
hyphen/f8hyph.tex
hyphen/fhyph.mac
hyphen/fhyph.tex
hyphen/fihyph.tex
hyphen/fr8hyph.dc
hyphen/ghyph31.tex
hyphen/czhyph.tex
hyphen/dkhyph.tex
hyphen/ithyph.tex
hyphen/nehyph1.tex
hyphen/nehyph2.tex
hyphen/nehyph3.tex
hyphen/ishyph.tex
hyphen/lahyph.tex
hyphen/nohyph.tex
hyphen/sehypha.tex
hyphen/pohyph.tex
hyphen/tkhyphart.tex
hyphen/turk_hyf.c
hyphen/ushyph1.tex
hyphen/ushyph2.tex
hyphen/pthyph.tex
hyphen/suhyph.tex
hyphen/tkhyph.tex
hyphen/ukhyph.tex
hyphen/ushyph.tex
or
hyphen/turkish/turk_hyf.c
hyphen/turkish/tkhyphart.tex
hyphen/turkish/tkhypha.tex
hyphen/swedish/sehypha.tex
hyphen/spanish/eshyph.tex
hyphen/portuguese/porthyph.tex
hyphen/polish/hyphen.pol
hyphen/norwegian/norhyph.tex
hyphen/norwegian/nohyphen.tex
hyphen/italian/ithyph.tex
hyphen/icelandic/ihyphen.tex
hyphen/german/ghyph31.tex
hyphen/german/README.ghyphen
hyphen/french/fr8hyph.dc
hyphen/french/fhyph.tex
hyphen/french/f8hyph.tex
hyphen/finnish/fihyph.tex
hyphen/english/ushyphen.tex
hyphen/english/ushyph2.tex
hyphen/english/ushyph1.tex
hyphen/english/ukhyphen.tex
hyphen/dutch/nehyph3.tex
hyphen/dutch/nehyph2.tex
hyphen/dutch/nehyph1.tex
hyphen/danish/dkhyphen.tex
hyphen/czech/czhyphen.tex
(The set of files is not necessarily identical, as I have not updated
the respective archive.) If you want to use the second layout,
shorten some directory names and install it on CTAN. Then we'll use
it for the TDS. ;-)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 24 Oct 1994 18:35:05 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 24 Oct 1994 16:34:53 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410242334.QAA28189@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: vojta@math.berkeley.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
I find Paul Vojta's third option fascinating because it is so familiar.
Linking, on systems that allow it, works wonders.
I work on some systems which are so fast that directory searching is no
problem at all. But on others, it is a real pain in the neck. So, every
morning at 4:00 + an arbitrary number of minutes, a crontab kicks in with
a whole series of linke such as
17 4 * * * ( cd /usr/local/lib/texmf/fonts ; /usr/local/bin/link-fonts ./public cx pk 00PK > /tmp/linkings 2>&1 )
00PK 00TFM 00VF and 00XDVI are flat directories full of symbolic links.
link-fonts reads:
#!/bin/sh
#
# This script provides for flat directories organized by function
# as opposed to the organization of fonts by foundry and typeface
# made possible by Karl Berry's kpathsearch. It can also achieve
# a speed-up in the execution of programs like dvips and xdvi
# which depend on kpathsearch. This is often needed with
# old, slow processors or old, slow disk controllers.
#
# A typical directory tree is:
#
# ${TEXFONTS}/
# 00PK/
# 00TFM/
# 00VF/
# 00XDVI/
# adobe/
# utopia/
# afm/
# ps-to-pk/
# src/
# tfm/
# type1/
# vf/
# public/
# cm/
# afm/
# cx/
# ricoh/
# src/
# tfm/
# vf/
#
#
# The 00[TFM,VF,XDVI] directories are flat or "accelerator"
# directories where links to files that are in extremely
# frequent use are placed.
#
# 00PK can also be used as an "accelerator" directory for
# links to frequently used PK files. But don't store write-white
# fonts there unless you are unlucky enough to have a write-white
# printer.
#
# If you want to move the actual font files made
# by MakeTeXPK into the foundry-based tree, select them
# with one or more of the optional predicates in a find command
#
PATH=$1
DIR=$2
FILEXT=$3
WHERE=$4
#
if test "$#" != 4 ;
then
echo " usage: link-fonts <branch> <leaf> <characteristic> <00dir>";
echo " Run this in the common parent TEXFONTS directory";
echo " Where the directories [ 00*] are located ";
echo " <branch> = Relative path to bitmaps. Start with ./";
echo " The closest common path to all desired fonts ";
echo " <leaf> = [ tfm vf type1 cx ricoh ] or similar";
echo " Where the metrics or glyphs are in each branch ";
echo " <characteristic> = [ tfm vf pfa pk ] or similar";
echo " <00dir> = one of [ 00TFM 00VF 00PK 00XDVI ]";
exit 1 ;
fi
#
for i in `/usr/bin/find ${PATH} -name ${DIR} -a -type d -print` ;
do
for j in `/usr/bin/find ${i} -name "*.*${FILEXT}" -print` ;
do
FONT=`/usr/bin/basename $j`
echo $j
(cd ${WHERE} ; /usr/bin/rm -f ${FONT} ; /usr/bin/ln -s .${j} ./${FONT} )
done ;
done
Karl is not enthusiastic about this,because it's messy. That is all
too true, but it is a great way to get performance out of slow messy
machines. On any given day, the full kpathsea is open for any new
addition to the font library, and by the next day the addition is
available in the hurry-up path. ls-R is supposed to do that too, but
PV points out that even ls-R has its price. I much prefer to use
super-fast machines that make pure kpathsea approaches
acceptable---who doesn't---but on a creaky old Sun3-50, this linking
approach gives me the second-best of all possible worlds.
Over and over again we seem to be saying:
"Here is a crummy solution for your hot-shot machine. We realize that it
"is illogical and arbitrary, but se have had to dumb it down to the
"least common capability of the crummiest machines we know about."
What we should be saying is:
"Here is a logical and systematic solution for a more or less ideal
"machine. It may not work on what you have now, but there are ways
"(such as PV's third option) to get around that. As the technology
"improves, you can drop the workarounds and adopt the clean, logical
"solution directly.
Several years ago, Intel had the crummy notion that no one would ever need
to address more than 64K bytes of memory continuously. Motorola
and even that perennial disaster NSC had a better idea, but the
marketing heavyweights put their weight behind the crummy 64K
limitation, and half a dozen other glaring design failures. That
64K nonsense is cast in concrete now, and even when Intel has at last
got past (sort of) the limitation, everyone who uses Intel is still
forced to sacrifice to the 64K god.
The value of PV's option 3 is that it shows how little point there
is in making the same mistake here. Note that the link option gives
the BEST time.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
Archive-Date: Mon, 24 Oct 1994 18:37:41 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 24 Oct 1994 16:37:28 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410242337.QAA28577@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
i see no harm in configuring xdvi to look at a flat directory setup
populated with links to a TDS tree
Hear, Hear.
I see a certain virtue in suggesting good ways to do this, and even
providing the tools for it.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| we will try unofficially to provide some services for the next few |
| months. Unfortunately Elizabeth will not be available by phone, |
| and I cannot be near my phone in any regular sense. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
to: UnixTeX@u.washington.edu Elizabeth Tachikawa
or to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (No call forwarding, no message recorder)
================================================================================
Archive-Date: Mon, 24 Oct 1994 18:43:53 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0qzYK9-0006PYC@rsuna.crn.cogs.susx.ac.uk>
Date: Mon, 24 Oct 94 22:57 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
bcc Damian.Cugley@comlab.oxford.ac.uk
Subject: [Damian.Cugley@comlab.oxford.ac.uk: Comments on TDS 0.49]
Some comments from Damian Cugley on TDS...
--- cut here ---
Chapter 4 says TDS specifies that generic METAFONT files go in
$texmf/tex/mf, whereas in Section 2.1 they are described as going in
$texmf/mf.
The section on subdirectory searching doesn't mention that VMS already
has a syntax for infinite subdirectory searching. It doesn't say if
keeping a database of every file allows for users to add their own
macros directories. (No mention is made anywhere that users might want
to add their own extensions to TeX without having to persuade sysadmins
to do it. There should also be a mechanism for people like me to
prevent the system finding old versions of files in the installed TeX
directory tree when I'm trying to develope new versions.)
The phrase "*user* documentation" is used in the fourth itemized
paragraph in Section 2.1, I guess to distinguish files intended to be
useful to users from those intended to be useful to installers (it was
not obvious from the phrase). But no mention is made of somewhere to
put installation notes (READMEs etc.). Since it is imaginable that more
than one person might be responsible for installing a given TeX system,
it would be a good idea, no?
In the last paragraph of Section 2.1, a "system" name is used to
distinguish directories with binaries for different systems in -- but no
spec is given for "system" names for UNIX TeX compiled for different
platforms; the GNU names (like "sun-sparc-sunos4.1.1") are the only de
facto standard I know of and are not ISO-9660-friendly.
Chapter 3. I'm not sure I like having LaTeX 2e's directory split into
"latex/distrib" and "latex/contrib"; this defeats finite subdirectory
searching and doesn't seem to serve much purpose (unless there are
packages that have both "contrib" and "distrib" versions?). (And using
"latex" instead of "latex2e" raises the issue of whether the "2e" is a
version number or part of the name. Presumably these get renamed
"latex2e" when LaTeX 3 is declared to be the one true LaTeX.)
Chap. 5. How are font family names chosen for existing fonts? The
first par of Section 5.1 has ".../typeface/typeface/...".
Section 5.2, under "dpi" (why isn't that italic?): Which file systems
require that names begin with a letter? (VMS allows zeros, so does
MS-DOS as far as I know. Is it ISO 9660?)
Section 5.2.1 says font files should contain info about resolution and
stuff... what format? How is this info extracted??
Chapter 8 (Packages.) I'm not very happy about being expected to make
subdirs like "Malvern-1.3/fonts/public/malvern/tfm" in Malvern's
tarfiles instead of just "Malvern-1.3/tfm". Since the files will still
have to be copied to under $texmf I can't see that it gains much.
The top-level name for packages, "Malvern-1.3", isn't ISO-9660-friendly;
perhaps the TDS should suggest a way to compress package names into 8
chars (e.g., "malver13"). BTW, it is only this example that we can
infer that package names and font family names do *not* include version
IDs when used as dirnames in TDS (*except* for LaTeX, *except* for the
current version of LaTeX).
I'm not sure I approve of having the "read me" file hidden quite so
thorougly, either. Since packages have to be ISO-9660-friendly and also
workable for MS-DOS/Windows users, perhaps we should settle on
"00readme.txt" as the name for "read me" files? "readme" and "read.me"
will be a pain for Windows File Manager users, whereas ".txt" files can
be read with a double-click... The double-0 prefix is the only way to
put the file at the top of th directory listing. Other installation
files could have single-0 prefix. This assumes at zeros are allowed as
the first character of a file name element.
BTW, the idea of "miscellaneous" is variously expressed as "generic",
"misc", "public" and "general".
================================================================================
Archive-Date: Wed, 26 Oct 1994 04:52:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 1994 05:51:48 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410260951.AA05948@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: [vojta@math.berkeley.edu: Re: TeX directory structures]
i see no harm in configuring xdvi to look at a flat directory setup
populated with links to a TDS tree
Hear, Hear.
I see a certain virtue in suggesting good ways to do this, and even
providing the tools for it.
Pierre, I can't really agree with you here, for a change!
I know why you use your link directories, and of course I think it's
just fine that you've got a working implementation :-) But I would hate
to see such a thing ensconced in a standard.
I see little point in having a TDS at all if it isn't used for
actual file searches. If everyone just creates links in flat
directories, we will have achieved nothing. (In fact, we'll have made
the situation worse, since then there would be another layer of confusion.)
This question is really the crux of the whole TDS issue -- whether there
will be subdirectories. As we started from, long long ago.
================================================================================
Archive-Date: Wed, 26 Oct 1994 04:52:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 1994 05:51:48 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410260951.AA05956@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: Damian.Cugley@comlab.ox.ac.uk
Subject: damian's tds comments
These are good comments.
There should also be a mechanism for people like me to
prevent the system finding old versions of files in the installed TeX
directory tree when I'm trying to develope new versions.)
Put only your directories in the paths?
Chapter 3. I'm not sure I like having LaTeX 2e's directory split into
"latex/distrib" and "latex/contrib"; this defeats finite subdirectory
The latex folks don't want to change. So far as I know.
Chap. 5. How are font family names chosen for existing fonts?
They look at my list? fontname 2.0 will have this in machine-readable form.
Which file systems require that names begin with a letter? (VMS
allows zeros, so does MS-DOS as far as I know. Is it ISO 9660?)
Someone early on -- Norm, I think -- said ISO-9960 is
beginning-with-a-letter only.
Section 5.2.1 says font files should contain info about resolution and
stuff... what format? How is this info extracted??
For Metafont fonts, you get it automatically if you use modes.mf.
The idea is just to include specials like
mode=cx
dpi=600
in the GF/PK file.
modes.mf has the particulars.
As for how it's extracted, they are just specials like others. They're
not used by any program, so far as I know, but they are sometimes
helpful when you're trying to track down the origin/meaning of a given
PK file that has popped up.
Chapter 8 (Packages.) I'm not very happy about being expected to make
subdirs like "Malvern-1.3/fonts/public/malvern/tfm" in Malvern's
tarfiles instead of just "Malvern-1.3/tfm". Since the files will still
have to be copied to under $texmf I can't see that it gains much.
The idea is that then installation becomes very simple:
cd Malvern-1.3; cp -r fonts tex ... $texmf
If the distribution flattens the tree, an installation script or
something has to expand it again.
Whether or not the subdirectory trees will make it into the final tds, I
don't know, but the basic idea of making the installer's job simple
seems a good one.
The other win of having a TDS structure in the distribution is that
conceivably people could experiment with having *packages* under texmf,
instead of file types. We had a long debate about this. If you're really
interested, it's in the archives.
The top-level name for packages, "Malvern-1.3", isn't ISO-9660-friendly;
Doesn't matter, because Malvern-1.3/ isn't going to be a name on
anyone's CD-ROM or in the tds tree. Keep that name for what your tar
file unpacks into.
perhaps the TDS should suggest a way to compress package names into 8
chars (e.g., "malver13").
I don't think it needs to. Top-level distribution names in tar files can
continue to be meaningful, not DOS-ified. At least I haven't heard any
convincing arguments to the contrary.
BTW, it is only this example that we can
infer that package names and font family names do *not* include version
IDs when used as dirnames in TDS
That should be said, I suppose.
(*except* for LaTeX, *except* for the
current version of LaTeX).
LaTeX is the only case -- isn't it? -- where a significant number of
people, right here and right now, want to support two different versions
simultaneously. Thus it is a special case.
At least that's the claim. I don't know what the reality is. I
personally wouldn't mind if the whole latex2e vs. latex209 thing went
away, and the TDS just had `latex', like everything else.
perhaps we should settle on "00readme.txt" as the name for "read me"
files?
I can buy this argument for monocase filesystems. For distributions like
tar files, I just can't bring myself to mangle filenames that badly.
================================================================================
Archive-Date: Wed, 26 Oct 1994 06:29:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 94 11:27:13 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410261127.AA02142@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: Damian.Cugley@comlab.ox.ac.uk
Subject: Re: damian's tds comments
> Chapter 3. I'm not sure I like having LaTeX 2e's directory split into
> "latex/distrib" and "latex/contrib"; this defeats finite subdirectory
> The latex folks don't want to change. So far as I know.
Actually I think it was mainly `me' rather than `the latex folks'.
Looking at how I've set this up locally I notice that I havent followed
my own suggestion.
Since I made the suggestion for the split we have changed latexbug.tex
to prompt people which `category' (aka ctan directory) the bug report
is for. The list of supported directories is now made explicit by
latexbug, like this:
Several categories of files are supported,
corresponding to directories in the standard LaTeX distribution:
0) base: The format itself, and the main classes such as `article'.
1) tools: Packages supported by the LaTeX3 project team.
2) graphics: The color and graphics packages.
3) mfnfss: Packages for using MetaFont fonts with NFSS (ie LaTeX2e).
4) psnfss: Packages for using PostScript fonts with NFSS (ie LaTeX2e).
5) amslatex: Classes and Packages supported by the AMS.
6) babel: Packages supporting many different languages.
Please select a category 0--6:
So there is now less need to make it clear which directories are
`supported' by us using the TDS tree.
So personally I would remove my objection to
...latex/base % supported by us
...latex/tools % supported by us
...latex/amslatex % supported by us/AMS
...latex/seminar % supported by Tim Van Zant
etc
Alan?
================================================================================
Archive-Date: Wed, 26 Oct 1994 07:53:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 94 12:53:35 GMT
From: Damian.Cugley@comlab.oxford.ac.uk
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410261253.AA02904@boothp1.ecs.ox.ac.uk>
To: TWG-TDS@SHSU.edu, kb@cs.umb.edu
Subject: Re: damian's tds comments
CC: Damian.Cugley@comlab.oxford.ac.uk
>> Which file systems require that names begin with a letter? (VMS
>> allows zeros, so does MS-DOS as far as I know. Is it ISO 9660?)
> Someone early on -- Norm, I think -- said ISO-9960 is
> beginning-with-a-letter only.
This would be very unfortunate. Without the "00" prefix there is no way
to make a "read me" file go near the top of the directory listing short
of calling it "aaron.txt" or something...
I haven't got a copy of ISO 9660, but here's what the CD-ROM FAQ says:
# Level one ISO-9660 is similar to an MS-DOS filesystem. Filenames are
# limited to eight single-case characters, a dot, and a three character
# extension. Only single case letters, numbers, and
# underscores. Directory names cannot have the three digit extension,
# just eight single-case characters.
# [...]
This doesn't explicitly state that digits are OK as the first character
but I'd expect it to say if they were not. So I poked around the
ftp.cdrom.com archive, and their CD-ROMs *do* use names like
"00_INDEX.TXT" and "00_CAT_0.TXT".
> LaTeX is the only case -- isn't it? -- where a significant number of
> people, right here and right now, want to support two different versions
> simultaneously. Thus it is a special case.
Yes, this makes sense.
I would have expected to see the LaTeX 2e directories called
"latex2e/*trib", since (I'm told) the "2e" in "LaTeX 2e" is *not* a
version number (!). Also, when LaTeX 3 is installed as, old LaTeX 2e
files would not need renaming.
================================================================================
Archive-Date: Wed, 26 Oct 1994 09:29:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 94 13:59:46 GMT
From: Damian.Cugley@comlab.oxford.ac.uk
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410261359.AA02946@boothp1.ecs.ox.ac.uk>
To: TWG-TDS@SHSU.edu, kb@cs.umb.edu
Subject: Re: damian's tds comments
CC: Damian.Cugley@comlab.oxford.ac.uk
>> Which file systems require that names begin with a letter? (VMS
>> allows zeros, so does MS-DOS as far as I know. Is it ISO 9660?)
> Someone early on said ISO-9960 is beginning-with-a-letter only.
This would be very unfortunate. Without the "00" prefix there is no way
to make a "read me" file go near the top of the directory listing short
of calling it "aaron.txt" or something...
I haven't got a copy of ISO 9660, but here's some of what the CD-ROM FAQ
says:
# Level one ISO-9660 is similar to an MS-DOS filesystem. Filenames are
# limited to eight single-case characters, a dot, and a three character
# extension. Only single case letters, numbers, and
# underscores. Directory names cannot have the three digit extension,
# just eight single-case characters.
# [...]
This doesn't explicitly state that digits are OK as the first character
but I'd expect it to say if they were not. So I poked around the
ftp.cdrom.com archive, and their CD-ROM file lists include names like
"00_INDEX.TXT" and "00_CAT_0.TXT". So it looks like ISO 9660 does allow
leading digits.
Is there some other modern file system that specifies file name
components must start with a letter?
--
P. Damian Cugley * * * * * * * * * * * * * * * <damian.cugley@comlab.ox.ac.uk>
Oxford University Computing Laboratory, Parks Road, Oxford OX1 3QD, UK
Alleged Literature, c/o Damian Cugley, 255B Banbury Road, Oxford OX2 7HN, UK
http://boothp1.ecs.ox.ac.uk:5705/people/pdc.html * My other computer is a Linux
================================================================================
Archive-Date: Wed, 26 Oct 1994 09:35:56 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0r09NC-00006xC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 26 Oct 94 14:30 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, Damian.Cugley@comlab.ox.ac.uk
Subject: Re: damian's tds comments
>So personally I would remove my objection to
>...latex/base % supported by us
>...latex/tools % supported by us
>...latex/amslatex % supported by us/AMS
>...latex/seminar % supported by Tim Van Zant
>etc
>Alan?
Fine by me.
Alan.
================================================================================
Archive-Date: Wed, 26 Oct 1994 09:40:09 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0r09Up-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 26 Oct 94 14:38 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, Damian.Cugley@comlab.ox.ac.uk
Subject: Re: damian's tds comments
> Chapter 8 (Packages.) I'm not very happy about being expected to make
> subdirs like "Malvern-1.3/fonts/public/malvern/tfm" in Malvern's
> tarfiles instead of just "Malvern-1.3/tfm". Since the files will still
> have to be copied to under $texmf I can't see that it gains much.
One of the possibilities is that on CTAN, Malvern will have tfm/
latex/ fd/ etc. directories plus some mechanism for saying where these
live in TDS. Then CTAN provides a new extension (say tds.tar) so
that when I get malvern.tds.tar I get a tar file which I can unpack
with:
cd $TEXMF
tar -xvf malvern.tds.tar
and everything will go in the right place. Of course this may just be
a pipe dream...
>At least that's the claim. I don't know what the reality is.
The reality is that at almost every meeting the L3 team goes to, one
of the first questions to be asked is `can I run 2e and 2.09 in
parallel'.
Alan.
================================================================================
Archive-Date: Wed, 26 Oct 1994 11:45:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 94 09:42:20 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410261642.AA17144@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: 0.doc, etc.
> Someone early on -- Norm, I think -- said ISO-9960 is
> beginning-with-a-letter only.
Many of PTF's discs contain files named 0.doc, 0.lst, etc. The only
problem we have had with this is that one set of mastering software
could not deal with it. The vendor acknowledged that this was a bug.
-r
================================================================================
Archive-Date: Wed, 26 Oct 1994 11:51:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 94 16:50:29 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9410261650.AA02487@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: Damian.Cugley@comlab.ox.ac.uk
Subject: Re: 0.doc, etc.
[Norm, are you around?]
> Many of PTF's discs contain files named 0.doc, 0.lst, etc. The only
> problem we have had with this is that one set of mastering software
> could not deal with it. The vendor acknowledged that this was a bug.
Norm's original comment on this was that *Directories* could not begin
with a digit, hence dp1300 but presumably *files* like 00readme.txt
are OK.
Presumably the documentation for this exists somewhere...
David
================================================================================
Archive-Date: Wed, 26 Oct 1994 12:01:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 26 Oct 1994 12:58:09 -0400
From: norm@ora.com (Norman Walsh)
Message-ID: <199410261658.MAA18670@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.doc, etc.
References: <9410261642.AA17144@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 26 October 1994 at 09:42:20, Rich Morin wrote:
>
> > Someone early on -- Norm, I think -- said ISO-9960 is
> > beginning-with-a-letter only.
>
> Many of PTF's discs contain files named 0.doc, 0.lst, etc. The only
> problem we have had with this is that one set of mastering software
> could not deal with it. The vendor acknowledged that this was a bug.
My error, I guess. Maybe the guy who masters for us had that version
of the mastering software ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | In science, "fact" can only mean "confirmed to
Production Tools Specialist | such a degree that it would be perverse to
O'Reilly & Associates, Inc. | withhold provisional assent." I suppose that
90 Sherman Street | apples might start to rise tomorrow, but the
Cambridge, MA 02140 | possibility does not merit equal time in physics
(617) 354-5800/661-1116 FAX | classrooms. -- Stephen J. Gould
================================================================================
Archive-Date: Fri, 28 Oct 1994 12:07:58 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410281706.SAA14341@spice.iti.informatik.th-darmstadt.de>
Subject: More on Damian's TDS comments
To: Damian.Cugley@comlab.ox.ac.uk
Date: Fri, 28 Oct 1994 18:06:28 +0100 (MEZ)
CC: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Content-Type: text
Damian wrote:
>
> BTW, the idea of "miscellaneous" is variously expressed as "generic",
> "misc", "public" and "general".
Actually, it isn't.
generic -- stuff that works with all TeX macro formats
public -- vendor of freely distributable fonts
misc -- directory for single file distributions
general -- documentation that does not concern one specific
system;
I don't want to defend the last one, as I think it's unnecessary;
`misc' is clearly the one you mentioned; but let's look at the first
two items. I consider neither `generic' nor `public' as
``miscellaneous'', but rather as very specific terms. The files
therein are not `the rest where we couldn't find or make a category
for', as it is with files in misc/.
We had already discussions about these two names. Do you have any
idea about other names that convey the information mentioned above?
(Of course, the names have to restricted to 8 letters, due to @$#!%
ISO-9660.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 28 Oct 1994 13:52:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 28 Oct 1994 14:51:59 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410281851.AA17333@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: fonts/public
public -- vendor of freely distributable fonts
Alan et al. convinced me long ago that this was not a good name, because
the idea behind that directory is really `fonts created/distributed by
people/organizations who only have a few', not `freely distributable'.
Copying conditions should be irrelevant to the directory names; it is
just chance that all the fonts in public/ are also free.
My only argument for having ams/ as a separate source is that the
amsfonts is a well-separated distribution that is being maintained. And
there are half-a-dozen or so typefaces, so ...
Whether Knuth or Yannis or Damian or Texplorators or whoever should get
their own directory is something I don't feel too strongly about. I
don't see much point to proliferating source directories unnecessarily,
but on the other hand it doesn't make any difference to me.
However, much more important than precisely what source directories will
be under fonts/ (at whatever level) is whether
(a) we're going to require subdirectory searching at all; and if so,
(b) whether fonts/type/source/typeface/dpiNNN/*.type got agreed on, or
if the debate is continuing.
There is no point in discussing (b) until (a) is resolved -- and so far
as I can see, saying `no subdirectory searching' is the only way to
guarantee compatibility with existing implementations and reasonable
startup time (except, perhaps, on VMS).
Watch out. I just had an idea.
It's not subdirectory searching per se that matters. It's being able to
find fonts in the tree. What about these wonderful %-specifiers that
some implementations (xdvi, dvips, mctex, emtex?, ...?) already do?
Wouldn't that be a more efficient (not to mention politically
acceptable) way of finding fonts in a deep tree than the horrendous mess
I've gotten myself into with ls-R, etc.? (I'm exaggerating for effect.)
So how about a path specification like this (illustrative purposes only, not
trying to suggest syntax):
PKFONTS = $TEXMF/fonts/%s/%t/dpi%d/%f.pk
Well ... the crux of the matter is the %s to get the source name and the
%t to get the typeface name (cm, etc.). The only way I can see do that
is to use a separate mapping file (which I've already constructed).
(If you're willing to require one-level subdirectory searching, the %s
could become * or whatever.)
I should say I'm not trying to suggest the TDS would specify this (or
any other searching method). We would just specify how the tree looks,
as usual. I'm only bringing this up because people are (entirely
reasonably) objecting to the subdirectories based on current
implementations -- so here's another search method.
Does this help anything?
Karl, making one last try at saving fonts/source ...
================================================================================
Archive-Date: Fri, 28 Oct 1994 18:23:44 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0r10ch-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 28 Oct 94 23:22 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: fonts/public
> public -- vendor of freely distributable fonts
>Alan et al. convinced me long ago that this was not a good name, because
>the idea behind that directory is really `fonts created/distributed by
>people/organizations who only have a few', not `freely distributable'.
>Copying conditions should be irrelevant to the directory names; it is
>just chance that all the fonts in public/ are also free.
Yes, I'll say it again, organizing fonts by cost is not the most
logical arrangement. Lets have the big font distributors (Adobe,
Linotype, Monotype) plus the big font developers for TeX (AMS, DEK)
and perhaps a few others, and bung everything else under misc.
Alan.
================================================================================
Archive-Date: Fri, 28 Oct 1994 19:32:00 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 28 Oct 1994 17:31:54 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410290031.RAA23679@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: fonts/public
I guess I always tacitly assumed that public was short for
public domain. Which isn't exactly true in the case
of fonts licensed under GNU Copyleft, but near enough.
The practical division is not clean, because you could
argue that adobe, bitstream, IBM and urw have made a selection
of fonts (utopia---part, charter, courier, nimbus/times etc.)
effectively public domain, though they retain licenses in the
comments at the head of the files.
But we have been using p
But we have been using public/ to indicate fonts that it is
always safe to pass on with no explicit concern for licensing,
and even though this can be done for part of adobe courier,
(sorry, I mean Adobe utopia) it remains that most of what
comes under adobe is subject to licensing. Nothing that
I ever consider putting under public/ is subject to
licensing except for a couple of cases where licenses are
required for *commercial* profit-making use.
When does a font developer become a BIG developer. Where
for instance does N. Billawala fit? Where does Tom Ridgeway
fit. Is Klaus Lagally a misc, or a BIG developer?
and if he is a BIG developer, is he "arabtex" or "lagally?"
It isn't cost which drove the development of the present
ad-hoc division, it is the question of licensing restrictions.
THe division isn't ruthlessly logical, but it is sort of
understandable.
Pierre
================================================================================
Archive-Date: Fri, 28 Oct 1994 19:42:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 28 Oct 1994 20:41:54 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410290041.AA20530@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: fonts/public
But we have been using public/ to indicate fonts that it is
always safe to pass on with no explicit concern for licensing,
That's a good point. I hadn't thought about that as an advantage of
`public' :-) That is actually of some value.
It's ok with me to put everything under `public' -- there just aren't
that many freely available typefaces out there that the directory would
get huge.
When does a font developer become a BIG developer. Where
Well, if we do adopt this, something like
more than half a dozen typefaces or so?
I don't think we need to make a hard-and-fast rule.
Just categorize everything on CTAN now, and let it go at that.
What happens in the future will follow along.
for instance does N. Billawala fit?
Since she's only got one, pandora/ will be under misc/ no matter what.
Where does Tom Ridgeway
fit. Is Klaus Lagally a misc, or a BIG developer?
and if he is a BIG developer, is he "arabtex" or "lagally?"
Don't know these ...
Which isn't exactly true in the case
of fonts licensed under GNU Copyleft, but near enough.
I don't think there are any copylefted fonts. Are there?
================================================================================
Archive-Date: Sun, 30 Oct 1994 02:19:41 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410292018.VAA14820@spock.iti.informatik.th-darmstadt.de>
Subject: Re: fonts/public
To: TWG-TDS@SHSU.edu
Date: Sat, 29 Oct 1994 21:18:49 +0100 (MEZ)
Content-Type: text
Karl wrote:
>
> public -- vendor of freely distributable fonts
>
> Alan et al. convinced me long ago that this was not a good name, because
> the idea behind that directory is really `fonts created/distributed by
> people/organizations who only have a few', not `freely distributable'.
> Copying conditions should be irrelevant to the directory names; it is
> just chance that all the fonts in public/ are also free.
Oh yes, I remember. Then Damian was right: it's misc/. Let's give DEK
his own directory, to escape those TPC discussions, and rename public/
to misc/.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Sun, 30 Oct 1994 03:19:49 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199410292016.VAA14808@spock.iti.informatik.th-darmstadt.de>
Subject: Re: fonts/public
To: TWG-TDS@SHSU.edu
Date: Sat, 29 Oct 1994 21:16:18 +0100 (MEZ)
Content-Type: text
Karl made
>
> one last try at saving fonts/source ...
that I applaude wholeheartly.
> So how about a path specification like this (illustrative purposes only, not
> trying to suggest syntax):
> PKFONTS = $TEXMF/fonts/%s/%t/dpi%d/%f.pk
If anybody wants C routines that support the specification above, I
will supply it immediately. An excerpt from the header file is below.
The routines are tested, they are actually in use at thousands of
sites that use our software.
Actually, Karl's got a very good point: You do *not* need full
subdirectory searching for the fonts/source layout if you use the TDS
layout, as you know *exactly* where <type> directories could be.
The discussion is open again... :-)
Joachim, TeX anarchist
----------------
FYI, the declarations of the functions mentioned above. The `funny'
names EXTERN_C etc. are introduced to be able to use such
declarations with ANSI C, K&R C, and C++ compilers. Their actual
definition should be obvious to any C programmer...
EXTERN_C C_String xstr_expand PROTO(( Const_string s ));
/*
* Input: s --- string which shall be expanded
* Returns: New string with all expansions done.
* The new string is malloc() compatible.
* This function does not return if not enough memory is available.
* Then an fatal error message is issued via fatal_msg().
* Description: Substrings of 's' which have the form $name or ${name}
* are substituted by the value of the environment
* variable with the respective name. `name' consists of
* letters, digits, and underscores. If it is written in
* the first form (ie, without surrounding braces), the
* first non-letter, non-digit, or non-underscore
* terminates the name.
*/
EXTERN_C C_String xstr_format_expand PROTO((
Const_string format,
Const_string varinfo,
Const_string *param ));
/*
* Input: format -- a printf-like format string
* varinfo -- a string with one expansion character for each
* element in param
* param -- a vector of parameters to substitute
* Returns: a new string with all expansions done.
* The new string is malloc() compatible.
* This function does not return if not enough memory is available.
* Then an fatal error message is issued via fatal_msg().
* Description: Every `%'c sequence in `format' is replaced by the i'th element
* of `param', if `c' is the i'th element in `varinfo' or with a
* single `%' character if `c' equals `%'.
* An error message is issued via err_msg(), if `c' is not
* contained within `varinfo'.
*/
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
Archive-Date: Thu, 03 Nov 1994 13:44:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 3 Nov 94 18:00:55 GMT
From: Damian.Cugley@comlab.oxford.ac.uk
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9411031800.AA08367@booth5.ecs.ox.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: TDS / Packages (Re: damian's tds comments)
CC: Damian.Cugley@comlab.oxford.ac.uk
(Hope you don't mind my posting to this list again.) In my comments on
TDS draft 0.49 which Alan forwarded to the list, I said
> Chapter 8 (Packages.) I'm not very happy about being expected to make
> subdirs like "Malvern-1.3/fonts/public/malvern/tfm" in Malvern's
> tarfiles instead of just "Malvern-1.3/tfm".
I'm beginning to be persuaded that TDS-styloe subdirs in the package
tarfile makes some sense. one of the packages I was thinking of making
was one called "narrowtt" that would have narrow versions of Computer
Modern TT and Courier; a TDS-like directory structure would make it
easier for installers to select which components of this package to
install.
I don't like deep directory structures because they make it hard to find
files when browsing through them (consider someone using an FTP
front-end or WWW browser, where you can only "move" one directory at a
time). I mention this because it occurs to me that if you put fonts in
a little-endian directory tree *and* use names "mf" and "pl" for
METAFONT and PL sources, then the "fonts" name element becomes
redundant. You could have names like
$texmf/tfm/malvern/ma55a10.tfm
$texmf/mf/malvern/ma55a10.mf
etc.
This is consistent with the "tex" and exiting "mf" directory; the
general rule is that files of type TYPE go in "$texmf/TYPE".
To find all TeX font packages installed, you do "ls $texmf/tfm" (or "DIR
$TEXMF\TFM" etc.).
I was thinking about the "SOURCE/TYPEFACE" directory names for fonts in
the context of these narrowtt fonts. Would a set of "crrrn" (Courier
Narrow) fonts go in "adobe/courier"? What if some other person comes up
with a different "Courier Narrow" of his or her own?
It might make sense to instead talk of "$texmf/tfm/PACKAGE/foo.tfm",
where PACKAGE is a package name (for fonts distributed as a package) or
is "SOURCE/FAMILY" for commerical fonts. Then I might have
(hypothetically)
$texmf/tfm/narrowtt/ct57ah10.tfm
$texmf/tfm/narrowtt/pcrrrn.tfm
etc.
Finally, Malvern and Fontinst both include "contrib" directories, where
files relevant to the package contributed by oither people go. Will TDS
have an official policy on where these "optional" directories get installed?
--
P. Damian Cugley * * * * * * * * * * * * * * * <damian.cugley@comlab.ox.ac.uk>
Oxford University Computing Laboratory, Parks Road, Oxford OX1 3QD, UK
Alleged Literature, c/o Damian Cugley, 255B Banbury Road, Oxford OX2 7HN, UK
http://boothp1.ecs.ox.ac.uk:5705/people/pdc.html * My other computer is a Linux
================================================================================
Archive-Date: Fri, 04 Nov 1994 12:06:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 4 Nov 1994 13:02:53 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199411041802.NAA24025@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Going away...
Reply-To: TWG-TDS@SHSU.edu
Folks,
I'm going away to SGML'94 next week. I have the draft, a portable,
and all the messages since September with me and I *really* hope to
have a new draft done when I return.
Thanks for your patience everyone...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | The new Congressmen say they're going to turn
Production Tools Specialist | the government around. I hope I don't get run
O'Reilly & Associates, Inc. | over again.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Fri, 18 Nov 1994 12:57:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 18 Nov 1994 13:53:52 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199411181853.NAA02169@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: New draft available...
Reply-To: TWG-TDS@SHSU.edu
ftp://jasper.ora.com/ftp/private/*
You only need twg-tds.*, but I also made the SGML files available again...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | A successful tool is one that was used to do
Production Tools Specialist | something undreamed of by its author. -- S. C.
O'Reilly & Associates, Inc. | Johnson
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Fri, 18 Nov 1994 13:23:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 18 Nov 1994 14:19:35 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199411181919.OAA02288@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: New draft available...
References: <199411181853.NAA02169@jasper.ora.com>
Reply-To: TWG-TDS@SHSU.edu
On 18 November 1994 at 13:53:52, Norman Walsh wrote:
> ftp://jasper.ora.com/ftp/private/*
I goofed, it's in
ftp://jasper.ora.com/ftp/private/twg-tds/*
^^^^^^^
Sorry for the confusion...
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Nothing is so smiple that it can't get screwed
Production Tools Specialist | up.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Fri, 18 Nov 1994 14:31:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 18 Nov 1994 15:27:45 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199411182027.PAA02731@jasper.ora.com>
To: twg-tds@shsu.edu
CC: mackay@cs.washington.edu (Pierre MacKay)
Subject: Re: New draft
References: <199411182025.MAA06026@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 18 November 1994 at 12:25:48, Pierre MacKay wrote:
>
> Is ./texmf/tex/mf really what we have
> decided on for miscellaneous non-font mf files?
> (It doesn't matter all that much, but I wondered whether it was a
> typo)
Looks like a typo to me. I meant /texmf/mf
I should point out: I did all this work on a portable where I couldn't
see the results of what I was doing so there may be similar problems
in other places.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Fri, 18 Nov 1994 14:32:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 18 Nov 1994 15:28:46 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199411182028.PAA02743@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Joachim's proposal for fonts/source...
Reply-To: TWG-TDS@SHSU.edu
I don't recall anyone commenting on Joachim's proposal that fonts/source
would work because the paths below fonts/source could be easily constructed
by substitution.
Does anyone have any comments?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Fri, 18 Nov 1994 14:48:36 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 18 Nov 1994 12:48:40 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411182048.MAA08572@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: Joachim's proposal for fonts/source...
I'll have to check back on what Joachim proposed, but I am, as always,
extremely eager to preserve fonts/source if at all possible.
I think we will have to offer rather more on the doc/<caategory>
tree. I am not absolutely sure I understand it as it stands,
and the martian example does not appear to conform unless martian
is both a category and a package.
Shouldn't it be:
martian-1.0/doc/latex/martian/martdoc.tex
/example.tex
with the possible addition of:
martian-1.0/doc/ps/martian/martdoc.ps % for people who want to read it FIRST
Should there be also:
martian-1.0/doc/readme/martian/read.me
or should we assume that read-me files are throwaways?
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| I will continue unofficially to provide tape distributions and |
| any other services I can. Although I cannot be near my phone on any |
| regular schedule, I now have an answering machine. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder now available)
================================================================================
Archive-Date: Fri, 18 Nov 1994 14:48:38 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 18 Nov 1994 12:48:40 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411182048.MAA08572@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: Joachim's proposal for fonts/source...
I'll have to check back on what Joachim proposed, but I am, as always,
extremely eager to preserve fonts/source if at all possible.
I think we will have to offer rather more on the doc/<caategory>
tree. I am not absolutely sure I understand it as it stands,
and the martian example does not appear to conform unless martian
is both a category and a package.
Shouldn't it be:
martian-1.0/doc/latex/martian/martdoc.tex
/example.tex
with the possible addition of:
martian-1.0/doc/ps/martian/martdoc.ps % for people who want to read it FIRST
Should there be also:
martian-1.0/doc/readme/martian/read.me
or should we assume that read-me files are throwaways?
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| I will continue unofficially to provide tape distributions and |
| any other services I can. Although I cannot be near my phone on any |
| regular schedule, I now have an answering machine. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder now available)
================================================================================
Archive-Date: Fri, 18 Nov 1994 15:04:42 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0r8aPw-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 18 Nov 94 21:00 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: Joachim's proposal for fonts/source...
>I don't recall anyone commenting on Joachim's proposal that fonts/source
>would work because the paths below fonts/source could be easily constructed
>by substitution.
Easy if you have a reverse look-up table that tells you that
to find ma55a10.tfm you should look in misc/malvern/tfm. Unless we're
going to mandate that fonts have to be named according to KB's scheme
(which will not win us friends) such a look-up table is effectively a
hash/ls-r/cache/etc.etc.etc.
Alan.
================================================================================
Archive-Date: Mon, 21 Nov 1994 06:08:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 21 Nov 94 12:07:55 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9411211207.AA10526@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: New draft available...
<title>A Directory Structure for Implementation-Independent
&TeX; Files<?lb>Version 0.50</>
Months of discussion and we are still only half way there....
<para>
To avoid different implementations having different syntaxes for
specifying recursive subdirectory searching, the TWG recommends
that subdirectory searching be specified by a doubled
directory separator. For example, the &unix;-style pathname
There was some debate as to whether this was desirable or possible on
all systems, and in any case I can not see any large advantages in
having this standardised across systems, as the rest of the directory
syntax is not standard across different OS. Perhaps instead say:
<para>
One possible syntax for specification of recursive directory
searching is by a doubled
directory separator. For example, the &unix;-style pathname
In addition, filenames may only contain letters,
digits and underscores and must begin with a letter.
Directory names may not have extensions.
</para>
There was some discussion as to whether this `begin with letter'
constraint is really in ISO 9660. Does anyone have any real
documentation on this?
<para>
The &tds; is rooted at a directory called <filename role=dir>texmf</>.
The location of
this directory within the file system is up to the installer. On
many systems, this may be at the root of the filesystem; however, on
&unix; systems, this would traditionally be located in
<filename role=dir>/usr/local</>. On PC networks, this could map to a
logical drive specification, for example <filename role=drive>T:</>.
</para>
I am not sure that this captures what I (thought) was decided.
In particular the two cited examples are rather different, I think
that the suggestions are
/usr/local/texmf/
t:/
but I would read the above paragraph as suggesting
/usr/local/texmf/
t:/texmf/
Perhaps something like
<para>
The root of the &tds; should be a directory only containing &TeX;
related material. In this document we shall assume that this directory
is called called <filename role=dir>texmf</>, although the exact name
of the directory is up to the installer. On PC networks, this could
map to a logical drive specification, for example
<filename role=drive>T:</>.
</para>
<para>
Similarly the location of
this directory within the file system is site-dependant. On
many systems, this may be at the root of the filesystem; however, on
&unix; systems, this would traditionally be located in
<filename role=dir>/usr/local</>.
</para>
... or something...:-)
Fonts Chapter.
There is no `is there a Better Way?' section here, ie all mention of
our discussions over fonts/type fonts/source has been deleted.
I know this is difficult to phrase, and I objected to the last draft which
tried to summarise both sides of the discussion, but I do think it
should say something (not sure what...)
David
================================================================================
Archive-Date: Mon, 21 Nov 1994 12:09:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 21 Nov 94 09:06:45 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9411211706.AA12923@cfcl.com>
To: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: Re: New draft available...
I'm working on finding a relatively definitive statement on ISO-9660 file
naming. At this point, all I can say is that *I've* used files like 0.doc,
and that when we encountered some pre-mastering software that couldn't
handle them, the vendor fixed it!
I'm a bit confused by the "syntaxes for specifying recursive subdirectory
searching". It appears to me that there are three rough possibilities here:
1. Allow each implementation to go its own way.
This way lies madness!!!
2. Standardize by OS (i.e., one standard syntax for each target OS).
In this scenario, UNIX uses "/a/b//" while MS-DOS uses "c:\a\b\\".
Note that the fact that both OS's use a doubled separator is just
a mnemonic aid here; the UNIX syntax is still incompatible with
the DOS syntax.
3. Standardize across all target OS's.
Pick some syntax that can be translated to every OS now existing.
Hope that all future cases can be handles, as well. Ask the folks
writing the implementations to accept and translate as needed.
My reaction to all this is that (2) is probably OK, and that the use of
a doubled separator is a nicety, but not a necessity. In particular, if
the doubled separator would cause confusion on a given OS, it should be
punted in favor of some other syntax.
Option (3) seems fraught with peril, and I'm not sure how necessary it is.
That is, I don't think these path specification are supposed to go into
TeX files, so it isn't really a portability issue. Is this correct?
The cost of symbolic links in UNIX is not "negligable". Each link takes
up a disk block (typically 1 KB). If we're talking about thousands of
files, this can add up. Also, traversing a symbolic link takes some time.
I don't see either of these points as crippling, but they deserve noting.
BTW, UNIX also allows the use of "hard links" within a given file system
(disk partition, roughly). These ARE essentially free to use.
-r
================================================================================
Archive-Date: Mon, 21 Nov 1994 15:02:25 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0r9fqE-00007DC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 21 Nov 94 21:00 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: Re: New draft available...
> 1. Allow each implementation to go its own way.
> This way lies madness!!!
This way seems the only way to go... I don't think it's our job to say
how implementors should implement configurations. I see no way of
getting OzTeX and Textures (for example) to agree on a way of
specifying directories, the two programs are just too different. I
don't see what the gain is in specifying how configuration should be
done, and I can see problems.
Alan.
================================================================================
Archive-Date: Tue, 22 Nov 1994 11:49:25 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 22 Nov 1994 09:49:28 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411221749.JAA03498@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TAG@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
In hopes that we can hurry along the development of a usable
basic TEXMF tree, I have run the UnixTeX texmf/ listing through
some scripts to identify 8+3 problems. I have already changed
the files that are directoy under my control, (it is extremely
annoying not to be able to refer to TeX3.1415), and here is the
residuum. I could take arbitrary action, but I don't want to.
I want to have the texmf part of the UnixTeX files as close as
possible to the TDS. (I am not even going to look at the rest
of the UnixTeX files. Only the texmf tree.)
./texmf/tex/latex/packages/babel/babel-new.tex HYPHEN,TOOLONG
./texmf/tex/latex/packages/babel/tb-article.tex HYPHEN,TOOLONG
./texmf/tex/latex/packages/tools/afterpage.dtx TOOLONG
./texmf/tex/latex/packages/tools/enumerate.dtx TOOLONG
./texmf/tex/latex/packages/tools/indentfirst.dtx TOOLONG
./texmf/tex/latex/packages/tools/longtable.dtx TOOLONG
./texmf/tex/latex/contrib/supported/epsfig/README.unix TOOLONG DIR&SUFFIX
./texmf/tex/latex/contrib/supported/mflogo/mflogo.readme TOOLONG DIR&SUFFIX
./texmf/tex/latex/contrib/supported/ssqquote/ssqquote.readme TOOLONG DIR&SUFFIX
./texmf/tex/latex/contrib/supported/subeqnarray/subeqnarray.dtx TOOLONG DIR&NAME
./texmf/tex/latex/contrib/supported/subeqnarray/subeqnarray.ins TOOLONG DIR&NAME
./texmf/tex/latex/misc/doublespace.sty TOOLONG
./texmf/tex/latex/misc/doublespace2.sty TOOLONG
./texmf/tex/latex/misc/nopagenumbers.sty TOOLONG
./texmf/tex/latex/misc/supertabular.doc TOOLONG
./texmf/tex/latex/misc/supertabular.sty TOOLONG
./texmf/tex/latex/misc/supertabular.tex TOOLONG
./texmf/tex/plain/fontchart.tex TOOLONG
./texmf/tex/tugboat/germanhyph.tex TOOLONG
./texmf/tex/tugboat/landscape.sty TOOLONG
./texmf/fonts/public/pandora/src/panaccent.mf TOOLONG
./texmf/fonts/public/pandora/src/pangreeku.mf TOOLONG
./texmf/fonts/public/pandora/src/panlowers.mf TOOLONG
For pandora, I suggest panacc.mf, pangrk.mf and panlwr.mf (or even panlower.mf)
It should be possible to straighten this out quickly. Maybe some of it
has already been straightened out. I have not yet succumbed to
the /texmf/fonts/function/source arrangement because I still
hope that it can be avoided. It is such a bummer.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| I will continue unofficially to provide tape distributions and |
| any other services I can. Although I cannot be near my phone on any |
| regular schedule, I now have an answering machine. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder now available)
================================================================================
Archive-Date: Tue, 22 Nov 1994 14:06:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 22 Nov 94 18:13:41 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9411221813.AA11670@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: TWG-TAG@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
./texmf/tex/latex/packages/babel/babel-new.tex HYPHEN,TOOLONG
./texmf/tex/latex/packages/babel/tb-article.tex HYPHEN,TOOLONG
I'll forward these to Johannes, I expect changing these will not be a
problem.
./texmf/tex/latex/packages/tools/afterpage.dtx TOOLONG
./texmf/tex/latex/packages/tools/enumerate.dtx TOOLONG
./texmf/tex/latex/packages/tools/indentfirst.dtx TOOLONG
./texmf/tex/latex/packages/tools/longtable.dtx TOOLONG
It was decided, after much worrying, *not* to change these names. I
actually did change them before the release of 2e, and all the
internal documentation to match, but we decided to change back, not
least because too many books have been printed with the full names in.
> /contrib/supported
Anyone got any suggestions for a shorter name? Another possibility is
to drop the supported-other distinction, and put everything in
contrib, one level up. (Joachim??)
All the rest are contributed by assorted authors, so changing the
names means contacting them and asking them to change, I think ctan
can not really just change the names of contributed files.
David
================================================================================
Archive-Date: Tue, 22 Nov 1994 15:11:41 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411222111.WAA18186@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Joachim's proposal for fonts/source...
To: TWG-TDS@SHSU.edu
Date: Tue, 22 Nov 1994 22:11:42 +0100 (MEZ)
Content-Type: text
You wrote:
>
> >I don't recall anyone commenting on Joachim's proposal that fonts/source
> >would work because the paths below fonts/source could be easily constructed
> >by substitution.
>
> Easy if you have a reverse look-up table that tells you that
> to find ma55a10.tfm you should look in misc/malvern/tfm.
No.
The point of discussion was
1. developers won't implement pruning
2. developers are willing to implement subdirectory searching.
3. full subdirectory searching is too slow for fonts/source
organization
Why is it said to be so slow? Because it was said that one does not
know where <type> directories could be, one has to search the full
file tree for it. (Under the assumption of no pruning.) It was said,
in the fonts/type mimic we know it.
I mentioned that we *do* know where <type> directories are in TDS, we
don't need full directory searching. In fact, we need only one-level
searching.
As an example, the pattern "texmf/fonts/*/tfm/%f.tfm" names each TFM
file (tagged as `%f') with one level of subdirectory searching
(marked with `*'). The pattern "texmf/fonts/*/%t/%d/dpi%r/%f.%t" names
a font file %f (of type %t, for device %d, resolution %r) with one
level of subdirectory searching (again, marked with `*').
NOTE 1: We don't need full subdirectory searching as long as we use
only TDS structure.
NOTE 2: Only POSIX.2 conformant functions are needed to implement the
pattern above. I.e., it's portable, folks.
NOTE 3: Many drivers already use such patterns, anyhow, to construct
font names. It is not a new concept.
Sorry, Alan, but your arguments don't hold water. If you're against
patterns, you're against subdirectory searching at all.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 23 Nov 1994 09:11:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 23 NOV 94 15:02:42 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: twg-tds <twg-tds@SHSU.EDU>
Subject: Another idea for e-TeX: \traceingfileio
Message-ID: <2023A84F_002C11B0.00987E6BBA4E0E7A$19_4@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
Having put up the so-called `patch level 4' of LaTeX-2e, I found it expedient
to allow full sub-directory searching... This was a mistake, since LaTeX-2e
proceeded to find LTHyphen.Cfg in some arcane unsupported Cyrillic
sub-directory, but that is by the by...
Rather more importantly, TeX can now appear to take a finite-but-unbounded time
to find a file that it used to find almost instantaneously. So what I propose,
specifically bearing in mind the possible requirements of TWG-TDS, is a new
primitive \tracingfileio: differing positive values would cause greater or
lesser verbosity, but basically it would shew each attempt to open a file,
including the particular path which it is currently traversing. I would
suggest that one use of the granularity be to differentiate between
\input, \openin and \font (have I missed any?).
** Phil.
================================================================================
Archive-Date: Thu, 24 Nov 1994 04:49:34 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
Date: Thu, 24 Nov 1994 10:49:01 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:076360:941124104936"@cl.cam.ac.uk>
> ./texmf/tex/latex/contrib/supported/epsfig/README.unix TOOLONG DIR&SU
the epsfig package should not be there; please zap it. its now part of
the standrad graphics package
> ./texmf/tex/latex/misc/doublespace.sty TOOLONG
> ./texmf/tex/latex/misc/doublespace2.sty TOOLONG
yuck. who supports these? i think no-one. we can take unilateral
action? but the Companion mentions doublespace
> ./texmf/tex/latex/misc/supertabular.doc TOOLONG
> ./texmf/tex/latex/misc/supertabular.sty TOOLONG
> ./texmf/tex/latex/misc/supertabular.tex TOOLONG
i understand David is doing a supertab emulation, so the package
should go?
> ./texmf/tex/plain/fontchart.tex TOOLONG
blame Don
> ./texmf/tex/tugboat/germanhyph.tex
you should not have this. zap it
> ./texmf/tex/tugboat/landscape.sty TOOLONG
zap it
> ./texmf/fonts/public/pandora/src/panaccent.mf TOOLONG
> ./texmf/fonts/public/pandora/src/pangreeku.mf TOOLONG
> ./texmf/fonts/public/pandora/src/panlowers.mf TOOLONG
bllody Pandora. why doesnt sonme sort out its naming?
> For pandora, I suggest panacc.mf, pangrk.mf and panlwr.mf (or even
> panlower.m
i say just do it, and pass to CTAN for prmulgation
sebastian
================================================================================
Archive-Date: Thu, 24 Nov 1994 05:13:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 24 Nov 1994 06:13:14 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411241113.AA03279@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
I asked Nina about naming the Pandora files.
No response yet.
I don't know if she's still around.
================================================================================
Archive-Date: Thu, 24 Nov 1994 06:06:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 24 Nov 1994 13:06:57 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
To: TWG-TDS@SHSU.edu
Message-ID: <01HJUX2BEO429JDAYY@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Well, the names of pandora fonts were once shortened (i think by Erik-Jan
Vens) to beginn with pn*. He also made the files internally consitent, so
that pandora compiles smoothly.
I got this version years ago from the famous ymir archives (has someone a
backup of this?).
--J"org Knappen.
Appended: List of pandora files I have:
Directory DISK$USER2:[USE.KNAPPEN.MFSOURCES.PANDORA]
CAPS.MF;1 FLIGS.MF;1 LIGS.MF;1 NAMEN.TXT;1
NUMBER.MF;1 PANACCENT.MF;1 PANDOR.MF;1 PANDOR.TXT;1
PANGREEKU.MF;1 PANLOWERS.MF;1 PANPUNCT.MF;1 PN.TXT;1
PNB10.MF;1 PNR10.MF;1 PNSL10.MF;1 PNSLTT9.MF;1
PNSS10.MF;1 PNSSB10.MF;1 PNSSI10.MF;1 PNTT9.MF;1
PUNCTR.MF;1 PUNCTS.MF;1 PUNCTT.MF;1 ROTEXT.MF;1
TTCHAR.MF;1 TTTEXT.MF;1 WIDTHS.MF;1
Total of 27 files.
================================================================================
Archive-Date: Fri, 25 Nov 1994 04:50:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 25 NOV 94 10:33:07 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
Message-ID: <2024E2A1_00335B50.00987FD8666B669A$19_3@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> Well, the names of pandora fonts were once shortened (i think by Erik-Jan
>> Vens) to beginn with pn*. He also made the files internally consitent, so
>> that pandora compiles smoothly.
Unfortunately, unless my counting is letting me down, he didn't go far enough:
--------
Directory DISK$USER2:[USE.KNAPPEN.MFSOURCES.PANDORA]
CAPS.MF;1 FLIGS.MF;1 LIGS.MF;1 NAMEN.TXT;1
NUMBER.MF;1 PANACCENT.MF;1 PANDOR.MF;1 PANDOR.TXT;1
^^^^^^^^^9
PANGREEKU.MF;1 PANLOWERS.MF;1 PANPUNCT.MF;1 PN.TXT;1
^^^^^^^^^9 ^^^^^^^^^9
PNB10.MF;1 PNR10.MF;1 PNSL10.MF;1 PNSLTT9.MF;1
PNSS10.MF;1 PNSSB10.MF;1 PNSSI10.MF;1 PNTT9.MF;1
PUNCTR.MF;1 PUNCTS.MF;1 PUNCTT.MF;1 ROTEXT.MF;1
TTCHAR.MF;1 TTTEXT.MF;1 WIDTHS.MF;1
** Phil.
================================================================================
Archive-Date: Fri, 25 Nov 1994 07:49:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 25 Nov 1994 08:48:31 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411251348.AA17466@terminus.cs.umb.edu>
To: CHAA006@VAX.RHBNC.AC.UK
CC: twg-tds@SHSU.EDU
Subject: Re: Another idea for e-TeX: \traceingfileio
Rather more importantly, TeX can now appear to take a finite-but-unbounded time
to find a file that it used to find almost instantaneously.
That's behavior that should be considered a bug. In my opinion.
a new primitive \tracingfileio:
I'm not sure a new primitive is necessary, especially since the output
from such a primitive would necessarily be system-dependent. Instead, I
think debugging options should be done in whatever way is most natural
and best for the implementation -- command-line arguments, environment
variables, using strings or numbers as values, or whatever.
(In the case of web2c, the envvar KPATHSEA_DEBUG can/will be able to be
set to various numeric values to get debugging output.
================================================================================
Archive-Date: Fri, 25 Nov 1994 08:14:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 25 NOV 94 14:13:48 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: twg-tds <twg-tds@SHSU.EDU>
Subject: Re: Karl's comments on *\tracingfileio
Message-ID: <20253A3A_000DF7E0.00987FF739F921FA$20_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
Karl --
>> Rather more importantly, TeX can now appear to take a finite-but-unbounded time
>> to find a file that it used to find almost instantaneously.
>> That's behavior that should be considered a bug. In my opinion.
I can't see why: if there are are a very large number of files in a very
large number of nested directories, I would expect the time to be
considerably greater than had previously been the case. And on a time-sharing
NFS-served file system (which is how I run TeX here), that time can be
very considerable indeed. I can't see that there is any bug-like
behaviour, although it's distinctly sub-optimal...
>> a new primitive \tracingfileio:
>> I'm not sure a new primitive is necessary, especially since the output
>> from such a primitive would necessarily be system-dependent. Instead, I
>> think debugging options should be done in whatever way is most natural
>> and best for the implementation -- command-line arguments, environment
>> variables, using strings or numbers as values, or whatever.
But is \tracingfileio different from any other (tracing=debugging) option?
None are used for production purposes, all are used for debugging. Why
would you want to treat file-io differently? I can see your point
about the output being system dependent, but that's true of \showbox,
for example, where the `glue set' figures are documented to be system-
dependent.
** Phil.
================================================================================
Archive-Date: Fri, 25 Nov 1994 09:36:54 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0rAkou-0006QqC@rsuna.crn.cogs.susx.ac.uk>
Date: Thu, 24 Nov 94 20:31 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Joachim's proposal for fonts/source...
>As an example, the pattern "texmf/fonts/*/tfm/%f.tfm" names each TFM
>file (tagged as `%f') with one level of subdirectory searching
Oh okay, yes if your TeX supports this sort of patterns, then yes you
can use fonts/source without much overhead. But we're back to the
argument about whether we want something that can be implemented today
or not.
So yes, this is another technical solution which would work if it were
implemented. But it doesn't change the political situation, which is
that TDS will die a death if we propose something that can't be
implemented today on most machines.
Alan.
================================================================================
Archive-Date: Fri, 25 Nov 1994 09:55:32 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411251555.QAA18693@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Joachim's proposal for fonts/source...
To: TWG-TDS@SHSU.edu
Date: Fri, 25 Nov 1994 16:55:29 +0100 (MEZ)
Content-Type: text
Alan wrote:
>
> So yes, this is another technical solution which would work if it were
> implemented. But it doesn't change the political situation, which is
> that TDS will die a death if we propose something that can't be
> implemented today on most machines.
It can be implemented. I already sent around the C function prototypes
that does it and repeat that I'm willing to give them to anyone (and
support them).
In fact, I brought this up because you and others said that pruning
is too difficult for many implementors. The proposal that's on the
table now does not demand such `sophisticated' knowledge of an
`esoteric' area like graph algorithms (taught in undergrad CS
courses, aren't they? ;-) -- it's standard C hackery.
Yes, I agree that the political situation is that it should be
implementable easily by every hacker. My proposal is. Please note that
the current TDS proposal cannot be realized on many platforms, so
there is implementation work ahead anyhow.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 25 Nov 1994 11:36:43 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 25 Nov 1994 09:36:51 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411251736.JAA28868@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
I haven't been able to get in touch either. I would still like
to have it official that my change to make smode possible is
OK. I send it out as a patch, but it should be part of the main files.
================================================================================
Archive-Date: Fri, 25 Nov 1994 11:51:29 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 25 Nov 1994 09:50:31 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411251750.JAA29586@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Non-unique to 8+3 in the pandora files
UnixTeX maintains a fully operational set of pandora files (I have actually
set several things in pandora including a collection of my father's poetry)
These have been modified in accordance with the following notice, although
the originals have been carefully preserved in the distribution. I hope this
time we can get the goahead for all these minor changes, which do not
in any way alter the character design.
Text of 00NOTE in the UnixTeX pandora source directory
00NOTE [Unix TeX distribution; October 1991, April 1993;
modified May 1994]
The standard mf source files for pandora cannot be used
with smode because they assume that the type of mode
is always numeric (smode defines the type of mode as string).
We have made very minor changes that will make smode
work and will in no way alter the actual appearance
of the font. The changes were posted by Pierre MacKay
(mackay@cs.washington.edu) to TeXhax on 22 April 1993, and
the author N. Billawalla notified. The files concerned are
pandor.mf
pnb10.mf
pnr10.mf
pnsl10.mf
pnss10.mf
pnssb10.mf
pnssi10.mf
pntt9.mf
The original files have been retained as *.mf.orig files.
Another change was made to line 12 of rotext.mf and tttext.mf
as a result of Mrs. Klaus Schallhorn's observation that the umlauts
over the slanted upper case letters in a document set by her husband
using the Pandora fonts, appeared to have been blown past the letters
to which they belonged, as though by a draft coming in from the left
side of the page.
All diacritical marks above upper case pnsl10 and pnssi10 manifested
this effect.
The problem was that the tfm slant value had been set to a HUGE
value as an accidental side effect of Neenie Billawala's careful
calculations of slant offsets in character design.
Changing
font_slant oblique;
to
font_slant sind(oblique/cosd oblique);
took care of the problem. The fix was posted to TeXhax by
Pierre A. MacKay (mackay@cs.washington.edu) in October 1991,
and the author notified. The original sources are retained
as *.mf.orig files.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| I will continue unofficially to provide tape distributions and |
| any other services I can. Although I cannot be near my phone on any |
| regular schedule, I now have an answering machine. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder now available)
================================================================================
Archive-Date: Fri, 25 Nov 1994 11:59:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 25 Nov 94 17:57:51 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9411251757.AA14088@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Joachim's proposal for fonts/source...
> Please note that
> the current TDS proposal cannot be realized on many platforms, so
> thaere is implementation work ahead anyhow.
I think we have been round this circle a few times already, but...
The current TDS proposal is implementable now on the vast majority of
unix and pc sites (at least web2c and emtex) and (I understand) also
in the upcoming vms TeX release, and for most normal sized setups also
on oztex. This is enough people to get TDS off the ground.
If we come out with a TDS for which everyone must upgrade their TeX
and in all cases except web2c, have to wait for that upgrade to
appear, we may as well not bother recommending anything.
David
================================================================================
Archive-Date: Fri, 25 Nov 1994 12:18:54 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 25 Nov 1994 10:16:33 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411251816.KAA00959@june.cs.washington.edu>
To: CHAA006@VAX.RHBNC.AC.UK
CC: twg-tds@SHSU.EDU
Subject: Re: Karl's comments on *\tracingfileio
This is essentially the same thing as the earlier observation about
the global nature of \openin. IO is not a typesetting primitive, and
has nothing to do with the way the primitives put the glyphs on the
page. \showbox may produce some system-dependent rounding differences
but boxes are an integral part of the typesetting environment of TeX.
IO is necessarily tied to the architecture of the particular compilation
in all its aspects. One of the virtues of Karl's kpathsea approach is
that it increasingly isolates IO questions from TeX proper. The
handling of IO is an operating system problem, not a typesetting problem.
As such it should be addressed by operating system tools.
I note that in the program listing \openin and its cousins are identified
as primitives in the sense that you can't achieve their functionality with
any sort of manipulation of \def. Perhaps they should have been given
some other name to preempt some aspects of the present discussion. But I
suspect that it just seemed so obvious that IO is a special and wholly
architecture-dependent case the the distinction appeared unnecessary. After
all, the program was written in Pascal, and ur-Pascal was distinguished
by Wirth's evident hope that if he ignored IO as completely as possible
maybe it would go away altogether.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| I will continue unofficially to provide tape distributions and |
| any other services I can. Although I cannot be near my phone on any |
| regular schedule, I now have an answering machine. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder now available)
================================================================================
Archive-Date: Fri, 25 Nov 1994 16:04:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 25 Nov 1994 23:00:24 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
To: TWG-TDS@SHSU.edu
Message-ID: <01HJWW4WI00IHXIT2Q@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Oops, You're right. I think, he did not change these, because clipping of
the last letter did not cause any harm on a PC, however for consistency
they should be also renamed from pan... to pn...
--J"org Knappen.
================================================================================
Archive-Date: Fri, 25 Nov 1994 19:53:29 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 25 Nov 1994 17:53:14 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411260153.RAA22677@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
More on the pandora naming:
If we are going to have pnaccent.mf pnlowers.mf and pngreeku.mf we
might as well go all the way with pnpunct.mf even though it is not
strictly necessary. But I think pandor.mf should probably be left
as is.
================================================================================
Archive-Date: Mon, 28 Nov 1994 15:30:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 28 NOV 94 11:34:37 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: TWG-TDS <TWG-TDS@SHSU.EDU>
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
Message-ID: <20264EF9_000E3378.0098823C7D0D63BA$19_1@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> Oops, You're right. I think, he did not change these, because clipping of
>> the last letter did not cause any harm on a PC, however for consistency
>> they should be also renamed from pan... to pn...
Clipping to first-8+3 is fine, and until recently I have been able to rely
on it, as I share files between VAX/VMS and MS/DOS using NFS; unfortunately
I am now testing a new version of TeX which has hard-wired into it a
different algorithm: first-5+last-3.3; this _really_ screws things :-(
** Phil.
================================================================================
Archive-Date: Mon, 28 Nov 1994 19:14:39 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 28 Nov 1994 17:14:51 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411290114.RAA05148@june.cs.washington.edu>
To: TWG-TDS@SHSU.EDU, TWG-TAG@SHSU.EDU
Subject: Redundant files in latex/unpacked
Is it really necessary to include the entire contents of latex/base
as a redundant copy in latex/unpacked. It actually causes trouble,
because if you bring in an upgrade, e.g. ltpatch.ltx and place
it in only one of [base,unpacked] you have an even chance, depending
on where path-searching looks first, of getting the old file.
I did a full unpack.ins into a new unpacked directory and then
trimmed old-unpacked until the listings matched. The redundant
files were
00readme.txt ifthen.dtx lterror.dtx ltpatch.ltx preload.dtx
Makefile.unx ifthen.ins ltfiles.dtx ltpictur.dtx proc.dtx
bugs.txt install.txt ltfinal.dtx ltplain.dtx proc.ins
changes.txt lablst.tex ltfloat.dtx ltsect.dtx sample2e.tex
classes.dtx latex209.dtx ltfntcmd.dtx ltspace.dtx slides.dtx
classes.ins latex209.ins ltfss.dtx lttab.dtx slides.fdd
clsguide.tex latexbug.tex lthyphen.dtx ltthm.dtx slides.ins
cmextra.ins latexsym.dtx ltidxglo.dtx ltvers.dtx small2e.tex
cmfonts.fdd latexsym.ins ltlength.dtx ltxdoc.dtx source2e.tex
cmfonts.ins legal.txt ltlists.dtx ltxguide.cls syntonly.dtx
directex.txt letter.dtx ltlogos.dtx ltxref.dtx syntonly.ins
doc.dtx letter.ins ltmiscen.dtx makeindx.dtx template.txt
docstrip.dtx ltalloc.dtx ltnews.cls makeindx.ins testdist.dtx
docstrip.ins ltbibl.dtx ltnews01.ps manifest.txt testpage.tex
emtex.txt ltboxes.dtx ltnews01.tex manual.err texpert.txt
exscale.dtx ltclass.dtx ltoutenc.dtx newlfont.dtx unpack.ins
exscale.ins ltcntrl.dtx ltoutput.dtx nfssfont.tex unpacked.txt
fntguide.tex ltcounts.dtx ltpage.dtx oldlfont.dtx usrguide.tex
fontdef.dtx ltdefns.dtx ltpageno.dtx oztex.txt web2ctex.txt
idx.tex ltdirchk.dtx ltpar.dtx patches.txt yandytex.txt
None of the above belong in unpacked.
I did the unpack into an empty latex/unpacked directory, with
initex ../base/unpack.ins
to get a clean lot of unpacked files. It works fine.
One file that ought to be included in latex/base, however,
is David Carlisle's template for a texsys.cfg. Otherwise
it is liable to disappear altogether, which would be a pity.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| I will continue unofficially to provide tape distributions and |
| any other services I can. Although I cannot be near my phone on any |
| regular schedule, I now have an answering machine. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder now available)
================================================================================
Archive-Date: Tue, 29 Nov 1994 04:03:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 29 Nov 94 10:03:21 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9411291003.AA16529@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: TWG-TAG@SHSU.EDU
Subject: Re: Redundant files in latex/unpacked
> s it really necessary to include the entire contents of latex/base
> as a redundant copy in latex/unpacked.
Yes because the instructions are to get *one* or *the other* of these
directories.
The `unpacked' directory is not intended for user installation.
The installation instructions are
1) get base
2) run unpack.ins
3) initex latex.ltx
However if you have an amiga or something step 2 takes about 3 hours
so instead you can
1) get unpacked
3) initex latex.ltx
ie skip the unpack stage at the expense of downloading more files.
David
================================================================================
Archive-Date: Tue, 29 Nov 1994 06:56:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 29 Nov 1994 13:57:17 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Redundant files in latex/unpacked
To: TWG-TDS@SHSU.edu
Message-ID: <01HK1YAMXT7M9GV76Z@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
I think, providing the unpacked distribution is a service of the CTAN
archives and the LaTeX2e team for the convenience of the users of slow
machines. You are not supposed to have the same redundancy in a production
version of TeX.
--J"org Knappen.
================================================================================
Archive-Date: Tue, 29 Nov 1994 08:49:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 29 NOV 94 14:28:19 BST
From: CHAA006@VAX.RHBNC.AC.UK
To: twg-tds <twg-tds@SHSU.EDU>
Subject: Re: Redundant files in LaTeX/Unpacked
Message-ID: <2026268D_002FD480.0098831DEB12F41A$17_2@UK.AC.RHBNC.VAX>
Reply-To: TWG-TDS@SHSU.edu
>> Yes because the instructions are to get *one* or *the other* of these
>> directories.
That presupposes that the user knows what the instructions are. But many
will do what I did, which is simply to ask Ctan for an on-the-fly ZIPping
of the entire LaTeX hierarchy: once you've done that, you have both packed
and unpacked forms.
** Phil.
================================================================================
Archive-Date: Tue, 29 Nov 1994 09:43:41 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411291543.QAA07968@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Redundant files in latex/unpacked
To: TWG-TDS@SHSU.edu
Date: Tue, 29 Nov 1994 16:43:36 +0100 (MEZ)
Content-Type: text
Joerg wrote:
>
> I think, providing the unpacked distribution is a service of the CTAN
> archives and the LaTeX2e team for the convenience of the users of slow
> machines. You are not supposed to have the same redundancy in a production
> version of TeX.
Exactly, and I would like to add that this distribution directory
must be split in a production version, according to our TDS draft. As
the LaTeX2e documentation tells, a whole bunch of files are to be
moved to tex/latex/distrib/base. We added the recommendation to move
*.ltx files to tex/initex/latex.
Once again, I would like to point out that
ftp://ftp.th-darmstadt.de/pub/tex/TDS-compliant/ holds files that
describe a basic TDS compliant installation in more detail. In
particular, map.dirs lists all directories and map.files is an
extensive directory list with files.
(I have to admit, though, that I didn't change tex/hyphen ->
tex/initex yet. That's partly because the draft doesn't tell any more
where the hyphenation patterns shall go...)
And please -- what's the current state to drop the distrib/contrib
special case of tex/latex, now that the LaTeX team says it's
unnecessary?
I ask this for the third time, because I would like to get a
(positive or negative) answer before I reorder a large part of the
whole installation!
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Tue, 29 Nov 1994 09:53:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 29 Nov 94 15:53:36 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9411291553.AA16785@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Redundant files in latex/unpacked
> We added the recommendation to move
> *.ltx files to tex/initex/latex.
It's on the list of things to change once we make the install docs TDS
compliant, after the TDS document is finalised...
> And please -- what's the current state to drop the distrib/contrib
> special case of tex/latex, now that the LaTeX team says it's
> unnecessary?
I assume dropped, although not in the latest draft, since I think I was
the only one pushing for it anyway.
texmf/tex/latex/
base
tools
graphics
amslatex
seminar
foo
bar
...
seems OK to me?
David
================================================================================
Archive-Date: Tue, 29 Nov 1994 11:25:31 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0rCVNu-00006iC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 29 Nov 94 16:26 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Redundant files in latex/unpacked
>Exactly, and I would like to add that this distribution directory
>must be split in a production version, according to our TDS draft. As
>the LaTeX2e documentation tells, a whole bunch of files are to be
>moved to tex/latex/distrib/base. We added the recommendation to move
>*.ltx files to tex/initex/latex.
So the final destinations are:
tex/<system>/formats/ latex.fmt
tex/doc/latex *guide.tex ltnews*.tex etc.
tex/doc/latexsrc *.dtx *.txt
tex/latex/base *.tex *.cls *.clo *.sty *.fd *.def *.cfg
tex/initex/latex *.ltx *.ins
makeindex/ist *.ist
? Details may be hazy, but neither Darmstadt nor jasper.ora.com are
talking to me...
This needs instructions that iniTeX needs to be able to read
tex/latex/base when creating latex.fmt. Not sure about the homes for
*.txt or *.ins. There may be other holes.
>And please -- what's the current state to drop the distrib/contrib
>special case of tex/latex, now that the LaTeX team says it's
>unnecessary?
Fine by me to have latex/base, latex/graphics, etc.
Alan.
================================================================================
Archive-Date: Tue, 29 Nov 1994 12:15:53 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 29 Nov 1994 10:16:01 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199411291816.KAA08013@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
TWG-TAG-SHSU.EDU
In-reply-to: Sebastian Rahtz's message of Thu, 24 Nov 1994 10:49:01 +0000 <"swan.cl.cam.:076360:941124104936"@cl.cam.ac.uk>
Subject: Re: Non-unique to 8+3 in LaTeX... hierarchy
Following Sebastian's guidance, I have looked at the files he
condemns, and they are a very odd lot.
The ./texmf/tex/latex/misc seems to be all latex209 stuff, so I have
moved it there, and shrunk the names. It turns out there was some
considerable duplication anyway.
I took a look in contrib/other/misc, and there are some long and
hyphenated names there, but that is so far out on the tree that
it probably doesn't matter.
I am taking local unilateral action to shrink the names in the
pandora directory, but that also means some slight editing in the
driver files. I would still like to be sure that the smode and
slant fixes are incorporated into the archive files. They do not
in any way alter the appearance of any of the characters (except
to get the accents where they were clearly intended to be in the
case of the slant fix) but they make the source files function
properly. Likewise the change from "pan" to "pn". It is trivial,
but it needs to be consistent. I would urge keeping pandor.mf
rather than pndor.mf, but making the pn prefix consistent even
in pnpunct.mf where it isn't strictly needed. I see no reason
to have qualms of conscience about this. It does not affect the
integrity of the design in any way.
At this point, I think the UnixTeX version of the files is 8+3
clean except for the odd file in contrib.
%=======================================================================%
| N O T I C E |
| The University of Washington has ordered us to close the Northwest |
| Computing Support Center, and to terminate the official support |
| of UnixTeX. Although the termination was final as of June 14, 1994 |
| I will continue unofficially to provide tape distributions and |
| any other services I can. Although I cannot be near my phone on any |
| regular schedule, I now have an answering machine. Please note |
| the changes in address and telephone number. There is no Northwest |
| Computing Support Center any longer. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder now available)
Archive-Date: Mon, 05 Dec 1994 16:37:17 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199412051911.UAA33142@spice.iti.informatik.th-darmstadt.de>
Subject: Some comments on TDS draft (fwd)
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Mon, 5 Dec 1994 20:11:16 +0100 (MEZ)
CC: David_Rhead@vme.ccc.nottingham.ac.uk
Content-Type: text
Today I received the following comment on the current draft of TDS.
Of particular interest seems to me that David would prefer even more
subcategories under tex/latex/, while some voices here (mine included ;-)
call for elimination of this special case.
[Please note Cc: to David.]
Joachim
---------------- forwarded message follows:
From: David_Rhead@vme.ccc.nottingham.ac.uk
Date: Mon, 5 Dec 94 17:23:18 GMT
Subject: Some comments on TDS draft
% Following your posting to comp.text.tex, I took up your invitation to
% fetch copies of the material from the TDS-compliant directory at
% Darmstadt.
% I have some comments, which I've appended below. However, I don't
% know who acts as secretary to the TWG, and I can't find a mail address
% for Norm Walsh.
% Could you feed my comments into the TWG's deliberations, please?
% (I'm afraid they've been done in haste. I hope that the gist is clear.)
% David
\documentclass[11pt]{article}
\begin{document}
\title{Some comments on version 0.5 of \\
{\it A directory structure for implementation-independent \TeX\ files}}
\author{David Rhead}
\date{5th December 1994}
\maketitle
\section{Name of \LaTeX\ directory}
Presumably, in due course, \LaTeX3 will appear, and people will have to
make the transition from \LaTeX2e to \LaTeX3. During the 2e-to-3
transition period, systems administrators may need to have \LaTeX2e
material and \LaTeX3 material in their filestores in parallel.
To ease the transition from \LaTeX2e to \LaTeX3, might it be better to have
directories called {\tt latex2e} rather than {\tt latex}? E.g., at the top
of page~8 of version 0.5 of the draft, have\\
{\tt texmf/tex/latex2e/distrib/package/files}\\
rather than \\
{\tt texmf/tex/latex/distrib/package/files}. \\
This would give the option of having \\
{\tt texmf/tex/latex3...} \\
when the time comes to phase \LaTeX3 in.
I would agree that \LaTeX2e is what one should get now from ``the {\tt
latex} command'' at a particular site. If a similar situation recurs with
\LaTeX3 (e.g., if \LaTeX3 has ``a compatibility mode''), ``the {\tt latex}
command'' might give \LaTeX3 from some day to be determined by a site's
systems administrator. But the run-up to the 2e-to-3 changeover may be
easier if it is clear whether a directory holds \LaTeX2e stuff or \LaTeX3
stuff. If the directories are called\\
{\tt texmf/tex/latex2e...} \\
and \\
{\tt texmf/tex/latex3...}, \\
rather than \\
{\tt texmf/tex/latex...}, \\
directory-names can be left alone during the 2e-to-3 transition. Material can
be tested in the\\
{\tt texmf/tex/latex3...}, \\
directory without affecting the \LaTeX2e service. When the material has
been tested, the effect of ``the {\tt latex} command'' for end-users can be
re-defined to point at the \LaTeX3 directory rather than the \LaTeX2e
directory.
\section{Site-specific \LaTeX\ class files, etc.}
An organization may have class files etc., that are locally important
(perhaps locally \emph{extremely} important), but which stay within the
organization. Examples include:
\begin{itemize}
\item
The AMS production software (as distinct from the pre-print styles
that are freely available to potential authors).
\item
The Elsevier production software (as distinct from the pre-print styles
that are freely available to potential authors).
\item
Addison-Wesley's software for books. At a UKTUG meeting on
book-production, Geeti Granger (from Addison-Wesley UK) said that most
of their \LaTeX-ed books are done in one of 6 designs. The {\tt .cls}
files (or whatever) that implement these 6 designs will have to
``live'' somewhere in the Addison-Wesley filestore.
\item
Anything that delivers documents typeset according to ``the
house-style'' of a particular organization.
\item
Anything that is hacked together that is ``good enough'' for use
internally within a particular organization, but isn't ``good enough''
to withstand the scrutiny it would get if placed in a CTAN archive.
\item For a university, software that:
\begin{itemize}
\item produces the sort of memos that are usual on that university campus
\item lays letters out so that they fit the university's headed paper
\item lays a thesis out in a way that is known to satisfy the university's
regulations
\item lays examination papers out as required by examination
officials.
\end{itemize}
(To reduce the scope for student mischief, it may be desirable to keep some
of these {\tt .cls} files in a directory that students cannot read!)
\end{itemize}
As far as I can see, the natural places for such material would be:
\begin{description}
\item[either] directly under {\tt texmf/tex/latex2e}
\item[or] under {\tt texmf/tex/latex2e/contrib}.
\end{description}
Might it be worth the TWG giving some advice about which place is to be
regarded as ``standard'' (and whether there should, or shouldn't, be a
standard name for the directory that holds it)?
Personally, I'd rate the organization-specific stuff as very important.
\begin{itemize}
\item
If people are browsing around the filestore, I'd hope that they find
it easy to locate the files that deliver their organization's
house-style.
\item
If someone is looking for a thesis style/class, it would be tragic if
they came across {\tt utthesis} (which is unlikely to satisfy
requirements outside Texas) before they found the {\tt .cls} file (or
whatever) that is known to meet their own university's requirements.
\item
It seems to me that one should treat ``provision of
organization-specific stuff'' as ``a good, and \emph{usual}, thing''.
I think it is much better for one person in an organization to do the
work and to make it available organization-wide, than to have
individual authors clogging {\tt comp.text.tex} up with queries about
how to satisfy their organization's requirements. E.g., surely it's a
university's computing centre's job to provide thesis software that is
deemed to satisfy the regulations -- it shouldn't be up to every
postgraduate to grope around CTAN and post items to {\tt
comp.text.tex}, etc.
\end{itemize}
Might it be worth saying that, as well as holding {\tt distrib} and {\tt
contrib}, {\tt texmf/tex/latex2e/contrib} will hold a directory (or two, to
allow one that students can't read!) that holds organization-specific
material? The following occured to me as examples of what this directory
(or directories) might be called:
\begin{itemize}
\item
{\tt texmf/tex/latex2e/OurHouse} for software that delivers ``our
house-style''
\item
{\tt texmf/tex/latex2e/in-house} for software that is used ``in
house''
\item
{\tt texmf/tex/latex2e/OurStaff} and {\tt texmf/tex/latex2e/OurOwn}
for ``software for staff-only'' and ``general-purpose'' software
respectively
\item
in the University of Mars,
{\tt texmf/tex/latex2e/UoMstaff} and {\tt texmf/tex/latex2e/UoM}
for ``software for staff-only'' and ``general-purpose'' software
respectively. (Students cannot read stuff in
{\tt texmf/tex/latex2e/UoMstaff}.)
\item
in the Department of Media Studies at the University of Mars,
{\tt texmf/tex/latex2e/CC} and {\tt texmf/tex/latex2e/Media}
for ``software hacked together and maintained by the UoM Computing Centre'' and
``software hacked together and maintained by UoM Media Studies staff''.
\item
What about sites where English is not ``the first language''? Where
would ``the ordinary user'' expect to find material that formats
documents in the way his/her organization requires? Does there need
to be the flexibility to allow a French site to put such material in,
for example, {\tt texmf/tex/latex2e/ChezNous} and a German site to put
it in {\tt texmf/tex/latex2e/bei-uns}?%
\footnote{Please feel free to replace these examples by more authentic ones.}
\end{itemize}
You'll see that I've had difficulty in thinking of one name that will
always be suitable. Maybe the TWG can think of a suitable name. If not,
perhaps it is a matter of finding ``a form of words'' to go in the
standard. For example, the text near the top of the current page 8 might
be replaced by something like:
\begin{quote}
The \LaTeX\ tree contains an extra level between ``format'' and
``package'' which indicates the package's status. Packages that are
supported by the \LaTeX\ project team are stored in\\
{\tt texmf/tex/latex2e/distrib/\dots}, \\
and other public-domain packages that are stored in\\
{\tt texmf/tex/latex2e/contrib/\dots}. \\
Packages peculiar to a particular site (e.g., because they implement
``the house-style'') will be held in one-or-more directories within
{\tt texmf/tex/latex2e/\dots}, \\
e.g., at Mars University Press, \\
{\tt texmf/tex/latex2e/MUPhouse/\dots}. \\
\end{quote}
Or does the TWG feel that such material should go under {\tt
texmf/tex/latex2e/contrib}?
In the analogous situation under {\tt doc}, a \LaTeX\ {\it Local Guide} in
the ``site's own'' directory might be the one tailored for that site,
whereas a {\it Local Guide} in a {\tt distrib} directory would be the raw
version distributed by the \LaTeX\ project team.
I think that it might be useful if the TWG's specification of the
``standard directory structure'' acknowledged that there is likely to be
such material, and suggested where it might live.
\section{Example files}
I'm inclined to think that ``example files'' are different from
``documentation files''. E.g., {\tt small2e.tex} is something that one
copies and plays with, whereas {\tt btxdoc.tex} is something which one
typesets and reads. Locally, I supply quite a lot of \TeX-related example
files (e.g., a ``thesis kit'' containing a root file, skeleton front
matter, 3 skeleton chapters, 2 skeleton appendices, and back matter -- the
idea being that a student can copy the lot and start typing their own text
into the skeleton).
Moreover, a site may have other software that supplies documentation and
example programs. E.g., for numerical methods, we get the Numerical
Algorithms Group Fortran Library, which has associated ``routine summary''
files and ``example program'' files. The site may wish to use links to
make it appear to end-users that all documentation files are in one tree,
and all example files are in another tree. E.g., the Mars Computing Centre
might reasonably want to define a directory {\tt /mcc/examples} that
appears to hold both NAG and \LaTeX\ examples, and a directory {\tt
/mcc/doc} that appears to hold both NAG and \LaTeX\ documentation.
How about having\\
{\tt examples/martian}\\
as well as \\
{\tt doc/martian}?
\end{document}
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Tue, 06 Dec 1994 05:32:08 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0rEy5e-00006iC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 6 Dec 94 11:29 GMT
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu, David_Rhead@vme.ccc.nottingham.ac.uk
Subject: Re: Some comments on TDS draft (fwd)
David,
>To ease the transition from \LaTeX2e to \LaTeX3, might it be better to have
>directories called {\tt latex2e} rather than {\tt latex}?
This is true, but the benifits of using latex2e will be transitory
(and quite a way in the future!) whereas the benefits of using latex
(eg users look in /local/texmf/tex/latex/ for stuff to do with latex)
are permanent.
For the transition, the best solution (on systems which support such
things) is to have directories latex209 latex2e latex3 etc. with a
symbolic link latex -> whatever... this is how I'll be implementing it
at this end!
>As far as I can see, the natural places for such material would be:
>\begin{description}
>\item[either] directly under {\tt texmf/tex/latex2e}
>\item[or] under {\tt texmf/tex/latex2e/contrib}.
>\end{description}
The current reccomendation (I can't remember if it made it into this
draft---it should have done!) is for a local directory, eg here it's
texmf/tex/latex/sussex/. This directory should *not* be called `local'
or some such in order that files can move (fairly) safely from site to
site.
>Might it be worth saying that, as well as holding {\tt distrib} and {\tt
>contrib}, {\tt texmf/tex/latex2e/contrib} will hold a directory (or two, to
>allow one that students can't read!) that holds organization-specific
>material?
The distrib/ contrib/ distinction is going to disappear, instead
there'll be (eg) texmf/tex/latex/graphics/, texmf/tex/latex/seminar/,
texmf/tex/latex/sussex/ etc.
>You'll see that I've had difficulty in thinking of one name that will
>always be suitable.
I don't think we should try. Sites are better placed to come up with
their own local names than we are.
Alan.
================================================================================
Archive-Date: Tue, 13 Dec 1994 08:10:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 13 Dec 94 15:09:35 +0100
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9412131409.AA19543@wega.informatik.uni-hannover.de>
To: TWG-TDS@SHSU.edu
Subject: system names ?
Since this is my first posting to this group, I start introducing
myself:
I am Thomas Esser, math student at univ. of Hannover, Germany. I have
been doing system adminitration for about 3 years in the institute of
databases and information systems at univ. A month ago, I released a
TeX distribution for linux: teTeX.
My question: how can all those architectures (hardware + OS) be
represented in a 8 character directory-name? (e.g. in texmf/bin/SYSTEM)
I am thinking of sparcs running sunos and solaris, but solaris runs on
intel, too. So, how to name them?
Thomas
================================================================================
Archive-Date: Tue, 13 Dec 1994 12:46:02 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199412131845.TAA16348@spock.iti.informatik.th-darmstadt.de>
Subject: Re: system names ?
To: TWG-TDS@SHSU.edu
Date: Tue, 13 Dec 1994 19:45:37 +0100 (MEZ)
Content-Type: text
Thomas wrote:
>
> A month ago, I released a
> TeX distribution for linux: teTeX.
Nice distribution. :-)
> My question: how can all those architectures (hardware + OS) be
> represented in a 8 character directory-name? (e.g. in texmf/bin/SYSTEM)
> I am thinking of sparcs running sunos and solaris, but solaris runs on
> intel, too. So, how to name them?
Hmmm, ``When in doubt, use brute force''. Was it Kernighan or Ritchie
who said that in their Turing award lecture? ;-)
Just make the names longer. Over NFS, MS-DOS will map the longer
directory names to something cryptic, but you won't access
system-specific directories from there by definition.
Personally, I use a platform specification ($PLATFORM) that is a
combination of an architecture and an OS specifier ("$ARCH-$OS").
Be careful that you'll need different architecture specifiers for
different Sparcs (sun4m & sun4c).
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Tue, 13 Dec 1994 14:29:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 13 Dec 94 21:28:35 +0100
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9412132028.AA20789@wega.informatik.uni-hannover.de>
To: TWG-TDS@SHSU.edu
Subject: Re: system names ?
Joachim wrote:
>Personally, I use a platform specification ($PLATFORM) that is a
>combination of an architecture and an OS specifier ("$ARCH-$OS").
>Be careful that you'll need different architecture specifiers for
>different Sparcs (sun4m & sun4c).
Does sun4m/sun4c really make any difference? We have both
architectures here running the same binaries ...
Thomas
================================================================================
Archive-Date: Wed, 14 Dec 1994 11:31:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Dec 1994 07:10:27 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199412141210.AA11397@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: system names ?
I don't think we need to standardize system names for anything in TDS.
Do we? What's the point? Not everyone is going to have texmf/bin/SYSTEM,
anyway -- sites deal with multiple architectures differently,
and pretending otherwise is pointless, IMHO.
================================================================================
Archive-Date: Wed, 21 Dec 1994 07:06:37 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199412211306.OAA26076@spice.iti.informatik.th-darmstadt.de>
Subject: Re: system names ?
To: TWG-TDS@SHSU.edu
Date: Wed, 21 Dec 1994 14:06:38 +0100 (MEZ)
Content-Type: text
Hallo, ich bin gerade ueber folgende alte Mail gestolpert:
> >Personally, I use a platform specification ($PLATFORM) that is a
> >combination of an architecture and an OS specifier ("$ARCH-$OS").
> >Be careful that you'll need different architecture specifiers for
> >different Sparcs (sun4m & sun4c).
>
> Does sun4m/sun4c really make any difference? We have both
> architectures here running the same binaries ...
Der Unterschied liegt darin, dass sun4m-Architekturen
sun4c-Executables ohne Probleme ausfuehren koennen, aber nicht
umgekehrt.
Frohe Weihnachten,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 21 Dec 1994 07:10:28 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199412211310.OAA21760@spice.iti.informatik.th-darmstadt.de>
Subject: Re: system names ?
To: TWG-TDS@SHSU.edu
Date: Wed, 21 Dec 1994 14:10:38 +0100 (MEZ)
Content-Type: text
Sorry, will check my headers better the next time. (The mail was
meant to be sent to Thomas Esser.)
Happy holidays,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
Archive-Date: Wed, 04 Jan 1995 07:00:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 4 Jan 1995 07:41:30 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199501041241.HAA19506@jasper.ora.com>
To: twg-tds@shsu.edu
CC: bob@microprograms.com
Subject: Re: TWG-TDS
References: <9501041201.AA02280@uu3.psi.com>
Reply-To: TWG-TDS@SHSU.edu
On 3 January 1995 at 08:44:19, bob@microprograms.com wrote:
> Has the work of this committee been completed? I haven't received any
> mail from the list server since 05 Dec 94.
No, the work hasn't been completed yet. But I have a New Year's resolution
about it written down around here somewhere. ;-) I'll try to get a new draft
out this week or next and let's all see if we can wrap this up before
the end of the month.
I know it's taken longer than we expected, but I think we've had to deal
with some fairly thorny issues.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
Archive-Date: Wed, 01 Feb 1995 05:50:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Feb 1995 06:51:26 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502011151.AA26728@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: font hierarchy
We seem to be stalled on the TDS. Can we please either officially
abandon or finish it? Norm, have you made any changes since the 18.Nov
version for ftp on jasper? I would be willing to take over editing it,
if it's a problem for you.
As far as I remember, one of the main outstanding questions is (still)
the fonts directory -- whether we're going to go with
fonts/tfm/adobe/times or fonts/adobe/times/tfm. Yes? Or were there other
serious alternatives on the table?
It's obvious there is substantial resistance to fonts/adobe/times among
the implementors, after reading over the replies to Alan's survey from
October. So, whether or not they or their implementations can be coerced
into trying to support it, it's probably doomed to failure.
So, I suppose I give up. I still think it is the wrong thing, because it
makes maintenance significantly harder, but it's pointless to keep
arguing about it.
P.S. Here's what I wrote before coming to the above conclusion -- I
can't bear to throw it away :-).
The main argument for tfm/adobe, as I recall, was practicality -- it
works reasonably efficiently with (almost?) all implementations now.
The reason I remain unconvinced is the efficiency part; I grant you the
works-with-present-implementations part. The case that is most
interesting, I think, is with CM and the usual Metafonts, the standard
35 PostScript fonts, and the standard LaserJet fonts -- about 200
directories or so in all, and maybe 40 typefaces. This is neither so
small that any kind of searching will be fast, nor so huge that anything
less than a fully-cached implementation will be hopeless. And also it is
a number that probably many implementations are close to.
I looked up Alan's message about emtex (in 1994-08, if anyone cares). In
summary, tfm/adobe/times took about 8 seconds to load 50 fonts, with
about 20 tfm directories. He characterized this as ``reasonable'' -- I
agree so far as it goes, but if it's linear (i.e., 16 seconds with twice
as many TFM directories), I bet many users would become very unhappy,
and so tfm/adobe/times really wouldn't be acceptable.
I seem to remember David C. also reporting some statistics with emtex,
but I can't find that message now. Sigh. In any case, other mail said
that emtex has path specifications (%f/%t/*/ type stuff), so perhaps
it could do searching that way, and avoid the raw subdirectory searching
after all.
================================================================================
Archive-Date: Wed, 01 Feb 1995 10:19:59 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Feb 1995 11:16:24 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502011616.LAA13399@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: font hierarchy
References: <199502011151.AA26728@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 1 February 1995 at 06:51:26, K. Berry wrote:
> We seem to be stalled on the TDS. Can we please either officially
> abandon or finish it? Norm, have you made any changes since the 18.Nov
Thanks for the nudge, Karl. I had hoped to finish it all up by the
end of January. But, in my own defense, the California office was
shut down by the flood (routing all tech support and customer service
calls to Cambridge where we struggled along as best we could), then I
want to CA for a week, got sick (came back early: the redeye with a
fever---that's either the best or the worst way to do it, I'm not sure
which), and then had to catch up on everything I hadn't done for two
weeks.
So, *finally* there's a new draft on jasper (/private/twg-tds). It's
not much changed, but I did a little work.
Let's try to pull together and finish this up before Valentine's day,
what do you say? I think it's all in the details now.
> version for ftp on jasper? I would be willing to take over editing it,
> if it's a problem for you.
Thanks, Karl. If it gets hectic here again, I'll pass it along to you
rather than let it all get stalled again.
> As far as I remember, one of the main outstanding questions is (still)
> the fonts directory -- whether we're going to go with
> fonts/tfm/adobe/times or fonts/adobe/times/tfm. Yes? Or were there other
> serious alternatives on the table?
>
> It's obvious there is substantial resistance to fonts/adobe/times among
> the implementors, after reading over the replies to Alan's survey from
> October. So, whether or not they or their implementations can be coerced
> into trying to support it, it's probably doomed to failure.
>
> So, I suppose I give up. I still think it is the wrong thing, because it
> makes maintenance significantly harder, but it's pointless to keep
> arguing about it.
Done.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Wed, 01 Feb 1995 12:22:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Feb 95 10:15:18 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502011815.AA11517@cfcl.com>
To: TWG-TDS@SHSU.edu, bed_gdg@shsu.edu, rdm@cfcl.com
Subject: implementation
Guise-
I realize that several of you have played with implementing the proposed
structures, but I don't know of any organized plan for generating a "real"
(and definitive) implementation. I would like to suggest that we do this,
preferably as part of the CTAN. I'm not sure how much help PTF can be in
this, but we might be able to supply George with a disk drive, or so...
Yours, Rich
rdm@cfcl.com
================================================================================
Archive-Date: Wed, 01 Feb 1995 12:39:54 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502011840.TAA17959@spice.iti.informatik.th-darmstadt.de>
Subject: Re: implementation
To: TWG-TDS@SHSU.edu
Date: Wed, 1 Feb 1995 19:40:34 +0100 (MEZ)
Content-Type: text
You wrote:
>
> I realize that several of you have played with implementing the proposed
> structures, but I don't know of any organized plan for generating a "real"
> (and definitive) implementation.
IMNSHO the problem is not _generating_ a definitive TDS
implementation, but _maintaining_ it. It's almost a full time job to
track all the new stuff and incorporate it into *the* `One-And-Only'
TDS-compliant TeX (source?) distribution.
The `TDS example' distribution I prepared (location in .sig, below)
is not definitive, but rather minimal. That's because it shall be an
_example_ about the packages that make up the kernel of a full
installation. But it is "real"; i.e., it's made up of packages that
are in use without any alteration on half a dozen platforms I
maintain. (I even provide the scripts to install them on Unix
systems.)
> I would like to suggest that we do this,
> preferably as part of the CTAN.
I don't think we should rearrange CTAN to fit TDS. (I don't know if
you want this, but I'd like to emphasize it. :-)
CTAN organization is oriented towards the purpose of archiving and
retrieving TeX software packages. TDS is oriented towards the purpose
of installing and using these packages. Two different goals that
conflict often enough, and that need two different views anyhow.
(Norm, how about putting that summary in the TDS document? ;-) ;-)
That's one of our past discussion points that are not reflected in
it.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
TeX Users Group
TWG TeX Directory Structure, member
ftp.th-darmstadt.de:/pub/tex/TDS-compliant/ has more information.
================================================================================
Archive-Date: Wed, 01 Feb 1995 12:56:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Feb 95 18:57:16 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502011857.AA06386@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
> I don't think we should rearrange CTAN to fit TDS. (I don't know if
> you want this, but I'd like to emphasize it. :-)
I'd like to strongly agree with Joachim on this point, also some care
has to be made in even making a sample TDS generally available in
addition to the ctan archives. Which was what I think Rich meant, as
he talked of `extra disks'.
Many packages have distribution conditions saying that all files,
including documentation, should be distributed together. This is fine
for a distribution/archiving structure like ctan.
However it is not what is wanted in the `working' TDS structure.
What this means essentially, is that if you are trying to maintain a TDS
structure that is publically distributed you have to gain permission
from the authors of each individual package to re-arrange their files.
LaTeX is one example of a package that states that all files must be
kept together, but it is not the only one. In the case of LaTeX we do
allow the redistribution in TDS style under certain conditions,
eg Karl's present lib.tar distribution, but as Karl could testify, it
took us a long time to come up with a wording for a document that
allowed this kind of distribution.
David
================================================================================
Archive-Date: Wed, 01 Feb 1995 13:07:12 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Feb 95 19:07:52 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502011907.AA06389@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: latest draft
<para>
The &LaTeX; tree contains an extra level between <replaceable>format</>
and <replaceable>package</> which indicates whether or not the package
is supported by the &LaTeX; development team.
I thought we'd agreed to flatten out that level again, ie
texmf/tex/latex/base/*
texmf/tex/latex/tools/*
texmf/tex/latex/babel/*
texmf/tex/latex/psnfss/*
texmf/tex/latex/seminar/*
texmf/tex/latex/hyperref/*
So this also affects the example at the end:
<programlisting>
texmf/tex/plain
texmf/tex/plain/amstex
texmf/tex/latex/distrib/amslatex
texmf/tex/latex/distrib/babel
texmf/tex/latex/contrib/float
texmf/tex/latex/contrib/psnfss
ie delete distrib and contrib (even as it stands it's wrong as psnfss
counts as distrib under the present arrangements)
<para>
We encourage package authors to build their distribution archives in
a structure that parallels the &tds;. This will make package installation
much easier for the installer and much more regular across packages.
For example, a package for Martian language typesetting might include
the following files:
</para>
Last time this came up, I thought we agreed that doing this would make
ctan unworkably deep. i think that this whole section ought rather say
something along the lines of Joachim's post as to why a ctan archive
is different from tds, and then encourage authors to document (and
possibly automate) how the files should be installed from an archive
into an existing tds tree.
David
================================================================================
Archive-Date: Wed, 01 Feb 1995 13:56:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 1 Feb 95 11:50:48 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502011950.AA11808@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
In case anyone is still wondering, I most certainly did *not* intend that
the current structure of the CTAN be changed to support the TDS. I *do*
wonder, however, whether it might not be useful to make up Info-Zip sets
of files, on a font-by-font basis, that could load cleanly into a TDS-
compliant set of directories. Is this possible in a portable fashion?
Getting back to the original point, however, I am a bit disturbed to find
out about the restrictions on distribution format. It would certainly be
possible to thrash our permissions for at least some of the more common
fonts and such, and perhaps those of us who are interested should get on
with it. If O'Reilly and/or PTF are to publish mountable TDS trees on
CD-ROM, *we* certainly have motivation to do this. And, more generally, I
think the users would benefit from being able to grab pre-built sets of
common fonts. In fact, I kinda thought that was the main point of this
exercise, along with assisting managers of huge TeX systems.
-r
================================================================================
Archive-Date: Thu, 02 Feb 1995 04:45:35 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502021044.LAA13739@spice.iti.informatik.th-darmstadt.de>
Subject: Re: implementation
To: TWG-TDS@SHSU.edu
Date: Thu, 2 Feb 1995 11:44:58 +0100 (MEZ)
Content-Type: text
You wrote:
>
> In case anyone is still wondering, I most certainly did *not* intend that
> the current structure of the CTAN be changed to support the TDS. I *do*
> wonder, however, whether it might not be useful to make up Info-Zip sets
> of files, on a font-by-font basis, that could load cleanly into a TDS-
> compliant set of directories. Is this possible in a portable fashion?
I'd say yes. We ``only'' need (a) volunteer(s) to maintain it.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Thu, 02 Feb 1995 05:06:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 95 11:04:49 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502021104.AA06883@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
> Getting back to the original point, however, I am a bit disturbed to find
> out about the restrictions on distribution format.
This may not be a problem in practice, as I say, for LaTeX we interpret
`must be distributed together' in a sufficiently loose way that a CD
could have the files distributed along TDS lines, as long as they are
all on the CD somewhere. It may be that other authors may take a
similar view, but things may need to be checked.
Personally I can not see much use for maintaining a rapidly changing
public TDS directory. Once the TDS has been finalised, It may be
useful for a basic `TDS-starter kit' ie an expanded version of web2c's
lib.tar, along the lines of Joachim's archive.
However `publishers of `ready installed' CD's will probably want to
have access to a large `sample TDS' and so perhaps it would not do
much harm if that was made publically available.
However I do not see that trying to keep a public TDS archive updated
with whatever stuff has just been contributed to ctan makes much
sense. Most people are never going to need *all* the files in the
contrib areas of ctan, the idea is to pick and choose, so I would be
against making an ever larger tar/zip file, and the only other
alternative appears to be a different zip file for each package, each
unpacking itself into a TDS tree, but as discussed here before, there
is a possibility of the ctan ftp program producing those on the fly
anyway.
David
================================================================================
Archive-Date: Thu, 02 Feb 1995 05:54:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 95 03:49:42 PST
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502021149.AA15627@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
JS> I'd say yes. We ``only'' need (a) volunteer(s) to maintain it.
Well, I see it almost falling out of a reasonable strategy to build a
"complete" TDS tree, as OR and/or PTF needs to do already. As I see it,
the process should be quite possible to automate, presuming that the
input archives don't go wonky on us.
It might also be that some of the maintainers of fonts and such would be
interested in releasing them in a TDS-compliant archive. In other cases,
where the materials are useful but static, a single conversion might do
the trick for quite a while. I'm not discounting the effort involved,
but I *do* think it is manageable, and that some cooperation could keep
the TeX community from duplicating a great deal of effort.
DC> Personally I can not see much use for maintaining a rapidly changing
DC> public TDS directory. ...
I agree. A definitive TDS tree on the CTAN might be useful as a check
on proper installation of local files, but I don't imagine that it would
be a very convenient place to go for files. That's why I like the idea
of TDS-compliant archives that can be poured into an existing TDS tree.
A "starter" TDS tree fits *very* well into this plan.
In order to make a definitive, mountable CD-ROM, of course, the publisher
would have to load in the starter plus all the add-ins. Fully realizing
that any given user will never need most of ther materials, the publisher
can still be content with the fact that the user will be able to find any
materials s/he needs. (Dictionaries contains lots more words than anyone
typically looks up. :-)
DS also hints at the "possibility of the ctan ftp program producing [zip
files in TDS format] on the fly". First time I've heard of this; but it
sounds like it might have possibilities. SPQR, what do you have in mind?
-r
================================================================================
Archive-Date: Thu, 02 Feb 1995 06:01:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 95 12:00:14 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502021200.AA06923@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Name of the TDS Root
The following snippet was part of the mail I sent about the November
draft, but it applies to the latest draft as well:-)
David
<para>
The &tds; is rooted at a directory called <filename role=dir>texmf</>.
The location of
this directory within the file system is up to the installer. On
many systems, this may be at the root of the filesystem; however, on
&unix; systems, this would traditionally be located in
<filename role=dir>/usr/local</>. On PC networks, this could map to a
logical drive specification, for example <filename role=drive>T:</>.
</para>
I am not sure that this captures what I (thought) was decided.
In particular the two cited examples are rather different, I think
that the suggestions are
/usr/local/texmf/
t:/
but I would read the above paragraph as suggesting
/usr/local/texmf/
t:/texmf/
Perhaps something like
<para>
The root of the &tds; should be a directory only containing &TeX;
related material. In this document we shall assume that this directory
is called called <filename role=dir>texmf</>, although the exact name
of the directory is up to the installer. On PC networks, this could
map to a logical drive specification, for example
<filename role=drive>T:</>.
</para>
<para>
Similarly the location of
this directory within the file system is site-dependant. On
many systems, this may be at the root of the filesystem; however, on
&unix; systems, this would traditionally be located in
<filename role=dir>/usr/local</>.
</para>
... or something...:-)
================================================================================
Archive-Date: Thu, 02 Feb 1995 12:56:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 1995 13:51:33 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502021851.NAA06798@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
References: <9502021149.AA15627@cfcl.com>
Reply-To: TWG-TDS@SHSU.edu
On 2 February 1995 at 03:49:42, Rich Morin wrote:
> DS also hints at the "possibility of the ctan ftp program producing [zip
> files in TDS format] on the fly". First time I've heard of this; but it
> sounds like it might have possibilities. SPQR, what do you have in mind?
If package authors were amenable to providing a file that mapped from
their archive arrangement to TDS, it would be possible to write a
wuftpd filter to "do the right thing".
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "I could be chasing an untamed ornithoid without
Production Tools Specialist | cause." -- Lt. Cmdr. Data
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Thu, 02 Feb 1995 12:58:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 1995 13:53:50 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502021853.NAA06856@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Name of the TDS Root
References: <9502021200.AA06923@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 2 February 1995 at 12:00:14, David Carlisle wrote:
>
> The following snippet was part of the mail I sent about the November
> draft, but it applies to the latest draft as well:-)
Just me, lousing up again ;-)
> Perhaps something like
>
> <para>
> The root of the &tds; should be a directory only containing &TeX;
> related material. In this document we shall assume that this directory
> is called called <filename role=dir>texmf</>, although the exact name
> of the directory is up to the installer. On PC networks, this could
> map to a logical drive specification, for example
> <filename role=drive>T:</>.
> </para>
> <para>
> Similarly the location of
> this directory within the file system is site-dependant. On
> many systems, this may be at the root of the filesystem; however, on
> &unix; systems, this would traditionally be located in
> <filename role=dir>/usr/local</>.
> </para>
>
> ... or something...:-)
Suits me. Sorta ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Oh my God! The dead have risen and they're
Production Tools Specialist | voting Republican! -- B. Simpson
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Thu, 02 Feb 1995 12:59:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 1995 13:48:51 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502021848.NAA06729@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: latest draft
References: <9502011907.AA06389@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 1 February 1995 at 19:07:52, David Carlisle wrote:
>
>
> <para>
> The &LaTeX; tree contains an extra level between <replaceable>format</>
> and <replaceable>package</> which indicates whether or not the package
> is supported by the &LaTeX; development team.
>
> I thought we'd agreed to flatten out that level again, ie
Happy to oblige.
> <para>
> We encourage package authors to build their distribution archives in
> a structure that parallels the &tds;. This will make package installation
> much easier for the installer and much more regular across packages.
> For example, a package for Martian language typesetting might include
> the following files:
> </para>
>
> Last time this came up, I thought we agreed that doing this would make
> ctan unworkably deep. i think that this whole section ought rather say
> something along the lines of Joachim's post as to why a ctan archive
> is different from tds, and then encourage authors to document (and
> possibly automate) how the files should be installed from an archive
> into an existing tds tree.
done.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Bill Gates should limit his salary to the number
Production Tools Specialist | of bytes addressable by the latest version of
O'Reilly & Associates, Inc. | MS-DOS, and be taxed based on the number of
90 Sherman Street | bytes of RAM needed by the latest version of
Cambridge, MA 02140 | MS-Windows.
(617) 354-5800/661-1116 FAX |
================================================================================
Archive-Date: Thu, 02 Feb 1995 13:02:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 95 19:01:39 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502021901.AA07217@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
> If package authors were amenable to providing a file that mapped from
> their archive arrangement to TDS, it would be possible to write a
> wuftpd filter to "do the right thing".
If this could be set up, I am sure LaTeX could put such a file in it's
`unpacked' directory so that this could serve as a model to authors of
other packages.
David
================================================================================
Archive-Date: Thu, 02 Feb 1995 13:20:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 1995 14:15:27 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502021915.OAA07086@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
References: <9502021901.AA07217@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 2 February 1995 at 19:01:39, David Carlisle wrote:
>
> > If package authors were amenable to providing a file that mapped from
> > their archive arrangement to TDS, it would be possible to write a
> > wuftpd filter to "do the right thing".
>
> If this could be set up, I am sure LaTeX could put such a file in it's
> `unpacked' directory so that this could serve as a model to authors of
> other packages.
LaTeX is *really* hard, though, because all the files in the unpacked
directory are still "packed" in dtx format, correct?
Don't get me wrong, I understand why it's done this way, but it does
mean that the installer needs to get the files, run latex, etc. etc. etc.
and that's more than a wuftpd packaging script could do (and given the
sort of configuration that you get to do at latex-time, you wouldn't
want it to anyway, right?).
A case like the (now modified) example of martian in the TDS doc is
a more tractable problem.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Thu, 02 Feb 1995 13:23:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 1995 14:18:55 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502021918.OAA07129@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: New draft online...
Reply-To: TWG-TDS@SHSU.edu
With the changes recently discussed. But I haven't really proofed it... ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Thu, 02 Feb 1995 17:53:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 2 Feb 95 19:28:49 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502021928.AA07256@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
> LaTeX is *really* hard, though, because all the files in the unpacked
> directory are still "packed" in dtx format, correct?
> Don't get me wrong, I understand why it's done this way, but it does
> mean that the installer needs to get the files, run latex,
> etc. etc. etc.
The dtx files in the `unpacked' dir are only there for show, they
could be moved straight to a ... (documentation or source:-) directory
> A case like the (now modified) example of martian in the TDS doc is
> a more tractable problem.
Certainly in terms of documenting *how* one should wrte such a file,
what I meant was if the system was there, and we managed to get it
working for the core latex distribution, it would encourage a lot of
other authors to follow suit.
On the other hand it might be best to get the draft finished, without
being sidetracked into writing nifty ftpd scripts....
David
================================================================================
Archive-Date: Fri, 03 Feb 1995 05:15:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Feb 1995 06:10:53 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502031110.GAA18745@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
References: <9502021928.AA07256@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 2 February 1995 at 19:28:49, David Carlisle wrote:
> > LaTeX is *really* hard, though, because all the files in the unpacked
> > directory are still "packed" in dtx format, correct?
>
> > Don't get me wrong, I understand why it's done this way, but it does
> > mean that the installer needs to get the files, run latex,
> > etc. etc. etc.
>
> The dtx files in the `unpacked' dir are only there for show, they
> could be moved straight to a ... (documentation or source:-) directory
I guess I've never paid that much attention. You mean that I could
really run the files in the 'unpacked' directory without any pre-processing?
Cool...
> > A case like the (now modified) example of martian in the TDS doc is
> > a more tractable problem.
> Certainly in terms of documenting *how* one should wrte such a file,
> what I meant was if the system was there, and we managed to get it
> working for the core latex distribution, it would encourage a lot of
> other authors to follow suit.
>
> On the other hand it might be best to get the draft finished, without
> being sidetracked into writing nifty ftpd scripts....
David! How could you think such a thing! ;-)
Tell ya what, since you know files so well ;-), how about providing a TDS
mapping for me?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "It can be shown that for any nutty theory,
Production Tools Specialist | beyond-the-fringe political view or strange
O'Reilly & Associates, Inc. | religion there exists a proponent on the Net.
90 Sherman Street | The proof is left as an exercise for your
Cambridge, MA 02140 | kill-file."
(617) 354-5800/661-1116 FAX |
================================================================================
Archive-Date: Fri, 03 Feb 1995 05:18:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Feb 1995 06:13:56 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502031113.GAA18754@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
References: <9502021928.AA07256@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 2 February 1995 at 19:28:49, David Carlisle wrote:
>
> The dtx files in the `unpacked' dir are only there for show, they
> could be moved straight to a ... (documentation or source:-) directory
Actually, given Joachim's recent statement about seperation of
archiving and TDS operations (widely agreed upon), doesn't it make
*less* sense to put a source tree in the TDS? I mean, that's not
needed to *run* TeX and that's a nice pragmatic way of deciding what
goes in and what doesn't, right?
I agree that for CD distribution, the source has to be there, but there's
nothing that says it has to be in TDS format. On the other hand, if we
need the TDS to start in the root of the CD, we'll need an escape hatch...
Maybe "texmf/source"?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Fri, 03 Feb 1995 05:33:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Feb 95 11:32:15 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502031132.AA07719@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation
> > The dtx files in the `unpacked' dir are only there for show, they
> > could be moved straight to a ... (documentation or source:-) directory
> Actually, given Joachim's recent statement about seperation of
> archiving and TDS operations (widely agreed upon), doesn't it make
> *less* sense to put a source tree in the TDS?
Yes this is a problem, and why I did not fill in the dots above.
On one hand, I agree with Joachim that the TDS should not really say
anything about sources, and that one might want to consider most of
the latex/base dtx files as source rather than documentation.
However if we really are contemplating automatic scripts to move stuff
from a ctan style setup to a TDS, these scripts have to move *.dtx
somewhere (NOT /dev/null:-). Whatever `somewhere' is in the script,
is likely to become a defacto extension of the TDS tree even if we try
and document that it is only a `suggestion' and that sources can be put
anywhere. (If the scripts work, nobody will read our documentation...)
David
================================================================================
Archive-Date: Fri, 03 Feb 1995 05:58:21 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502031155.MAA13902@spice.iti.informatik.th-darmstadt.de>
Subject: Re: implementation
To: TWG-TDS@SHSU.edu
Date: Fri, 3 Feb 1995 12:55:43 +0100 (MEZ)
Content-Type: text
Norm wrote:
>
> Actually, given Joachim's recent statement about seperation of
> archiving and TDS operations (widely agreed upon), doesn't it make
> *less* sense to put a source tree in the TDS? I mean, that's not
> needed to *run* TeX and that's a nice pragmatic way of deciding what
> goes in and what doesn't, right?
>
> I agree that for CD distribution, the source has to be there, but there's
> nothing that says it has to be in TDS format. On the other hand, if we
> need the TDS to start in the root of the CD, we'll need an escape hatch...
> Maybe "texmf/source"?
Hasn't texmf/src/<system>/<package> already been discussed in the
past? More missing points will be mentioned in a further mail (I have
to read the current draft first, to check them again...)
I'm all in favor for specifying a directory for sources. It should be
listed as one element in the set of ``additional directories [to] be
used for other standard purposes'', like bin/, ini/, etc.
"src/web2c/, src/latex/base, etc." are IMO a good example list for
that item. (Btw, I don't care for the name `src', I would use
`source', too. It's just my Unix-oriented attitude that shows off. :-)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 03 Feb 1995 07:04:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Feb 1995 08:00:03 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502031300.IAA20052@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Three new directories...
Reply-To: TWG-TDS@SHSU.edu
Going back through recent discussions and a paper posted (or emailed to me?)
by David Rhead, I have three suggestions:
1) As Joachim suggested, a standard "acceptable other" place for sources:
/texmf/source/<format>/...
/texmf/source/<whatever>/...
2) A place for local packages and styles:
/texmf/local/<format>/...
3) A place for local fonts:
/texmf/fonts/<type>/local/<typeface>/...
Here, texmf/local is for local TeX stuff and texmf/fonts/.../local is
for local fonts. Since the "source" of a font could arguably be
"local" for the font tree, that seems better than trying to go with
"/texmf/lcltex" and "texmf/lclfont" or some such. Or do you disagree?
My gosh, are we actually getting close to the end? ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Fri, 03 Feb 1995 07:20:18 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502031319.OAA16518@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Three new directories...
To: TWG-TDS@SHSU.edu
Date: Fri, 3 Feb 1995 14:19:47 +0100 (MEZ)
Content-Type: text
Norm wrote:
>
> 2) A place for local packages and styles:
>
> /texmf/local/<format>/...
>
> 3) A place for local fonts:
>
> /texmf/fonts/<type>/local/<typeface>/...
I don't like this.
If one needs to add local stuff in a single place (I can see the
reason why), one can set up *another* texmf tree, and add both trees
to the search paths (the local one first, usually). I.e.,
/usr/lib/texmf and /usr/local/lib/texmf, so to speak.
IMO, the other solution (texmf/local/) leads to problems with file
searches: Typically such a local (sub-)tree is not only used for
enhancements, but also for local replacements. The `system part' is
then assumed to be on a read-only network file system, or a CD, or
similar. Search paths like `$TEXMF//cm//' cannot be used any more,
while they are currently non-amiguous. But
`$LOCAL_TEXMF//cm//:$TEXMF//cm//' is still workable.
Bottom line: Let me make a counter proposal:
2+3) Add an explicit hint that more than one texmf tree may be
available and should be usable in an installation. In particular, the
constellation of one texmf tree that is an (unchanged) distribution
and another texmf tree for local adaptions/enhancements/replacements
is not uncommon.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 03 Feb 1995 10:56:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Feb 95 16:18:16 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502031618.AA07821@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Three new directories...
> Bottom line: Let me make a counter proposal:
This looks like a good idea to me, especially if people are going to
be using a TDS tree directly off a CD, they are going to have to do
this anyway, so formalising this as a general method for keeping
local things separate from a distributed setup sounds interesting.
Probably having `local' further down the tree is more like current
practice, but ... .
Wherever `local' goes there was also Alan's proposal that we suggest
using a `site name' eg `sussex' rather than `local' to aid merging
style collections from different sites.
David
================================================================================
Archive-Date: Fri, 03 Feb 1995 11:59:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Feb 1995 11:38:31 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502031638.LAA24416@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Three new directories...
References: <199502031319.OAA16518@spice.iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
On 3 February 1995 at 14:19:47, Joachim Schrod wrote:
> Bottom line: Let me make a counter proposal:
>
> 2+3) Add an explicit hint that more than one texmf tree may be
> available and should be usable in an installation. In particular, the
> constellation of one texmf tree that is an (unchanged) distribution
> and another texmf tree for local adaptions/enhancements/replacements
> is not uncommon.
Sounds good to me! Solves a lot of ugliness.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Life is like arriving late for a movie, having
Production Tools Specialist | to figure out what was going on without
O'Reilly & Associates, Inc. | bothering everybody with a lot of questions, and
90 Sherman Street | then being
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Fri, 03 Feb 1995 13:59:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 3 Feb 1995 13:44:31 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502031844.NAA27471@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: Three new directories...
References: <9502031618.AA07821@r8d.cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
On 3 February 1995 at 16:18:16, David Carlisle wrote:
>
> Wherever `local' goes there was also Alan's proposal that we suggest
> using a `site name' eg `sussex' rather than `local' to aid merging
> style collections from different sites.
>
True, but seperate trees just fixes the whole mess. A user can have
/cdrom/texmf:/usr/local/sussex/texmf:/usr/local/mainze/texmf
etc. Or even just
/cdrom/texmf:/usr/local/sussex:/usr/local/mainze
the extra texmf layer isn't really necessary on local disks. Although
I *really* want to see it on the CD-ROM.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If you understand: things are as they are. If
Production Tools Specialist | you do not understand: things are as they are.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Wed, 08 Feb 1995 07:32:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 8 Feb 1995 08:27:36 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502081327.IAA01710@jasper.ora.com>
To: vojta@math.berkeley.edu (Paul Vojta)
CC: twg-tds@shsu.edu
Subject: Re: comments on twg-tds draft
References: <199502022328.PAA12698@tashkent.berkeley.edu>
Reply-To: TWG-TDS@SHSU.edu
On 2 February 1995 at 15:28:48, Paul Vojta wrote:
> Norm:
>
> Here are some comments I have about the draft twg-tds standard:
Thanks. Spelling and gramatical errors corrected.
> 4. A question:
>
> Will .ps files (e.g., .ps header files for dvips)
> need to implement a subdirectory searching algorithm?
>
> Note that xdvi will likely share many header files with dvips.
I don't think so. Information for dvips can reasonably go in
texmf/dvips
and the organization can be whatever is convenient for dvips/xdvi/etc.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The eternal mystery of the world is its
Production Tools Specialist | comprehensibility." -- A. Einstien
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Wed, 08 Feb 1995 10:42:57 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Wed, 8 Feb 1995 08:42:45 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502081642.IAA00250@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: mackay@murad.classics.washington.edu
Subject: comments on twg-tds draft
Has anyone else noticed the subtle effect of genuine rationality
in the example in section 9?
Section 5.2 despairs of the {\it source}-first organization, but there it
is again in Section 9. I don't hold out any hope for a return to
{\it source}-first as opposed to {\it type}-first, even though the
latest version of kpathsea searching on my creaky old no-memory
Sun 3-50 strongly validates Karl's claims for it. But the example
will need to be consistent with the recommendations in 5.2 whatever
they are.
I should like also to plead for the retention of the {\it public}
designation for a wide range of fonts and, on the whole, even to put
cm among them. DEK is really not a foundry, and I doubt that he
really cares whether he is advertised as one. Karl Berry and I talked
this out a while ago, and I think I was able to make the point that
{\it public} can be used to designate fonts for which there is no
problem of licensing when you send them out. Most foundry fonts, at
least in glyph form (and that includes PK renderings of Type1
outlines) can only be delivered to those who can show that they have
valid licences for that specific font. Those that are specifically
freed up for public distribution have traditionally (in the UnixTeX
world at least) gone into {\it public} because {\it public} expresses
their licensing situation better than any other term we could think
of. Of course there are anomalies. Part of Adobe Utopia (by no means
all of it) has been made available without restriction, Bitstream
charter, IBM Courier and the odd collection of URW fonts.
(Incidentally, how widely are people aware that Nimbus Roman is an
open-license Times and Nimbus Sans is an open-license Helvetica?) I
don't see any point in splitting hairs about this. I am not arguing
that these fonts be crammed into {\it public} just because their
licensing conditions are not the same as those for the remainder of
the foundry's fonts. But for the general run of METAFONTS and for any
others that may arrive perhaps in a different coding, {\it public}
seems a good catch-all rubric, and it actually conveys something to
the user.
Incidentally, does anyone know the status of Symbol and NewCenturySchoolbook?
There has been some suggestion that these are open-license too.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| I will continue unofficially to provide tape distributions and |
| any other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
Archive-Date: Mon, 13 Feb 1995 05:54:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 06:54:07 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131154.AA01112@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: architecture- and implementation-dependent directories
The current TDS allows:
\item[\filename{bin}/\replaceable{system}] for binaries
I think system/bin is also ok ... I don't think we can possibly (or need
to) legislate whether a site wants sun4/bin or bin/sun4.
\item[\filename{ini}/\replaceable{system}]
for pool files, format files, and base files.
I'm puzzled by this. I thought we were suggesting `emtex', `web2c',
etc., as top-level directories, like `makeindx' and `bibtex'. That would
make the need for an ini directory (and this paragraph) go
away. (Despite my fondness for the name...)
Also, I think we should allow a top-level directory `info' for the
program-readable .info files produced from Texinfo source.
================================================================================
Archive-Date: Mon, 13 Feb 1995 05:54:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 06:54:07 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131154.AA01120@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: type1 fonts in the tds
The current draft of the tds has:
\item[\filename{pfa}] Type 1 fonts in \filename{PFA} format
\item[\filename{pfb}] Type 1 fonts in \filename{PFB} format
I don't see anything in the archives that explains why we're
distinguishing these. It would simplify the paths to put them in one
directory, called, say, `type1'.
In practice, I think
1) it's highly dubious that people will have both a pfa and a pfb for
the same font; so we're not making the directories any smaller by
separating them.
2) every extant program can read both kinds if it can read either (at
least ghostscript and dvips can; not sure about ps2pk). So it's
not making any practically useful distinction to separate them,
either.
Put another way, every time .../pfa is put in someone's path, .../pfb is
needed also. So let's make everyone's life easier and put them together
in the first place.
================================================================================
Archive-Date: Mon, 13 Feb 1995 05:54:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 06:54:10 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131154.AA01144@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: bibtex
I think there should be a chapter on bibtex in the tds -- it needs to be
almost as long as the chapter on Metafont :-). E.g.,
The TDS specifies two subdirectories of the top-level `bibtex'
directory:
bib -- for bibliography (.bib) files
bst -- for bibtex style (.bst) files
Rationale: this is in line with the general approach of the TDS to put
files of a particular type in a common directory.
================================================================================
Archive-Date: Mon, 13 Feb 1995 05:54:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 06:54:08 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131154.AA01128@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: fonts/knuth?
The current tds draft has:
[for a font source] \literal{knuth} for the
original Computer Modern fonts
As Pierre wrote, I don't see the necessity for this. It's just another
directory where users and programs have to look for stuff. It's not like
its contents are going to be enlarged, ever again.
So I suggest we merge cm into public.
(In any case, it wouldn't be just the ``original Computer Modern
fonts'', but also concrete and logo and manfnt, presumably...)
================================================================================
Archive-Date: Mon, 13 Feb 1995 05:54:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 06:54:09 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131154.AA01136@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: the initex directory
I hate to reopen this discussion, but the current draft of the tds
specifies a top-level initex directory.
Doesn't such a thing imply another whole set of things that have to go
in the paths, and where people & programs have to look?
I'm not sure I see the need. In the old mail, the things suggested for
it were
1) base files, like plain.tex and latex.ltx. Surely people would be more
inclined to find these in tex/<format>/base?
2) Joachim's unnamed initex-only files. They could be considered as
a package (if they aren't already) and put in tex/<package>?
3) hyphenation files. Could go in tex/hyphen.
Is there a practical advantage to the top-level initex/ to outweigh the
practical disadvantage?
By the way, these things kind of worry me. I'm just reading the
document, not actually trying to make a system [yet] that conforms to
it. I don't think the TDS should be declared official-and-accepted until
several implementations are actually distributing something that
conforms to it. Otherwise, we're just playing theoretical games.
================================================================================
Archive-Date: Mon, 13 Feb 1995 05:54:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 06:54:05 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131154.AA01104@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: editorial comments
Editorial comments only, no one but Norm needs to read :-), sending to
the list only for archiving.
(Sorry, but the quotes are from the TeX document, not the SGML; I
neglected to retrieve that :-(.)
General comment #1: I don't see that the filename needs to have `twg-' in it.
General comment #2: I think `Unix' looks a lot better as `Unix' than
`\textsc{UNIX}'.
\title{A Directory Structure for Implementation-Independent {\TeX} Files \\ Version 0.61}
We talk about implementation-specific files as well, and I think it's
good for titles to be short and catchy, so how about tossing
`Implementation-Independent'.
to install it. This has resulted in hundreds of slightly different
... slightly (or not so slightly) different
(Text changes below not otherwise rationalized are just what struck me
as slightly improved wording as I was reading.)
structure for macros, fonts, and other implementation-independent {\TeX}
... other such
In the long run a consistent directory structure will make it
In the not-so-long run ...
work on all modern architectures. In particular, it can be used
`systems' instead of architectures, I think. Hardware seems irrelevant!
on \textsc{UNIX} workstations, \acronym{MS-DOS} and \acronym{OS/2}
\acronym{PC}'s, Macintoshes, and \acronym{VMS} machines.
under Unix, MS-DOS, OS/2, Macintoshes, and VMS.
(Also, by the way, \acronym is technically wrong here -- an acronym is
an abbreviation that's pronounced as a word: NASA and FAQ are acronym;
FBI (and VMS and PC and ...) are just abbreviations. No, I'm not saying
you have to change the control sequence name :-)
local system uses the \TeX\ Directory Structure.
... Structure recommended here.
(Also, I suggest saying the `\TeX Directory Structure (TDS)' here, and
then using `TDS' in most of the rest of the document. You already do
occasionally, and I think it would be clearer/shorter to use it
routinely. It's a single concept, after all. And you use TWG ...)
files into a single unit; for the purposes of use, it is frequently
more useful to segregate files (even similar files) from a single
..., it is traditional to segregate files ...
(Aside from the repeated `use...useful', what's ``useful'' is not the
same at every site.)
\subsection{Conventions}
A non-typographic convention you should note is that ``This document
uses / to separate filename components, as on Unix, purely
arbitrarily. The ideas are in no way Unix-specific.'' Or some such.
Filenames are represented in constant width.
`constant width' is not a term I've ever heard used as a noun. How about
simply `typewriter type'? Or `monospaced type', if you want to be fancy.
\item[\command{command}]
Commands are represented in italics.
Italics are fine, but `command' got printed here in bold italics,
probably because it's in a LaTeX \description. Yuck.
Literal text, things that you should type explicitly,
is represented in constant width.
`constant width' weirdness, as above. It's not exactly that you should
type them, either -- this isn't a user manual. I think `Literal text' is
clear enough by itself.
Replaceable text, like \replaceable{filename},
identifies a class of things. You should specify some member of
that class. Replaceable text is represented in constant width
oblique.
1) `constant width' again.
2) The `replaceable' wasn't printed in italic typewriter here, but
regular bold italic.
3) I think `package' would be a better example than `filename'.
4) The sentence `You should specify...' can be tossed, I think, as above
about typing.
5) I suggest we use cmsltt10 for this stuff. It's always part of a
filename (isn't it?), so some form of typewriter seems appropriate,
rather than regular italics. cmitt10 is a truly weird-looking font; I
think cmsltt10 is much cleaner.
\subsection{Subdirectory Searching}
Instead of making this part of the `Introduction' chapter, how about a
new chapter 2, `Basics' or some such, and put this, Constraints, Rooting
the tree, and Top Level Directories under it. I think that last should
not be a subsection of Rooting, either.
system configuration file, for example), but this is insufficient in
the general case.
I don't know what `in the general case' means. Sounds like handwaving to
me :-). How about `this is so cumbersome as to be unworkable at large
sites'?
On systems without runtime configuration files,
without some form of runtime configuration
(Envvars would suffice, doesn't have to be config files.)
As a result, the TWG decided that a comprehensive \TeX\ Directory Structure required
`concluded' is better than `decided', I think. It wasn't an arbitrary
decision. And here is a primse place to start `TDS' instead of `TeX
Directory Structure'. Those capital letters in the middle of a sentence
are disconcerting.
to specify that {\TeX} (and other {\TeX} utilities) search in both a
`and Metafont and their companion' instead of `other \TeX`?
specified directory and recursively through all subdirectories of that
... and implicitly recursively ...
(I think it's important to get the idea of ``implicitly'' across here;
we mean you specify a single directory name and the program does the
recursion, but that's not necessarily obvious from the present wording.)
directory when looking for an input file,
that is, a {\TeX} macro file, \filename{TFM} file, or a
\filename{PK}
bitmap font.
There's a lot more kinds of input files than those! (.bst, .mf, ...). I
suggest just deleting `that is ... bitmap font'.
Windows-NT, Macintosh, NeXT, and other systems) and the \application{em{\TeX}}
NeXT is Unix, no need to mention it separately.
distribution for \acronym{MS-DOS} and \acronym{OS/2}
Missing period at end of sentence.
This TWG recognizes that subdirectory searching places an extra burden
The TWG recognized ...
As an immediate consequence of the search strategy outlined
I'm not sure it's ``immediate''.
above, one cannot place variants of a file with the same name in
Well, you *can*. I mean, it's physically possible. I suggest wording
something like this:
... above, two files in a search path with the same name leads to
ambiguity. The TDS does not define which one is found. To disambiguate
this case, one must specify a search path that lists the respective
subtrees in the search order as needed.
(But, I have comments on your text, in case you keep it:)
If one wants to use diffferent versions, one has to specify
Three f's.
a \systemitem{ENVIRONVAR}{TEXINPUTS} search path that lists
You don't want to particularize to TEXINPUTS here.
the respective subtrees in the search order as needed. Then the file
.... Then the filenames
Having accepted that subdirectory searching was necessary, the TWG
agreed to adhere to the following constraints in designing the \TeX\ Directory Structure.
... the TWG adhered ...
(The only people we agreed with were ourselves!)
problem is surmountable. In particular, note that \acronym{MS-DOS},
... In particular, on
(I have an aversion to ever saying `Note that', since it's 100%
redundant with itself, and you can say that again.)
\textsc{UNIX} platforms can use symbolic links (that most of them now support)
The remaining case is Unix, but Unix systems can use hard or symbolic links
[and delete the parenthetical, or move to after the next sentence.]
Automatic font generation is a big win on systems that do not have
access to scalable fonts. It is important that the \TeX\ Directory Structure not restrict
... big win on TeX systems, since then Computer Modern and other such
bitmapped fonts can be used at any size without human intervention.
(It has nothing to do with scalable fonts...)
the applicability of automatic font generation. The arrangement
I don't see the ``constraint'' here, though. What does automatic font
generation imply for the needs of a TDS? Nothing that I can see.
If this bulleted item goes, so can the other one, and it just be the
main text of the section.
is called called \filename{texmf}, although the exact name
Only one `called'.
Similarly the location of
Comma after `Similarly'.
many systems, this may be at the root of the filesystem; however, on
No `however'.
\filename{/usr/local}.
or /usr/local/lib.
it reflects the fact that the directory contains more than {\TeX} files
(it also contains fonts), it is likely to be unused, and it is
Not only does it also contain fonts, it contains BibTeX inputs, etc.,
etc. Something like: the directory contains files to an entire TeX
system, including Metafont, BibTeX, etc., not just TeX itself.
The \filename{texmf} root \emphasis{should not} be placed
`is not intended to be' instead of `should not'? I don't see any dire
consequences resulting from doing this. The crucial thing is that the
TDS already makes provision for the implementation-specific files, so
there's no point to putting them outside the tree.
under a system-dependent directory. For example, \filename{texmf}
should not be created in the \filename{emtex} or \filename{pctex}
directories!
The ! seems like overkill.
Awareness of the fact that storing all of the {\TeX} files (including
system-dependent files such as binaries) under a single tree can be very
useful, has resulted in a few extensions within the \TeX\ Directory Structure to allow these
files to coexist.
I don't see that this has anything much to do with `rooting the
tree'. Anyway, you already have substantially the same text in the next
section, so I'd delete it here.
[tex] for the input files used by {\TeX}.
May as well have a ref to the relevant chapters for each of these.
\item[\replaceable{utility}]
This came out in the wrong font (bold italic), as discussed above.
Also, instead of `utility', how about `program', and have `emtex' and
`web2c' as other examples.
As I'll write in a subsequent message, I think `bibtex' should have its
own line (and chapter).
administration if the {\TeX} tree is maintained by someone other than
adminstration, especially if ...
(It's good even if texadmin == sysadmin.)
be used for other, standard, purposes (at the discretion of the installer
and system administrator):
`installer and system administrator' => `TeX administrator'?
Also, I would combine the following list with the previous list, so
there is one and only one list of top-level directories. I don't see any
need to separate them. Put the `Although designed...' paragraph
afterwards, and just say `not all these directories may be needed by all
sites' beforehand.
\item[\replaceable{utility}]
for \replaceable{utility} configuration files
(e.g. \filename{dvips}, \filename{bibtex}, \filename{makeindx},
etc.).
Already had this in the previous list. (I would add `dvips' to the list
of examples along with `makeindx'.) So can delete it here.
The \replaceable{system} directories allow multiple
implementations to share the common directory structure. For example,
the binaries for em{\TeX} might be installed in \filename{/texmf/bin/emtex}.
I think the word `system' is being overloaded here. texmf/bin/emtex is
fine -- but Unix binaries require a directory per architecture, not per
TeX implementation.
The current practice of lumping files into a single directory (or a
The common current practice ...
(There's no such thing as ``the'' current practice, or we wouldn't have
needed to create a TDS in the first place!)
To combat this maintenance problem, the \TeX\ Directory Structure specifies that macros
How about `help solve' instead of `combat'? Or `ameliorate' or `ease'?
\replaceable{format}\filename{/}
The spacing looks funny here (and in all other similar places) --
there's a space after the / (due to the eol), but none before. I don't
have strong feelings about which it should be (maybe no space to match
the no spaces in the literal `texmf/tex'?) but at least it should be
consistent.
examples of \replaceable{format}. Note that some of these
Note that => Although
For some formats, it may be natural to search more than one format
directory. For example, the \filename{amstex} and
\filename{plain}, and \filename{generic}
directories may be searched when using {\AmS}{\TeX}.
Thus, for almost every \replaceable{format}, it is correct to search the
format directory, and then the generic directory (in that order).
It may be necessary to search other directories as well. For example,
the \filename{amstex}, \filename{plain}, and \filename{generic}
directories should be searched when using {\AmS}{\TeX}.
(In any case, note you have an extra `and' after \filename{amstex}.)
Also, before this paragraph, I think we should explain the intended
difference between `plain' and `generic' (or maybe this should be
combined with your current text in some way):
The plain/ directory is intended for files which are only useful with
the plain TeX format: fontchart.tex, testfont.tex, story.tex,
manmac.tex, webmac.tex, etc., as well as plain.tex itself. The generic/
directory, by contrast, contains files which can be used with LaTeX
and/or AMSTeX as well as Plain: btxmac.tex, path.sty, texnames.sty,
null.tex, etc.
Packages that consist of \emphasis{only} a single file shall be
installed in the \filename{misc} package directory.
How about formats that have no subpackages and consist only of a single
file? I think it should be tex/texinfo/texinfo.tex, not
tex/texinfo/base/texinfo.tex.
(This should probably be a separate paragraph in the `format' item.)
For packages that consist of a single file, it seems pointless to
nest them within a directory of their own.
It seems pointless to nest such a package/file within a directory of
its own.
(Avoid repeating the `packages that consist' clause.)
The arrangement
actually adopted tends to spread files out into two or three places
(consider a package which includes extensive documentation and fonts).
Huh? We should only talking about TeX inputs here, shouldn't we? I'm
glad we have this section, and I think it's important, but I think it
should be somewhere else. An Is there a better way for the whole thing?
It has been demonstrated that this arrangement is usable in a production
environment whereas the alternative would be much more experimental.
In addition, several members of the TWG already have arrangements that are
similar to the \TeX\ Directory Structure and the CTAN archives have
a similar arrangement.
The fact that several members ... similar to the TDS demonstrates that
this arrangement is usable (proof by example). The alternative
arrangement is not in use at any known site, and the TWG felt it wrong
to mandate something with which there is no practical experience.
(I think the CTAN stuff is irrelevant to the argument.)
\section{{\protect\MF}}
How about `Non-font \MF inputs' as a name?
\filename{texmf/mf/mf}
What's the point of the extra mf/? What else goes in texmf/mf besides
these random files?
\filename{texmf/fonts/\replaceable{type}/\replaceable{source}/\replaceable{typeface}/\replaceable{files}}
Oh, I see, \replaceable comes out differently inside \filename than
outside. (In this case, it comes out as cmitt10, but everywhere else in
the document, it's regular italic.) Anyway, I'm still voting for
cmsltt10 everywhere, for the umpteenth time :-).
Font sources ({\protect\MF} files, property lists, etc.)
Uncapitalize the `Font'. Or else put a period at the end of the line.
Virtual fonts
virtual font metrics
(Trying to distinguish from .vpl here ...)
\filename{PK} bitmapped fonts
Just `PK files', I think. You didn't say `TFM font metric files'...
is the name of the font vendor or ``\filename{public}'' for
I think we should have the rationale for `public' here, from, e.g., that
recent message of Pierre's: it serves a good practical purpose. We don't
mean to necessarily be separating out the fonts you pay for from the
fonts you can get for free (e.g., Utopia, etc.) Make `ams' one of the
example sources, and that will be even clearer.
Also, there's no need for ``...'' around public, I think. The font
change to typewriter is enough. You don't quote anything else.
Perhaps it would be good to mention `Filenames for fonts' as a list of
sources (and typefaces, in the next item).
and \literal{latex} for the
extensions to Computer Modern distributed by the {\LaTeX} team.
I don't see this as a special case; latex seems like a perfectly
reasonable source to me. Also, it's not just extensions to Computer
Modern but the lasy* fonts as well. I'd just drop this phrase and add
`latex' as another example source.
I don't see knuth as a special case, either, but I'm arguing against
that in a separate msg.
type of printer (mode) for which the font was created and the
`device' would be more correct than `printer'.
directories. To identify the resolution, there are two common ways of
I think this second `To identify' should start a new paragraph.
For example, the same 300dpi bitmap would be named
\filename{cmr10.pk} in the directory \filename{300dpi}.
... would be named dpi300/cmr10.pk.
(It is typically dpi300 and not 300dpi, isn't it?)
Since long filenames are technically impossible on many file systems,
... are not allowed by many ... (ref constraints)
the \TeX\ Directory Structure has adopted the latter scheme for
the TDS must use the latter ...
naming fonts. Under the \filename{pk} directory, two more
fonts. Therefore, under the ...
\filename{ljfour}, \filename{canoncx}, and
cx, please, not canoncx.
Maybe mention modes.mf as a reference list?
For PostScript fonts rendered as bitmaps with the \command{ps2pk}
program, the mode \filename{ps2pk} should be used.
Ditto gsftopk.
consist of the string \filename{dpi} followed by the numeric
value of the resolution in decimal. \filename{dpi300},
\filename{dpi328}, and \filename{dpi1404} are
Rounded value or truncated value? Presumably the former. Then you want
dpi329, not 328.
The \TeX\ Directory Structure recommends the use of \filename{dpi300/cmr10.pk} for font
We don't recommend, we specify or mandate. In this case, anyway.
Also, I'd move this paragraph down to `Is there a better way'.
naming syntax as it is the
least-common-denominator (and therefore most portable) form. Extensions
... as it is the only portable form across present-day operating
systems. Extensions
and (b) neither gain nor loss of functionality accrues from this
variation.
Do you have any particular gain or loss in mind? I can't see how there
could be any. I'd just drop this clause.
There was almost immediate recognition within the TWG of the fact that
the use of short filenames has many disadvantages.
The TWG recognizes that the use ...
same name (\filename{cmr10.pk} identifies Computer Modern Roman 10pt
at 5--10 magnifications for 2--3 resolutions on many
systems).
same name. At a typical site, cmr10.pk will be the filename for Computer
... resolutions.
Within the \TeX\ Directory Structure, every \filename{PK} file \emphasis{must} contain
The TDS specifies that PK files must contain
This may seem autocratic, and perhaps, strictly speaking,
No perhaps about it. But I don't think it matters. We don't need to
apologize for it; I think maybe this paragraph can be tossed.
file derived from Karl Berry's \filename{modes.mf} distribution, the
derived from (or is in fact)
No other issue caused as much
heated debate among the members of the committee as the issue of the
font directory structure.
The TWG struggled more with the font directory structure than anything else.
little more we can do.
In other words, we're standardizing on something known to be insufficient.
Oh, well.
(I'm just randomly complaining, ignore me.)
packages themselves, but it seemed to be important that users find
source files for the packages, but ...
is a nuisance. And since developers and distributors bemoan all the
time that users don't read their documentation, it is important that
no additional barriers are introduced. For these reasons, we decided
Don't see the need for this sentence (And since ...).
find the particular documentation they were after.
In addition to this: we've already split up a package's file all over
creation, so the doc files may as well follow along.
for each package, in a tree like the \filename{tex}
... tree paralleling ...
Miscellaneous help
and information files (like the \acronym{FAQ}) should be stored in
the directory
\filename{help} and general purpose documents
should be stored in the directory \filename{general}.
Two special categories: `help' for metainformation, such as FAQ's,
David Jones' macro index, etc. `general' for standalone documents not
part of any package: Michael Doob's A Gentle Introduction to TeX,
Joachim Schrod's Components of TeX, texbook.tex and mfbook.tex, etc.
(I think we should make the distinction a little clearer.)
to document (or automate) how the files should be moved from the
(or, preferably, automate)
For example, a package for Martian language typesetting might include
the following files:
... might be distributed as the following:
the working TDS structure which looks something like this:
Delete `something'.
\section{Example}
Instead of `Example', I think we should make this `Summary', and provide
not just a minimal set of directories, but (more or less) every
directory in a small-but-real system.
I think this would also help pull together everything from the preceding
text.
I'll work on this, unless you have some problem with it!
texmf/fonts/knuth/cm/pk/canoncx
texmf/fonts/knuth/cm/pk/canoncx/dpi300
cx, not canoncx
texmf/tex/plain/amstex
Is there something in particular that goes in here?
I can't even think what something like this would mean -- wouldn't all
amstex files go in texmf/tex/amstex?
That's it!
================================================================================
Archive-Date: Mon, 13 Feb 1995 08:43:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 13 Feb 1995 09:42:47 -0500 (EST)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: fonts/knuth?
To: TWG-TDS@SHSU.edu
Message-ID: <792686567.936052.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
although i agree with pierre and karl that the knuth fonts are
"public", i think it's valuable to be able to identify which are
the *original* set and which are extensions, as the additional
sizes of cmmib in amsfonts and even more in the sauter complement.
for that matter, the amsfonts and those generated by the sauter
parameters are also "public" in the sense considered, but it would
also be useful for these to be separately identifiable.
at ams, we are now accepting papers for our publications in dvi
form. the policy on fonts is that either the knuth or amsfonts
can be used with no restriction, but that any other fonts either
require special prior arrangements or will be rejected. recently
we received a paper that used cmss7, a size that was in neither
the knuth nor the amsfonts complement. we were on the point of
rejecting it, but found that cmss7 had been implemented here
for a special request. even then, i'm not certain that the
checksums matched. we need to make these restrictions in order
to minimize the amount of time needed for processing, and if
authors are to be able to comply with our restrictions, they
have to be able to figure out with a mimimum of hassle exactly
what they are allowed to use. combining all "public" fonts
into one bucket won't be helpful in that situation.
-- bb
================================================================================
Archive-Date: Mon, 13 Feb 1995 09:00:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 09:55:10 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131455.JAA01065@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: bibtex
References: <199502131154.AA01144@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 06:54:10, K. Berry wrote:
> I think there should be a chapter on bibtex in the tds -- it needs to be
> almost as long as the chapter on Metafont :-). E.g.,
>
> The TDS specifies two subdirectories of the top-level `bibtex'
> directory:
>
> bib -- for bibliography (.bib) files
> bst -- for bibtex style (.bst) files
>
> Rationale: this is in line with the general approach of the TDS to put
> files of a particular type in a common directory.
Actually, I thought I had removed references to the 'bib' and 'bst'
directories. Where did you find them?
Anyway, I removed them because I didn't want it to look like we were
playing favorites. Yes, BibTeX is used by *a lot* of users, but there
are many that don't use it at all and many that use tib instead, etc.
I relegated BibTeX to the "utility" category (page 6).
I could be convinced to move BibTeX back up, but is it really necessary?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Knowing how things work is the basis for
Production Tools Specialist | appreciation, and is thus a source of civilized
O'Reilly & Associates, Inc. | delight." -- William Safire
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Mon, 13 Feb 1995 09:02:48 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 09:58:17 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131458.JAA01368@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: fonts/knuth?
References: <199502131154.AA01128@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 06:54:08, K. Berry wrote:
> The current tds draft has:
>
> [for a font source] \literal{knuth} for the
> original Computer Modern fonts
>
> As Pierre wrote, I don't see the necessity for this. It's just another
> directory where users and programs have to look for stuff. It's not like
> its contents are going to be enlarged, ever again.
>
> So I suggest we merge cm into public.
Unlike other "public" fonts, the Knuth fonts are special. They are
absolutely required to run TeX (you can configure TeX so that isn't
true, obviously, but who does?).
They also have special significance to the AMS, as Barbara pointed
out.
It's also a nod to the Grand Wizard.
> (In any case, it wouldn't be just the ``original Computer Modern
> fonts'', but also concrete and logo and manfnt, presumably...)
True. That doesn't bother me too much, though.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | When they took the fourth amendment, I was quiet
Production Tools Specialist | because I don't deal drugs. When they took the
O'Reilly & Associates, Inc. | six amendment, I was quiet because I'm innocent.
90 Sherman Street | When they took the second amendment, I was quiet
Cambridge, MA 02140 | because I don't own a gun. Now they've taken the
(617) 354-5800/661-1116 FAX | first amendment and I can't say anything at all.
================================================================================
Archive-Date: Mon, 13 Feb 1995 09:05:02 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 10:00:31 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131500.KAA01581@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
References: <199502131154.AA01112@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 06:54:07, K. Berry wrote:
> The current TDS allows:
>
> \item[\filename{bin}/\replaceable{system}] for binaries
>
> I think system/bin is also ok ... I don't think we can possibly (or need
> to) legislate whether a site wants sun4/bin or bin/sun4.
Fair enough.
>
> \item[\filename{ini}/\replaceable{system}]
> for pool files, format files, and base files.
>
> I'm puzzled by this. I thought we were suggesting `emtex', `web2c',
> etc., as top-level directories, like `makeindx' and `bibtex'. That would
I don't remember saying that. The purpose of bin/system and ini/system
was for "bin/emtex" and "ini/emtex". As you note abouve, "emtex/ini"
and "emtex/bin" are equivalent.
> Also, I think we should allow a top-level directory `info' for the
> program-readable .info files produced from Texinfo source.
Agreed.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Debugging is 99% complete most of the time" --
Production Tools Specialist | Fred Brooks, jr.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Mon, 13 Feb 1995 09:12:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 10:08:21 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131508.KAA02314@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
References: <199502131154.AA01120@terminus.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 06:54:07, K. Berry wrote:
> The current draft of the tds has:
>
> \item[\filename{pfa}] Type 1 fonts in \filename{PFA} format
> \item[\filename{pfb}] Type 1 fonts in \filename{PFB} format
>
> I don't see anything in the archives that explains why we're
> distinguishing these. It would simplify the paths to put them in one
> directory, called, say, `type1'.
I'd like to do that, but every other directory name is based purely
on the filename extension.
> In practice, I think
> 1) it's highly dubious that people will have both a pfa and a pfb for
> the same font; so we're not making the directories any smaller by
> separating them.
> 2) every extant program can read both kinds if it can read either (at
> least ghostscript and dvips can; not sure about ps2pk). So it's
> not making any practically useful distinction to separate them,
> either.
It's not a useful distinction, I agree. But we can't mandate one or
the other.
> Put another way, every time .../pfa is put in someone's path, .../pfb is
> needed also. So let's make everyone's life easier and put them together
> in the first place.
Yeah, it's true. What does everyone think? Break the filename extension
rule for this case?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Knowing how things work is the basis for
Production Tools Specialist | appreciation, and is thus a source of civilized
O'Reilly & Associates, Inc. | delight." -- William Safire
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Mon, 13 Feb 1995 09:56:49 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
Date: Mon, 13 Feb 1995 15:55:46 +0000
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:276840:950213155606"@cl.cam.ac.uk>
i agree with Norm. if the algorithm says file name extension, dont
break it. how about just omit pfa from the example, and leave it top
people to wonder...
s
================================================================================
Archive-Date: Mon, 13 Feb 1995 10:04:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:04:35 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131604.AA29762@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: bibtex
Actually, I thought I had removed references to the 'bib' and 'bst'
directories. Where did you find them?
I didn't. I wanted them back in.
Anyway, I removed them because I didn't want it to look like we were
playing favorites.
It's not a question of playing favorites. It's a question of saying what
needs to be said. See below.
Yes, BibTeX is used by *a lot* of users, but there
are many that don't use it at all and many that use tib instead, etc.
If tib needs a directory with substructure, then by all means let's
mention that as well.
However, I don't think bibtex and tib are symmetrical: every TeX
installation (at least every one I've ever heard of) includes
bibtex. That's not true for tib.
I relegated BibTeX to the "utility" category (page 6).
I know. I think it deserves its own category.
I could be convinced to move BibTeX back up, but is it really necessary?
I think so. Right now, the bib and bst files are installed at different
places at different sites. Isn't rationalizing this the whole purpose of
the TDS?
Most utilities -- e.g., dvips -- install any aux files during normal
program installation. Thus the TDS doesn't need to specify anything
(beyond allowing `dvips' as a top-level directory). But bibtex is
different. People retrieve new .bib (and occasionally .bst) files all
the time. Where do they go?
================================================================================
Archive-Date: Mon, 13 Feb 1995 10:07:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:07:28 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131607.AA29773@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
Norm> It's not a useful distinction, I agree. But we can't mandate one or
the other.
I don't see that we're mandating anything by saying both pfa and pfb
files go into one directory named type1, instead of two different directories.
Sebastian> i agree with Norm.
It's not clear to me that Norm was saying keep pfa/pfb.
if the algorithm says file name extension, dont
What algorithm?
*We* made the rule. We can break it if we want.
I don't see the downside here.
As I said, two different directories is *harder* for programs and people
to deal with, not easier.
break it. how about just omit pfa from the example, and leave it top
people to wonder...
Surely you jest.
================================================================================
Archive-Date: Mon, 13 Feb 1995 10:13:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:13:22 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131613.AA29800@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
> I'm puzzled by this. I thought we were suggesting `emtex', `web2c',
> etc., as top-level directories, like `makeindx' and `bibtex'. That would
I don't remember saying that.
I remember Alan (I think) saying at one point that it would be quite
strange to allow a top-level directory for relatively obscure utilities
like makeindex, but to relegate the main TeX implementation itself to
subdirectories!
As you note abouve, "emtex/ini" and "emtex/bin" are equivalent.
I noted this? Now I'm very confused.
OK, let's put it this way:
I propose we
1) say the contents of the bin directory (or a `sun4'-like directory)
are purely up to the texadmin;
2) remove the ini/ directory;
3) explicitly allow TeX implementations to have their own top-level
directory, where not only .fmt/.base files can go, but also
configuration files.
Otherwise, where do web2c's and emtex's runtime config files go?
And, given the need for this, an ini/ directory seems redundant.
This is simply being consistent with the rule that each program that
needs it gets a top-level directory to put whatever files it needs in.
If dvips, why not emtex?
================================================================================
Archive-Date: Mon, 13 Feb 1995 10:15:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 95 16:14:41 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502131614.AA03910@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: bibtex
I could be convinced to move BibTeX back up, but is it really necessary?
I'd go with Karl on this one, The base TDS ought to say what to do
with any files in a standard `TeX distribution' and that includes
bibtex. If you want, you could mention tib (or others) as possible
`utility' programs that could have their own branch off the tds.
David
================================================================================
Archive-Date: Mon, 13 Feb 1995 10:18:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:14:22 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131614.LAA08358@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: bibtex
References: <199502131604.AA29762@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 11:04:35, K. Berry wrote:
> Actually, I thought I had removed references to the 'bib' and 'bst'
> directories. Where did you find them?
>
> I didn't. I wanted them back in.
Done.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Oh my God! The dead have risen and they're
Production Tools Specialist | voting Republican! -- B. Simpson
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Mon, 13 Feb 1995 10:20:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:20:40 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131620.AA29922@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: fonts/knuth?
barbara> i think it's valuable to be able to identify which are
the *original* set and which are extensions, as the additional
sizes of cmmib in amsfonts and even more in the sauter complement.
I completely agree.
The AMS files would be in ams/extracm, and sauter in public/sauter.
public/cm (or knuth/cm, for that matter) would be for the original 75.
Unlike other "public" fonts, the Knuth fonts are special. They are
absolutely required to run TeX
Doesn't seem like an argument for a separate directory to me.
They also have special significance to the AMS, as Barbara pointed
out.
This is not affected by whether they're in knuth/ in public/, as I point
out above.
It's also a nod to the Grand Wizard.
Who could care less about it.
Oh well. I don't care as much about fonts/knuth as I do pfa/pdb, because
at least no one ever has to specify a path that explicitly says
/blah/blah/knuth:/blah/blah/public, etc. So it's more an annoyance and
slight inefficiency of another directory to search than anything else.
I just don't see the point of being annoyed and inefficient :-).
> (In any case, it wouldn't be just the ``original Computer Modern
> fonts'', but also concrete and logo and manfnt, presumably...)
True. That doesn't bother me too much, though.
It doesn't bother me, either. I was pointing out (maybe I did so more
explicitly in the editorial message?) that the current text was
misleading -- it says the knuth/ directory will have only the CM fonts.
================================================================================
Archive-Date: Mon, 13 Feb 1995 10:21:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:16:48 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131616.LAA08584@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
References: <199502131607.AA29773@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 11:07:28, K. Berry wrote:
> Sebastian> i agree with Norm.
>
> It's not clear to me that Norm was saying keep pfa/pfb.
I was leaving it the way it was.
> if the algorithm says file name extension, dont
>
> What algorithm?
> *We* made the rule. We can break it if we want.
> I don't see the downside here.
Fine, "type1" it is.
> As I said, two different directories is *harder* for programs and people
> to deal with, not easier.
>
> break it. how about just omit pfa from the example, and leave it top
> people to wonder...
>
> Surely you jest.
Yeah, Sebastian, you *were* joking weren't you? ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Mon, 13 Feb 1995 10:24:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:19:52 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131619.LAA08873@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
References: <199502131613.AA29800@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 11:13:22, K. Berry wrote:
> I remember Alan (I think) saying at one point that it would be quite
> strange to allow a top-level directory for relatively obscure utilities
> like makeindex, but to relegate the main TeX implementation itself to
> subdirectories!
>
> As you note abouve, "emtex/ini" and "emtex/bin" are equivalent.
>
> I noted this? Now I'm very confused.
In your message, you pointed out that we should allow "bin/sun4" or
"sun4/bin". I extended this to include implementations as well, not
thinking of the fact that a single OS might have multiple implmentations,
which it will.
> 1) say the contents of the bin directory (or a `sun4'-like directory)
> are purely up to the texadmin;
Ok.
> 2) remove the ini/ directory;
What about ini files that aren't implementation-specific, like hyphenation
patterns? I thought that's what ini was for.
> 3) explicitly allow TeX implementations to have their own top-level
> directory, where not only .fmt/.base files can go, but also
> configuration files.
Ok.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | `A new scientific truth does not triumph by
Production Tools Specialist | convincing its opponents and making them see the
O'Reilly & Associates, Inc. | light, but rather because its opponents
90 Sherman Street | eventually die, and a new generation grows up
Cambridge, MA 02140 | that is familiar with it' (Planck 1949)
(617) 354-5800/661-1116 FAX |
================================================================================
Archive-Date: Mon, 13 Feb 1995 10:25:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 95 16:25:07 GMT
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502131625.AA03919@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
Karl
OK, let's put it this way:
I propose we
1) say the contents of the bin directory (or a `sun4'-like directory)
are purely up to the texadmin;
2) remove the ini/ directory;
3) explicitly allow TeX implementations to have their own top-level
directory, where not only .fmt/.base files can go, but also
configuration files.
Sounds OK to me (all three)
I was never that fond of initex specific directories (except obvious
things like hyphenation) although I thought having them was the
majority view...
David
================================================================================
Archive-Date: Mon, 13 Feb 1995 10:30:07 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 13 Feb 1995 08:29:56 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131629.IAA03240@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: type1 fonts in the tds
ps2pk requires a preliminary step pfb2pfa to read pfb files. I can
look into the possibility of incorporating that step into the
basic code of ps2pk
I would have preferred to stick with type1, particularly since I
have been using type1/ as the final directory in the tree for
three years now. (Lots of links to pfa/, of course) The
division into pfa/ and pfb/ seems just fussy.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| I will continue unofficially to provide tape distributions and |
| any other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
Archive-Date: Mon, 13 Feb 1995 10:30:11 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 13 Feb 1995 08:29:56 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131629.IAA03240@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu
Subject: Re: type1 fonts in the tds
ps2pk requires a preliminary step pfb2pfa to read pfb files. I can
look into the possibility of incorporating that step into the
basic code of ps2pk
I would have preferred to stick with type1, particularly since I
have been using type1/ as the final directory in the tree for
three years now. (Lots of links to pfa/, of course) The
division into pfa/ and pfb/ seems just fussy.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| I will continue unofficially to provide tape distributions and |
| any other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
Archive-Date: Mon, 13 Feb 1995 10:34:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:29:58 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131629.LAA09828@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
References: <199502131629.IAA03240@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 08:29:56, Pierre MacKay wrote:
> ps2pk requires a preliminary step pfb2pfa to read pfb files. I can
> look into the possibility of incorporating that step into the
> basic code of ps2pk
I think you're mistaken Pierre. Unless I've lost my mind (a possibility
that I cannot completely rule out), I've done ps2pk's on PFBs many
times.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | My parents were assimilated by the Borg and all
Production Tools Specialist | I got was this lousy implant.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Mon, 13 Feb 1995 10:45:40 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 13 Feb 1995 08:45:33 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131645.IAA04403@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: fonts/knuth?
Doesn't the distinction between CM and EXTRACM, etc., achieve this? If it
is understood and stated that the cm directory contains exactly
the mf sources and derived fonts etc that are canonized by volume
E of Computers and Typesetting, then additions to that, whether
precompiled sauter interpolations or extracm-style reeditions
of the parameter files are clearly separate.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| I will continue unofficially to provide tape distributions and |
| any other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
Archive-Date: Mon, 13 Feb 1995 10:55:32 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 13 Feb 1995 08:55:27 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131655.IAA05398@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
The manual says that pfb2pfa is required!!!???
================================================================================
Archive-Date: Mon, 13 Feb 1995 10:59:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 11:54:55 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502131654.LAA12403@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
References: <199502131655.IAA05398@june.cs.washington.edu>
Reply-To: TWG-TDS@SHSU.edu
On 13 February 1995 at 08:55:27, Pierre MacKay wrote:
> The manual says that pfb2pfa is required!!!???
Nevertheless,
norm@jasper$ ps2pk -V -P10 -a/usr/local/lib/psfonts/adobe/garamond/afm/Garamond-Book.afm /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb ./gbk.300pk
Trying to open /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb
Trying to open /usr/local/lib/psfonts/adobe/garamond/afm/Garamond-Book.afm
Loading encoding vector from /usr/local/lib/psfonts/adobe/garamond/afm/Garamond-Book.afm ... done
Checking /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb font ... done
Creating character glyphs for /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb ...^Cnorm@jasper$ ps2pk -V -P10 -a/usr/local/lib/psfonts/adobe/garamond/afm/Garamond-Book.afm /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb ./gbk.300pk
Trying to open /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb
Trying to open /usr/local/lib/psfonts/adobe/garamond/afm/Garamond-Book.afm
Loading encoding vector from /usr/local/lib/psfonts/adobe/garamond/afm/Garamond-Book.afm ... done
Checking /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb font ... done
Creating character glyphs for /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb ... done.
Creating ./gbk.300pk from /usr/local/lib/psfonts/adobe/garamond/pfb/Garamond-Book.pfb.
'040 '041 '042 '043 '044 '045 '046 '047
'050 '051 '052 '053 '054 '055 '056 '057
'060 '061 '062 '063 '064 '065 '066 '067
'070 '071 '072 '073 '074 '075 '076 '077
'100 '101 '102 '103 '104 '105 '106 '107
'110 '111 '112 '113 '114 '115 '116 '117
'120 '121 '122 '123 '124 '125 '126 '127
'130 '131 '132 '133 '134 '135 '136 '137
'140 '141 '142 '143 '144 '145 '146 '147
'150 '151 '152 '153 '154 '155 '156 '157
'160 '161 '162 '163 '164 '165 '166 '167
'170 '171 '172 '173 '174 '175 '176 '241
'242 '243 '244 '245 '246 '247 '250 '251
'252 '253 '254 '255 '256 '257 '261 '262
'263 '264 '266 '267 '270 '271 '272 '273
'274 '275 '277 '301 '302 '303 '304 '305
'306 '307 '310 '312 '313 '315 '316 '317
'320 '341 '343 '350 '351 '352 '353 '361
'365 '370 '371 '372 '373
norm@jasper$
================================================================================
Archive-Date: Mon, 13 Feb 1995 11:23:48 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 13 Feb 1995 09:19:32 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502131719.JAA08405@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: type1 fonts in the tds
If pfb2pfa is not necessary, so much the better. I never had
the occasion to find out, because I always convert to pfa
for other reasons.
Makes an even better case for consolidating pfb and pfa in one
type1 directory.
================================================================================
Archive-Date: Mon, 13 Feb 1995 13:31:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 13 Feb 1995 17:32:24 GMT
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950213173224.22001967@vms.rhbnc.ac.uk>
Subject: Re: type1 fonts in the tds
>> The manual says that pfb2pfa is required!!!???
Sometimes the author loses control of his own code! I can confirm
that the MS/DOS version is very happy with PFB files. ** Phil.
================================================================================
Archive-Date: Tue, 14 Feb 1995 05:32:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Feb 1995 06:32:22 -0500
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502141132.AA12549@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
What about ini files that aren't implementation-specific, like hyphenation
patterns? I thought that's what ini was for.
Now, hyphenation patterns are something entirely different. That was the
subject of another message of mine; maybe it never made it out. In the
draft I read over the weekend, ini/ was only for pool/base/fmt
files. Hyphenation patterns were stored in a top-level initex directory.
Here's my msg arguing for removal of initex/:
To: twg-tds@shsu.edu
Subject: the initex directory
I hate to reopen this discussion, but the current draft of the tds
specifies a top-level initex directory.
Doesn't such a thing imply another whole set of things that have to go
in the paths, and where people & programs have to look?
I'm not sure I see the need. In the old mail, the things suggested for
it were
1) base files, like plain.tex and latex.ltx. Surely people would be more
inclined to find these in tex/<format>/base?
2) Joachim's unnamed initex-only files. They could be considered as
a package (if they aren't already) and put in tex/<package>?
3) hyphenation files. Could go in tex/hyphen.
Is there a practical advantage to the top-level initex/ to outweigh the
practical disadvantage?
By the way, these things kind of worry me. I'm just reading the
document, not actually trying to make a system [yet] that conforms to
it. I don't think the TDS should be declared official-and-accepted until
several implementations are actually distributing something that
conforms to it. Otherwise, we're just playing theoretical games.
================================================================================
Archive-Date: Tue, 14 Feb 1995 15:40:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 14 Feb 1995 16:35:47 -0500
From: norm@ora.com (Norman Walsh)
Message-ID: <199502142135.QAA10716@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
References: <199502141132.AA12549@ra.cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
On 14 February 1995 at 06:32:22, K. Berry wrote:
> What about ini files that aren't implementation-specific, like
> hyphenation patterns? I thought that's what ini was for.
>
> Now, hyphenation patterns are something entirely different. That was the
> subject of another message of mine; maybe it never made it out. In the
> draft I read over the weekend, ini/ was only for pool/base/fmt
> files. Hyphenation patterns were stored in a top-level initex directory.
>
> Here's my msg arguing for removal of initex/:
>
> To: twg-tds@shsu.edu
> Subject: the initex directory
>
> I hate to reopen this discussion, but the current draft of the tds
> specifies a top-level initex directory.
>
> Doesn't such a thing imply another whole set of things that have to go
> in the paths, and where people & programs have to look?
>
> I'm not sure I see the need. In the old mail, the things suggested for
> it were
> 1) base files, like plain.tex and latex.ltx. Surely people would be more
> inclined to find these in tex/<format>/base?
> 2) Joachim's unnamed initex-only files. They could be considered as
> a package (if they aren't already) and put in tex/<package>?
> 3) hyphenation files. Could go in tex/hyphen.
>
> Is there a practical advantage to the top-level initex/ to outweigh the
> practical disadvantage?
I agree with Karl and vote we remove both /ini and /initex from the
TDS.
> By the way, these things kind of worry me. I'm just reading the
> document, not actually trying to make a system [yet] that conforms to
> it. I don't think the TDS should be declared official-and-accepted until
> several implementations are actually distributing something that
> conforms to it. Otherwise, we're just playing theoretical games.
Agreed. You know, though, that one of the Linux distributions comes darn
close. I was amazed when it came installed on my new system ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The 'net interprets censorship as damage and
Production Tools Specialist | routes around it." -- John Gilmore
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm.html
================================================================================
Archive-Date: Tue, 14 Feb 1995 16:46:23 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 14 Feb 1995 14:46:19 -0800
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199502142246.OAA10079@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
Without wanting to make excessive claims, I try to rework UnixTeX
into conformity with TDS in any parts of the tree that seem stable.
It is difficult though. ini/ has just disappeared again, and I am
still not quite clear on what to do with doc/
================================================================================
Archive-Date: Wed, 15 Feb 1995 18:00:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 16 Feb 95 00:57:26 +0100
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9502152357.AA15308@wega.informatik.uni-hannover.de>
To: TWG-TDS@SHSU.edu
Subject: Re: architecture- and implementation-dependent directories
: Agreed. You know, though, that one of the Linux distributions comes darn
: close. I was amazed when it came installed on my new system ;-)
Are you speeking of teTeX? It was me who set up this distribution. I listen
to this mailing-list since approx. 08/94 and I tried anticipiate the
(hopefully) upcoming TDS.
Maybe, teTeX will be fully TDS compiliant some day (since all drivers and the
web2c package use Kpathsea-2.6, I am very flexible (thanks Karl!)).
Any comments about the arrangements in teTeX are welcome.
Thomas
Archive-Date: 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'.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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?
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
=========================================================================
================================================================================
Archive-Date: 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)
================================================================================
Archive-Date: 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)
================================================================================
Archive-Date: 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)
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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:-)
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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/ ...
================================================================================
Archive-Date: 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
}
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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>/)
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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}}
***************
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 |
================================================================================
Archive-Date: 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 |
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 ...)
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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:).
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.)
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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?
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 |
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 ...
================================================================================
Archive-Date: 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/
================================================================================
Archive-Date: 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?
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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 ...
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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?
================================================================================
Archive-Date: 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 :-).
================================================================================
Archive-Date: 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?
================================================================================
Archive-Date: 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 ...
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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?
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 :-).
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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?
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 |
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 ...
================================================================================
Archive-Date: 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:-)
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 |
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 :-)
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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)
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 |
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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)
================================================================================
Archive-Date: 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)
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 :-)
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 |
================================================================================
Archive-Date: 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 :-).
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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)
================================================================================
Archive-Date: 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)
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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)
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 :-(.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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 |
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 |
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 :-)
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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}
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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 :-).
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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?
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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?
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 ...
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.)
================================================================================
Archive-Date: 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)
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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!
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 :-).
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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 |
================================================================================
Archive-Date: 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 |
================================================================================
Archive-Date: 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 |
================================================================================
Archive-Date: 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.
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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
================================================================================
Archive-Date: 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: