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: http://jasper.ora.com/norm
================================================================================
Archive-Date: Thu, 18 May 1995 02:47:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 95 09:48:16 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505180748.AA10108@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: more comments on 0.75
Two more late comments on draft 0.75 (Sorry, I haven't seen the
very latest yet, I'm always a bit behind, I'm afraid):
1. While I agree with dropping the file extensions for most files
in the doc tree figure, I'd strongly suggest keeping it for
amsfonts.faq und amslatex.faq. These are plain text files
rather than .tex files, so the extension is significant here.
2. In the related documentation appendix I'd suggest listing only
the three primary CTAN hosts instead of a somewhat arbitrary
selection from among the mirror sites. (Who's ever heard
of ftp.uni-bielefeld.de?)
So long,
Ulrik.
P.S. Concerning the target for the final version: What about
sheduling it for the time after TUG'95 but before EuroTeX'95.
This would allow for integrating comments received after the
TUG meeting, but presenting the final conclusions not too
long afterwards. Otherwise another year would go by before
the next large international TeX conference. Sounds sensible?
================================================================================
Archive-Date: Thu, 18 May 1995 07:22:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 08:21:24 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505181221.AA16519@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: more comments on 0.75
2. In the related documentation appendix I'd suggest listing only
the three primary CTAN hosts instead of a somewhat arbitrary
selection from among the mirror sites. (Who's ever heard
of ftp.uni-bielefeld.de?)
I chose a random selection precisely so people would be aware that there
*were* sites other than the primary ones. (And so people would see that
not everything started with /tex-archive.) However, perhaps this was
silly, and it would be better to list the primary sites only, or list
them plus some selected others from the other continents.
P.S. Concerning the target for the final version: What about
sheduling it for the time after TUG'95 but before EuroTeX'95.
When is it?
long afterwards. Otherwise another year would go by before
the next large international TeX conference. Sounds sensible?
If it can be done, sure. I think it's more important to get the content
right than to meet any particular date. I also think conferences as a
way of disseminating information are overrated, because only a minuscule
proportion of the people affected attend any given conference.
================================================================================
Archive-Date: Thu, 18 May 1995 09:59:27 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505181457.QAA13176@spice.iti.informatik.th-darmstadt.de>
Subject: it get's less... 0.76
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Thu, 18 May 1995 16:57:22 +0200 (MESZ)
Content-Type: text
[The new macros are committed now, a macro source distribution is
available as a tar.gz file.]
--------------------
** 10 Summary **
In the generic/ subsection -- please move hyphen/ in front of misc/.
Everywhere it's ordered alphabetically, except here.
** A.4 Subdirectory Searching Syntax **
You must not transform backslashs in \path arguments to
`$\backslash$'.
** C Related References **
A sample tree is available electronically from CTAN:\path|tds|.
--------------------
Joachim
PS: The latter is not completely true yet, I have to hash out the
procedure for automatic updates with Sebastian. (Hmm, consider: I
will eventually mirror the mail backlogs from shsu.edu:[twg.tds], and
CTAN will mirror it back from my site. Rather long way from shsu.edu
to ftp.shsu.edu... :-)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Thu, 18 May 1995 11:00:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 11:59:29 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505181559.AA17446@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: it get's less... 0.76
A sample tree is available electronically from CTAN:\path|tds|.
How about changing this to doc/tds?
As I said before, I don't see why we should get a top-level directory.
================================================================================
Archive-Date: Thu, 18 May 1995 11:01:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 16:55:52 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950518165552.21a05302@vms.rhbnc.ac.uk>
Subject: RE: more on 0.75
>> Is emTeX syntax really `t:\directory**'? I would have suspected
>> `t:\directory\**'.
Where did the asterisks come from? I have been religiously tracking
updates to emTeX betas, and can find nothing in the DOC files to
suggest that the syntax has changed from trailing `!' & `!!'...
** Phil.
================================================================================
Archive-Date: Thu, 18 May 1995 11:06:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 95 12:05:06 EDT
From: karl@owl.HQ.ileaf.com (Karl Berry)
Message-ID: <9505181605.AA27467@owl.hq.ileaf.com>
To: twg-tds@shsu.edu
Subject: 0.76 comments
Reply-To: TWG-TDS@SHSU.edu
0.76 is looking good. There are a few typographic problems that preclude
it being the final version, but I don't see any content problems.
Here are the nits.
difficult: it is impossible to determine what files are used by
impossible => hard [nothing's impossible]
Naturally, this does not affect the format of names on the CD-ROM itself.
Delete `Naturally,'. [nothing's natural]
up to the installer. On \abbr{pc} networks, for example, this
Is `PC networks' really the right term here? How about `DOS machines'?
files which can also be used with {\LaTeX} or {\AMSTeX} as well as
Saying AMSTeX here gives the misleading impression that those are the
only two formats that counts (especially since we also point out AMSTeX
is compatible with plain). How about `and other formats' instead?
This directory need only exist
only exist => exist only
under the \literal{generic} format tree.
tree => directory
The \abbr{TDS} specifies the following:
following (except for PK and GF, which need additional structure, as
detailed in the next section):
\path|PK| and \path|GF| files need additional structure,
described in the next section.
Delete this now, if you like the above.
into separate directories.
New text following: Consult \filename{modes.mf} for recommended mode
names. (See Appendix C for complete reference.)
the \abbr{TDS} must use the latter (directory-based) scheme for naming fonts.
the \abbr{TDS} => it
For PS fonts rendered as bitmaps by a program that does not
Delete `PS'. [should have been `PostScript' anyway, but it's equally
applicable to truetype or whatever]
\section{{\protect\BibTeX}}
There's something wrong with the BibTeX logo. The `TeX' is coming out in
a bigger point size than the `B'. This is true in both the regular text
and in this heading.
Other categories include utility names:
... names, for example:
martian-1.0/read.me
Er, do we really have to recommend `read.me'? Why not `README'?
We already have the mixed-case OT1 file ...
(Global replace if you buy it.)
Thus, we don't expect any big surprises as implementation gets under way.
... we hope for few surprises ... [let's be humble]
\application{Y\&Y{\TeX}}, \command{dvips(k)},
How did this suddenly become a \command? Looks wrong.
\item[\command{dvips}]
\item[\command{xdvi} (patchlevel 20)]
Likewise here. Also, how about putting a : after each of these names?
\item[em{\TeX}]
SHould be \application-ified.
\item[\application{kpathsea}]
SHould probably be a capital K.
\path|t:$\backslash$directory**|
Here are the $\backslash$ things you need to fix. (Joachim said make it
\\, I think.) Also, what about \dir\** vs. \dir**? Are we sure this is
correct? Is anyone on the committee actually running emtex?! Surely...
structure won on a couple of grounds:
on a couple of grounds => for a couple of reasons
[don't think grounds can be pluralized like that]
however, unless all the programs that search this tree employ some form of
however, => but
sunsite.unc.edu:/pub/packages/TeX
Now that I see the list, I agree completely with Ulrik. So:
ftp.dante.de:/tex/-archive
ftp.shsu.edu:/tex-archive
ftp.tex.ac.uk:/tex-archive
This distribution includes eight-character-or-fewer recommended mode names.
distribution => file
Also, there are many places where \abbr is missing. I edited this list
from an M-x occur of ` [A-Z][A-Z][A-Z]+':
45:and from \path|/tex-archive/doc/tds| on any CTAN host.
84:At first glance, it may seem that the CTAN archives fulfill (at least)
85:part of this role, but this is not the case. The role of the CTAN archives
89:In fact, the roles of the \abbr{TDS} and CTAN are frequently in conflict,
587:The TWG recognizes that the use of short filenames has many
767: . ctan/ info about CTAN sites, \path|TeX-index|, etc.
768: . faq/ FAQs of \path|comp.text.tex|, etc.
797: info/ GNU Info files, made from {\TeXinfo} sources
957:Computer Modern and AMS fonts, you can store them in the
961:The TWG recognizes that subdirectory searching places an extra burden
1022:The TWG settled on the
1039:The fact that several members of the TWG already have arrangements
1042:at any known site, and the TWG felt it wrong to mandate something
1106:In this document, ``CTAN:'' means the root of a anonymous ftp CTAN
1113:Finger \path|ctan@ftp.shsu.edu| for a complete list of CTAN sites.
1123:available from CTAN:\path|doc/components-of-TeX|.
1132:The TWG had no formal meetings (many, but not all, members attended
================================================================================
Archive-Date: Thu, 18 May 1995 11:12:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505181611.SAA16337@spice.iti.informatik.th-darmstadt.de>
Subject: Re: it get's less... 0.76
To: TWG-TDS@SHSU.edu
Date: Thu, 18 May 1995 18:11:15 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> A sample tree is available electronically from CTAN:\path|tds|.
>
> How about changing this to doc/tds?
I suspect because
(a) there is no CTAN:doc/ directory [:-)]
(b) from 13 MB, 10 MB are archives with software. (Effectively, your
lib/ tree & some Unix executables.) I don't know if
CTAN:documentation/tds/ is the right place for it.
[But then, I don't speak for the CTAN team; actually I don't care
where it is as long as it gets updated automatically...]
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Thu, 18 May 1995 11:28:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 12:26:59 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505181626.MAA16002@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: it get's less... 0.76
Reply-To: TWG-TDS@SHSU.edu
>
> [The new macros are committed now, a macro source distribution is
> available as a tar.gz file.]
Will get it for 0.77
> ** 10 Summary **
>
> In the generic/ subsection -- please move hyphen/ in front of misc/.
> Everywhere it's ordered alphabetically, except here.
check.
> ** A.4 Subdirectory Searching Syntax **
>
> You must not transform backslashs in \path arguments to
> `$\backslash$'.
Ok.
> ** C Related References **
>
> A sample tree is available electronically from CTAN:\path|tds|.
Ok.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The 'net interprets censorship as damage and
Production Tools Specialist | routes around it." -- John Gilmore
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
Archive-Date: Thu, 18 May 1995 11:29:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 12:27:59 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505181627.MAA16020@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: RE: more on 0.75
Reply-To: TWG-TDS@SHSU.edu
> >> Is emTeX syntax really `t:\directory**'? I would have suspected
> >> `t:\directory\**'.
>
> Where did the asterisks come from? I have been religiously tracking
> updates to emTeX betas, and can find nothing in the DOC files to
> suggest that the syntax has changed from trailing `!' & `!!'...
I think Phil's right on this one...anyone sure it's **?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Practice kind, beautiful acts of random
Production Tools Specialist | senselessness.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
Archive-Date: Thu, 18 May 1995 11:41:36 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505181639.SAA15400@spice.iti.informatik.th-darmstadt.de>
Subject: Re: 0.76 comments
To: TWG-TDS@SHSU.edu
Date: Thu, 18 May 1995 18:39:51 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> \section{{\protect\BibTeX}}
>
> There's something wrong with the BibTeX logo. The `TeX' is coming out in
> a bigger point size than the `B'.
I beg to differ. My eyes have an other opinion. Well, you might not
trust them, so I asked dvitype:
38112: fntnum30 current font is cmss12
38113: setchar55 h:=4063232+462023=4525255, hh:=286
[7]
38114: pop
level 3:(h=0,v=21340577,w=0,x=0,y=786432,z=1030300,hh=0,vv=1352)
38115: right3 5449302 h:=0+5449302=5449302, hh:=345
38119: setchar66 h:=5449302+613300=6062602, hh:=384
38120: right3 -46205 h:=6062602-46205=6016397, hh:=381
[ B]
38124: fntnum38 current font is cmss10
38125: setchar73 h:=6016397+182046=6198443, hh:=393
38126: setchar66 h:=6198443+436908=6635351, hh:=421
38127: right3 -73925 h:=6635351-73925=6561426, hh:=416
[IB]
38131: fntnum30 current font is cmss12
38132: setchar84 h:=6561426+630230=7191656, hh:=456
[T]
I checked DVI & PS file distributed by Norm, btw.
> \path|t:$\backslash$directory**|
>
> Here are the $\backslash$ things you need to fix. (Joachim said make it
> \\, I think.)
Uumpf. Norm, be careful. If you use \path, just use `\', without any
escape. \path works like \verb here. If you use \literal or \filename,
you should use `\\'.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Thu, 18 May 1995 11:46:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 12:22:36 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505181622.MAA15944@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: more comments on 0.75
Reply-To: TWG-TDS@SHSU.edu
> 1. While I agree with dropping the file extensions for most files
> in the doc tree figure, I'd strongly suggest keeping it for
> amsfonts.faq und amslatex.faq. These are plain text files
> rather than .tex files, so the extension is significant here.
I don't feel strongly about it, so OK.
> 2. In the related documentation appendix I'd suggest listing only
> the three primary CTAN hosts instead of a somewhat arbitrary
> selection from among the mirror sites. (Who's ever heard
> of ftp.uni-bielefeld.de?)
I don't feel strongly about this, either. Maybe just list the big
three and suggest using "finger"...
> P.S. Concerning the target for the final version: What about
> sheduling it for the time after TUG'95 but before EuroTeX'95.
> This would allow for integrating comments received after the
> TUG meeting, but presenting the final conclusions not too
> long afterwards. Otherwise another year would go by before
> the next large international TeX conference. Sounds sensible?
I think timing of the final version will depend on user feedback
more than anything else.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The eternal mystery of the world is its
Production Tools Specialist | comprehensibility." -- A. Einstien
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
Archive-Date: Thu, 18 May 1995 11:50:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 12:49:40 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505181649.MAA16650@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: 0.76 comments
Reply-To: TWG-TDS@SHSU.edu
> Here are the nits.
>
> difficult: it is impossible to determine what files are used by
>
> impossible => hard [nothing's impossible]
Check.
> Naturally, this does not affect the format of names on the CD-ROM itself.
>
> Delete `Naturally,'. [nothing's natural]
Check.
> up to the installer. On \abbr{pc} networks, for example, this
>
> Is `PC networks' really the right term here? How about `DOS machines'?
No, it's more a network thing than a DOS thing. Yes, a user on a single
machine could do it, but they might not. A Netware network might only
provide the path as T:
> files which can also be used with {\LaTeX} or {\AMSTeX} as well as
>
> Saying AMSTeX here gives the misleading impression that those are the
> only two formats that counts (especially since we also point out AMSTeX
> is compatible with plain). How about `and other formats' instead?
Is this what you mean?
...files which can also be used with {\LaTeX} or {\AMSTeX} and other
formats as well as...
Check.
> This directory need only exist
>
> only exist => exist only
Check.
> under the \literal{generic} format tree.
>
> tree => directory
Check.
> The \abbr{TDS} specifies the following:
>
> following (except for PK and GF, which need additional structure, as
> detailed in the next section):
Check.
> \path|PK| and \path|GF| files need additional structure,
> described in the next section.
>
> Delete this now, if you like the above.
Sounds good.
> into separate directories.
>
> New text following: Consult \filename{modes.mf} for recommended mode
> names. (See Appendix C for complete reference.)
Check.
> the \abbr{TDS} must use the latter (directory-based) scheme for naming fonts.
>
> the \abbr{TDS} => it
Check.
> For PS fonts rendered as bitmaps by a program that does not
>
> Delete `PS'. [should have been `PostScript' anyway, but it's equally
> applicable to truetype or whatever]
Check.
> \section{{\protect\BibTeX}}
>
> There's something wrong with the BibTeX logo. The `TeX' is coming out in
> a bigger point size than the `B'. This is true in both the regular text
> and in this heading.
Joachim?
> Other categories include utility names:
>
> ... names, for example:
Check.
> martian-1.0/read.me
>
> Er, do we really have to recommend `read.me'? Why not `README'?
> We already have the mixed-case OT1 file ...
> (Global replace if you buy it.)
Ok.
> Thus, we don't expect any big surprises as implementation gets under way.
>
> ... we hope for few surprises ... [let's be humble]
Yep.
> \application{Y\&Y{\TeX}}, \command{dvips(k)},
>
> How did this suddenly become a \command? Looks wrong.
>
> \item[\command{dvips}]
> \item[\command{xdvi} (patchlevel 20)]
>
> Likewise here. Also, how about putting a : after each of these names?
Ok.
> \item[em{\TeX}]
>
> SHould be \application-ified.
>
> \item[\application{kpathsea}]
>
> SHould probably be a capital K.
Check and check.
> \path|t:$\backslash$directory**|
>
> Here are the $\backslash$ things you need to fix. (Joachim said make it
> \\, I think.) Also, what about \dir\** vs. \dir**? Are we sure this is
> correct? Is anyone on the committee actually running emtex?! Surely...
I used to. And I really think it's \dir!!
> structure won on a couple of grounds:
>
> on a couple of grounds => for a couple of reasons
> [don't think grounds can be pluralized like that]
Ok.
> however, unless all the programs that search this tree employ some form of
>
> however, => but
Check.
> sunsite.unc.edu:/pub/packages/TeX
>
> Now that I see the list, I agree completely with Ulrik. So:
>
> ftp.dante.de:/tex/-archive
> ftp.shsu.edu:/tex-archive
> ftp.tex.ac.uk:/tex-archive
Check.
> This distribution includes eight-character-or-fewer recommended mode names.
>
> distribution => file
Check.
> Also, there are many places where \abbr is missing. I edited this list
> from an M-x occur of ` [A-Z][A-Z][A-Z]+':
Check.
================================================================================
Archive-Date: Thu, 18 May 1995 14:57:32 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 15:56:41 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505181956.PAA22982@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: MORE READING: 0.77
Reply-To: TWG-TDS@SHSU.edu
ftp://jasper.ora.com/private/twg-tds/tds.{tex,dvi,ps}; *.sgm
Joachim,
I used tdsguide 1.1; is the header on the title page my fault (old
version of some style)?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "It can be shown that for any nutty theory,
Production Tools Specialist | beyond-the-fringe political view or strange
O'Reilly & Associates, Inc. | religion there exists a proponent on the Net.
90 Sherman Street | The proof is left as an exercise for your
Cambridge, MA 02140 | kill-file."
(617) 354-5800/661-1116 FAX |
================================================================================
Archive-Date: Thu, 18 May 1995 15:09:48 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505182008.WAA14013@spice.iti.informatik.th-darmstadt.de>
Subject: Re: MORE READING: 0.77
To: TWG-TDS@SHSU.edu
Date: Thu, 18 May 1995 22:08:53 +0200 (MESZ)
Content-Type: text
Norm wrote:
>
> ftp://jasper.ora.com/private/twg-tds/tds.{tex,dvi,ps}; *.sgm
>
> Joachim,
>
> I used tdsguide 1.1; is the header on the title page my fault (old
> version of some style)?
It seems so, I have noticed but can't reproduce this problem here. I
use fancyheadings.sty version 1.7, perhaps you might want to check
this.
I thought about adding current versions of all used style files to
the tdsguide macro distribution, perhaps in a styles/ subdirectory --
would this help?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Thu, 18 May 1995 16:31:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 18 May 1995 17:30:45 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505182130.AA29174@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: it get's less... 0.76
(a) there is no CTAN:doc/ directory [:-)]
Oops. Several CTAN:doc/'s need to be changed to CTAN:documentation/'s.
Sorry, Norm.
(b) from 13 MB, 10 MB are archives with software. (Effectively, your
lib/ tree & some Unix executables.) I don't know if
CTAN:documentation/tds/ is the right place for it.
Well, are users supposed to actually retrieve it and use it?
Then I would say it should be systems/tds.
If it's a sort of supplement to the standard (the view I lean towards), then
I think it should be CTAN:documentation/tds/texmf or some such.
In any case, having the example tree in CTAN:tds/ and the standard in
CTAN:documentation/tds seems utterly confusing to me.
[But then, I don't speak for the CTAN team; actually I don't care
Yes, but Sebastian's on the list. What say you, Sebastian?
I can't find any TDS directories on ftp.shsu.edu, by the way.
================================================================================
Archive-Date: Thu, 18 May 1995 17:38:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 18 May 1995 18:37:38 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: 0.76 comments
To: TWG-TDS@SHSU.edu
Message-ID: <800836658.199839.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
oops!
i knew when i saw this i should have spoken up:
ftp.dante.de:/tex/-archive
ftp.shsu.edu:/tex-archive
ftp.tex.ac.uk:/tex-archive
i think we've got one too many slashes in the first line.
still in v 0.77.
please make it
ftp.dante.de:/tex-archive
(appendix c)
-- bb
================================================================================
Archive-Date: Fri, 19 May 1995 02:35:10 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505190734.JAA16844@spice.iti.informatik.th-darmstadt.de>
Subject: Re: it get's less... 0.76
To: TWG-TDS@SHSU.edu
Date: Fri, 19 May 1995 09:34:10 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> (b) from 13 MB, 10 MB are archives with software. (Effectively, your
> lib/ tree & some Unix executables.) I don't know if
> CTAN:documentation/tds/ is the right place for it.
>
> Well, are users supposed to actually retrieve it and use it?
No, heaven forbid. I don't see it as a plug&play distribution.
So I withdraw argument (b), Sebastian shall decide.
> I can't find any TDS directories on ftp.shsu.edu, by the way.
I don't know how the CTAN team currently organizes an automatic mirror
on one site and subsequent uploads to the other CTAN sites.
(Technically, it's simple; a script ctan_install must be called with
the result of a mirror run.)
I might be inclined to mirror it myself to ftp.dante.de (netwise
very near, and I have write access) and manage the CTAN distribution
from there. But first I want to know how it's supposed to be done... :)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 19 May 1995 11:09:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 19 May 1995 12:08:25 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505191608.AA07273@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: 0.77 comments
Well, aside from tex/-archive and the few miscellanous typographical
problems, maybe it's time ... my nits are getting nittier. Also,
thankfully, fewer.
this.) It may be convenient to store implementations
(\application{em{\TeX}}, \application{PC{\TeX}}, etc.) as well
as utilities (\command{dvips}, \command{MakeIndex}, etc.) in
their own directories. Implementations can store implementation-specific
This bit is confused, both typographically and semantically. How about
this:
Both implementations (\application{em{\TeX}},
\application{PC{\TeX}}, etc.) and
utilities (\application{dvips}, \application{MakeIndex}, etc.)
are included here. Sites can thus store implementation-specific
``local'' files, since that would require duplicating the entire tree.
``local'' files => locally-maintained files (e.g., letterheads)
files which can also be used with {\LaTeX} or {\AMSTeX} and other
Now that I see it in print, I think it's better to delete the `or
{\AMSTeX}' here. Whether it should ``and other formats'' or ``or other
formats'' is a matter of debate -- I think we previously decided
anything in tex/generic/ has to work with at least tex and latex, didn't
we? I.e., tex and amstex is not enough, since amstex doesn't do anything
drastic to plain, like latex does.
This is one of the weakest points of the standard ... exactly what goes
in generic/. But, clearly now is not the time for further debate!
At the moment there aren't any besides the standard distribution,
besides the => besides those in the
little more we can do.
little => no
American Mathematical Society, Providence, \abbr{ri}, \abbr{u.s.a}.
Editor, TUGboat;
TUGboat => \citetitle{TUGboat}
Berry, Karl (\literal{kb@cs.umb.edu}). Maintainer of \command{Web2C},
\command => \application
such as \citetitle{SunExpert} and \citetitle{UNIX Review}.
UNIX => \abbr{UNIX}
================================================================================
Archive-Date: Fri, 19 May 1995 11:43:16 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505191642.SAA12486@spice.iti.informatik.th-darmstadt.de>
Subject: Re: 0.77 comments
To: TWG-TDS@SHSU.edu
Date: Fri, 19 May 1995 18:42:20 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> This is one of the weakest points of the standard ... exactly what goes
> in generic/.
That's easy (IMO :-):
texmf/tex/generic/ holds macros that can be used with all TeX formats
that use plain TeX's category codes and provide plain TeX's basic
control sequences. The latter are those described in the TeXbook
Appendix B, except ``font information'' (section~4), box, tabbing,
item and section macros (section~5, p.\,353--355), and ``Macros for
output'' (section~7). Note that those control sequences must be only
be provided, they may have a different implementation.
Joachim
PS: page numbers are from hard cover, 9th printing.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 19 May 1995 12:14:48 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505191642.SAA12486@spice.iti.informatik.th-darmstadt.de>
Subject: Re: 0.77 comments
To: TWG-TDS@SHSU.edu
Date: Fri, 19 May 1995 18:42:20 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> This is one of the weakest points of the standard ... exactly what goes
> in generic/.
That's easy (IMO :-):
texmf/tex/generic/ holds macros that can be used with all TeX formats
that use plain TeX's category codes and provide plain TeX's basic
control sequences. The latter are those described in the TeXbook
Appendix B, except ``font information'' (section~4), box, tabbing,
item and section macros (section~5, p.\,353--355), and ``Macros for
output'' (section~7). Note that those control sequences must be only
be provided, they may have a different implementation.
Joachim
PS: page numbers are from hard cover, 9th printing.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 19 May 1995 16:08:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 19 May 1995 17:07:40 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505192107.AA12104@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.77 comments
Being compatible with plain TeX's catcodes and basic control
sequences isn't enough, I thought. It has to be compatible
with LaTeX, or what's the point? For example, btxmac.tex
should not be in generic/, I thought we decided,
even though it can be used by plain and amstex.
In reality, I think it comes down to those macro files
that can be used by plain and latex.
================================================================================
Archive-Date: Sat, 20 May 1995 04:51:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505200950.LAA18087@spock.iti.informatik.th-darmstadt.de>
Subject: Re: 0.77 comments
To: TWG-TDS@SHSU.edu
Date: Sat, 20 May 1995 11:50:36 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> Being compatible with plain TeX's catcodes and basic control
> sequences isn't enough, I thought. It has to be compatible
> with LaTeX, or what's the point?
Please note: The first sentence implies the second. I.e., my
definition was carefully worded to imply compatibility with LaTeX.
> For example, btxmac.tex
> should not be in generic/, I thought we decided,
> even though it can be used by plain and amstex.
Does btxmac.tex use only the pieces of plain.tex I scetched in my
last mail? Do you -- as the author of btxmac.tex -- expect people to
use btxmac.tex with other formats than plain TeX & AMS-TeX?
Two yes: it goes in generic/.
One no: it goes in plain/.
That's because AMS-TeX is a real extension to plain TeX, all plain
macros are (in theory) be usable with AMS-TeX. The search path for
AMS-TeX therefore encompasses the plain subtree.
There are more formats than just the Big Three. There _are_ macro files
that run with the Big Three but do not run with other formats, because
they demand more from the environment than the part I scetched. Those
don't belong in generic/ then. (IMO.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 24 May 1995 06:30:58 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: it get's less... 0.76
Date: Wed, 24 May 1995 12:26:47 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:196860:950524112656"@cl.cam.ac.uk>
re CTAN and TDS, Rainer has fixed SHSU to pull the top-level tds tree
in from Germany. so as things stand now, all CTAN sites will be
mirroring Joachim's TDS site, directly or indirectly. If Joachim
preferers to amanage it on Dante, just let us know, and the mirror
will switch to there
actually, on refelction, since SHSU alraedy follows Dante, not Joachim
direct, i'll make the UK do likewause, so all Joachim or anyone need
do is make sure Rainer knows whats happening
Sebastian
================================================================================
Archive-Date: Wed, 24 May 1995 09:57:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 24 May 1995 10:57:02 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505241457.AA29890@ra.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: some corrections on 0.72
Sebastian just pointed out to me:
the current draft says doc/tds in one place, and tds in aother :-}
doc/tds should be eradicated. we're going with CTAN:tds.
================================================================================
Archive-Date: Wed, 24 May 1995 14:44:24 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505241921.VAA25321@spice.iti.informatik.th-darmstadt.de>
Subject: Another TDS revision?
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Wed, 24 May 1995 21:21:58 +0200 (MESZ)
Content-Type: text
Karl suggested to create another version before public review. Norm,
if you do so, do you please check the version of your installed
fancyheadings.sty?
I just processed the current tds.tex file and forced it to use the
style files from this stand-alone document. No head line on the title
page. This points to a general problem, IMHO. I don't know how I can
force LaTeX (portably!) to output the filecontents enviroment if the
file does not exist in the current directory, so we may get more
problem reports of people with outdated style files.
If anybody on the mailing list knows a way to cope with this problem,
please contact me by email.
Thanks in advance,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 24 May 1995 14:48:03 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505241850.UAA17036@spice.iti.informatik.th-darmstadt.de>
Subject: TDS on CTAN
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Wed, 24 May 1995 20:50:21 +0200 (MESZ)
CC: ctan@shsu.edu
Content-Type: text
[Hi, I've been away for a few days [*] and working on my mail backlog now.]
Thanks to sebastian to confirm that my TDS collection is mirrored. In
retrospect I think I may have sounded harsh -- it was not my
intention, my apologies to the CTAN team.
After I saw the mirror result on CTAN, I suddenly realized that I
have quite some information in the READMEs that are written in the
context of my ftp server, I have to change them to cope with the
availability on CTAN as well. In addition, there are symlinks to
files outside the TDS subtree (to the actual sources); they are not
mirrored and I have to think about a method to handle them. I have
started to do tackle the changes and will continue to do so over the
next weekend; I hope to have it settled by then.
If you have more material, where you think it should be available in
the TDS area, please send it to me or tell me an ftp site. If you
think there should be changes in file names/directory structures, I'm
open for improvement proposals.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Thu, 25 May 1995 11:21:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:20:40 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251620.MAA15815@jasper.ora.com>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: MORE READING: 0.77
Reply-To: TWG-TDS@SHSU.edu
> > I used tdsguide 1.1; is the header on the title page my fault (old
> > version of some style)?
>
> It seems so, I have noticed but can't reproduce this problem here. I
> use fancyheadings.sty version 1.7, perhaps you might want to check
> this.
I had, gulp, 1.1.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Debugging is 99% complete most of the time" --
Production Tools Specialist | Fred Brooks, jr.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
Archive-Date: Thu, 25 May 1995 11:24:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:23:23 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251623.MAA15933@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: it get's less... 0.76
Reply-To: TWG-TDS@SHSU.edu
> (a) there is no CTAN:doc/ directory [:-)]
>
> Oops. Several CTAN:doc/'s need to be changed to CTAN:documentation/'s.
> Sorry, Norm.
Fixed.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Nothing is so smiple that it can't get screwed
Production Tools Specialist | up.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
Archive-Date: Thu, 25 May 1995 11:24:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:23:49 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251623.MAA15959@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: 0.76 comments
Reply-To: TWG-TDS@SHSU.edu
> oops!
> i knew when i saw this i should have spoken up:
>
> ftp.dante.de:/tex/-archive
> ftp.shsu.edu:/tex-archive
> ftp.tex.ac.uk:/tex-archive
>
> i think we've got one too many slashes in the first line.
> still in v 0.77.
Fixed.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | First time surrealists are often confused by the
Production Tools Specialist | similarities between fish and telephones.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
Archive-Date: Thu, 25 May 1995 11:36:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:35:27 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251635.MAA16416@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: 0.77 comments
Reply-To: TWG-TDS@SHSU.edu
> this.) It may be convenient to store implementations
> (\application{em{\TeX}}, \application{PC{\TeX}}, etc.) as well
> as utilities (\command{dvips}, \command{MakeIndex}, etc.) in
> their own directories. Implementations can store implementation-specific
>
> This bit is confused, both typographically and semantically. How about
> this:
>
> Both implementations (\application{em{\TeX}},
> \application{PC{\TeX}}, etc.) and
> utilities (\application{dvips}, \application{MakeIndex}, etc.)
> are included here. Sites can thus store implementation-specific
Ok.
> ``local'' files, since that would require duplicating the entire tree.
>
> ``local'' files => locally-maintained files (e.g., letterheads)
Check.
> files which can also be used with {\LaTeX} or {\AMSTeX} and other
>
> Now that I see it in print, I think it's better to delete the `or
> {\AMSTeX}' here. Whether it should ``and other formats'' or ``or other
> formats'' is a matter of debate -- I think we previously decided
> anything in tex/generic/ has to work with at least tex and latex, didn't
> we? I.e., tex and amstex is not enough, since amstex doesn't do anything
> drastic to plain, like latex does.
>
> This is one of the weakest points of the standard ... exactly what goes
> in generic/. But, clearly now is not the time for further debate!
I'm leaving it "LaTeX and other formats", for now.
> At the moment there aren't any besides the standard distribution,
>
> besides the => besides those in the
Check.
> little more we can do.
>
> little => no
Check.
> American Mathematical Society, Providence, \abbr{ri}, \abbr{u.s.a}.
> Editor, TUGboat;
>
> TUGboat => \citetitle{TUGboat}
Check.
> Berry, Karl (\literal{kb@cs.umb.edu}). Maintainer of \command{Web2C},
>
> \command => \application
Check.
> such as \citetitle{SunExpert} and \citetitle{UNIX Review}.
>
> UNIX => \abbr{UNIX}
Check.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | On a clear disk you can seek forever
Production Tools Specialist |
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
Archive-Date: Thu, 25 May 1995 11:36:53 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:36:17 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251636.MAA16453@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: some corrections on 0.72
Reply-To: TWG-TDS@SHSU.edu
>
> re CTAN home for TDS, its already rooted at the top-level tds/
> directory; does anyone really feel strongly that this was a bad
> decision? i dont want to undo it unless i have to. i says that TDS is
> weird enough to warrant its own tree, cos its* not* CTAN. i want it to
> have prominence
>
Fine by me.
================================================================================
Archive-Date: Thu, 25 May 1995 11:40:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:39:16 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251639.MAA16510@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: more ...
Reply-To: TWG-TDS@SHSU.edu
>
> Can we have one more draft, just to make sure the typographic problems
> are sorted out? Then I can think we can go for it.
>
Yes.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Debugging is 99% complete most of the time" --
Production Tools Specialist | Fred Brooks, jr.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
Archive-Date: Thu, 25 May 1995 11:40:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:39:55 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251639.MAA16526@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: some corrections on 0.72
Reply-To: TWG-TDS@SHSU.edu
> Sebastian just pointed out to me:
>
> the current draft says doc/tds in one place, and tds in aother :-}
>
> doc/tds should be eradicated. we're going with CTAN:tds.
Gone.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | My parents were assimilated by the Borg and all
Production Tools Specialist | I got was this lousy implant.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
Archive-Date: Thu, 25 May 1995 11:41:01 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:40:23 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251640.MAA16572@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Another TDS revision?
Reply-To: TWG-TDS@SHSU.edu
> Karl suggested to create another version before public review. Norm,
> if you do so, do you please check the version of your installed
> fancyheadings.sty?
Done.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Bill Gates should limit his salary to the number
Production Tools Specialist | of bytes addressable by the latest version of
O'Reilly & Associates, Inc. | MS-DOS, and be taxed based on the number of
90 Sherman Street | bytes of RAM needed by the latest version of
Cambridge, MA 02140 | MS-Windows.
(617) 354-5800/661-1116 FAX |
================================================================================
Archive-Date: Thu, 25 May 1995 11:48:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 12:36:17 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251636.MAA16453@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Re: some corrections on 0.72
Reply-To: TWG-TDS@SHSU.edu
>
> re CTAN home for TDS, its already rooted at the top-level tds/
> directory; does anyone really feel strongly that this was a bad
> decision? i dont want to undo it unless i have to. i says that TDS is
> weird enough to warrant its own tree, cos its* not* CTAN. i want it to
> have prominence
>
Fine by me.
================================================================================
Archive-Date: Thu, 25 May 1995 12:08:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 25 May 1995 13:07:57 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505251707.NAA18044@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: 0.78 online
Reply-To: TWG-TDS@SHSU.edu
ftp://jasper.ora.com/private/twg-tds/tds.{tex,dvi,ps}
No updated SGML files provided...
Will we be ready to go on Monday??? ;-)
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Not doing more than the average is what keeps
Production Tools Specialist | the average down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
Archive-Date: Fri, 26 May 1995 04:05:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 26 May 95 11:06:05 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505260906.AA01663@thphy.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: TDS on CTAN
Joachim wrote:
> If you have more material, where you think it should be available in
> the TDS area, please send it to me or tell me an ftp site. If you
> think there should be changes in file names/directory structures, I'm
> open for improvement proposals.
Check out CTAN:graphics/metapost/contrib/systems/web2c-mp-lib.tar.gz,
which includes the repackaged MetaPost macros and docs from the original
distribution and few other things I've thrown in, such as a null.mp file.
You may want to rename and/or repackage the file to ensure that it's
rganization is consistent with the rest of your files, but it should
contain all that's needed for a MetaPost base distribution.
Cheers,
Ulrik.
P.S. I haven't looked at your files, so I don't know if they unpack
into ./texmf/whatever or into ./whatever. How should it be done?
================================================================================
Archive-Date: Fri, 26 May 1995 16:02:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 26 May 95 11:30:50 EDT
From: karl@owl.HQ.ileaf.com (Karl Berry)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505261530.AA26520@owl.hq.ileaf.com>
To: twg-tds@shsu.edu
Subject: 0.78 comments
Looking good.
Implementations can store implementation-specific files
Implementations => Sites
latter (directory-based) scheme
Suggest deleting `(directory-based)'.
an effort to determine
an => the
I think we're ready. Could it be?
================================================================================
Archive-Date: Fri, 26 May 1995 17:11:11 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505261723.TAA18705@spice.iti.informatik.th-darmstadt.de>
Subject: Re: TDS on CTAN
To: TWG-TDS@SHSU.edu
Date: Fri, 26 May 1995 19:23:54 +0200 (MESZ)
Content-Type: text
Ulrik wrote:
>
> Joachim wrote:
>
> > If you have more material, where you think it should be available in
> > the TDS area, please send it to me or tell me an ftp site. If you
> > think there should be changes in file names/directory structures, I'm
> > open for improvement proposals.
>
> Check out CTAN:graphics/metapost/contrib/systems/web2c-mp-lib.tar.gz,
> which includes the repackaged MetaPost macros and docs from the original
> distribution [...]
>
> P.S. I haven't looked at your files, so I don't know if they unpack
> into ./texmf/whatever or into ./whatever. How should it be done?
It might be that a misunderstanding raises its head here. I would
like to emphasis that the archives in the TDS area are *not* a
distribution, they are a packaged example of a final installation of
a (very basic) system. The packaging happens for my handling
convenience, not as an example how a distribution is to be done.
I have recently changed the READMEs to reflect that issue better, I'm
in the process of improving them further. In the meantime, bear with
me. :-)
I.e., I might add a reference to that tar file, but most probably I
won't add its contents. OTOH, there might be lots of such references,
and I don't want to collect them -- that's a task for the TDS registry
effort.
Ulrik, I had more pieces like your WWW document about the doc/
tree in mind. What's the URL for that? I didn't find a link in your
home page.
Btw, people looking for a binary distribution might want to check out
Thomas' new teTeX release, at
sunsite.informatik.rwth-aachen.de:/pub/comp/tex/teTeX/.
In so far, I can't comment on the PS; I think it depends on the media
& the chosen installation procedure, it will differ from distribution
to distribution.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 26 May 1995 17:49:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 26 May 1995 15:11:24 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505261911.PAA26003@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Do me a favor...
Reply-To: TWG-TDS@SHSU.edu
Draft an announcement for me ;-) Ha, ha, only serious. ;-)
I'll try over the weekend; in any event, I'll circulate *something* on
Tuesday. (Monday is a holiday, at least here in the U.S.).
No one has commented on 0.78, which I take as a positive sign.
Enjoy, everyone.
Cheers,
norm
P.S. A show of hands, how many of you will be in St. Pete for TUG?
---
Norman Walsh <norm@ora.com> | "Whatever you do may seem insignificant, but it
Production Tools Specialist | is most important that you do it" -- Ghandi
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
Archive-Date: Sat, 27 May 1995 10:10:26 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505271509.RAA24384@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Do me a favor...
To: TWG-TDS@SHSU.edu
Date: Sat, 27 May 1995 17:09:52 +0200 (MESZ)
Content-Type: text
You wrote:
>
> P.S. A show of hands, how many of you will be in St. Pete for TUG?
Sorry, no TUG conference this year. I'll be in the US in autumn, and
I can't afford two US trips in one year.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Sat, 27 May 1995 10:19:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 27 May 1995 11:18:56 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505271518.AA08664@ra.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: draft announcement
OK, Norm, ask and ye shall receive. Here's a draft version 0.0001 :-) of
an announcement. (I wonder if there are any paper publications going
out the door soon; something along these lines should go in TTN or
TUGboat, at least, whichever comes next.)
You should probably generate the final versions in all the formats,
so we can make sure there's no sthupidities there. (If there are, the
offending formats could just be removed from the title pages that says
they're available...)
I'm not sure we should send this to the TUG board directly, but it would
probably be good for Sebastian (as our Official Liaison :-) to forward it.
Someone who knows should add the URL's for WWW retrieval and probably
change what I have into a URL.
To: texhax@tex.ac.uk, info-tex@shsu.edu, tex-archive@math.utah.edu,
tex-implementors@math.ams.org,
From: twg-tds@shsu.edu
Subject: draft of TeX Directory Structure standard available for review
A draft of the proposed TeX Directory Structure standard is available
for public review. You can get it by FTP from:
<CTAN host>:/tex-archive/tds/draft/tds.{tex,dvi,ps,html,xxxxxx}
(The `/tex-archive' may vary; see the end of this message for a list of
possible hosts.)
Comments and suggestions are welcome. Please communicate them by email to
twg-tds@shsu.edu
or by paper mail to
Norman Walsh
O'Reilly & Associates, Inc.
90 Sherman Street
Cambridge, MA 02140 USA
[xxx -- Norm, add the `USA' to the draft. Shouldn't be a comma after MA,
either.]
The primary purpose of this document is to describe a standard TeX
Directory Structure (TDS) for macros, fonts, and other such
implementation-independent TeX files. As a matter of practicality, it
also suggests ways to incorporate the rest of the TeX files into a
single structure. In the not-so-long run a consistent directory
structure will make it much easier to install and maintain TeX. We hope
that administrators and developers of both free and commercial
implementations of TeX will adopt this standard. It has been designed
to work on all modern systems. In particular, this Technical Working
Group (TWG) believes it is usable under Unix, MS-DOS, OS/2, MacOS, and VMS.
We hope to publish another draft, or make the final release (depending
on the volume of comments and concerns) shortly after TUG 95.
-- the TUG TWG on a TeX Directory Structure
prompt$ finger ctan@ftp.shsu.edu
[pip.shsu.edu]
[...]
In order to reduce network load, it is recommended that you use the
Comprehensive TeX Archive Network (CTAN) host which is located in the
closest network proximity to your site. Alternatively, you may wish to
obtain a copy of the CTAN via CD-ROM (see help/CTAN.cdrom for details).
Known partial mirrors of the CTAN reside on (alphabetically):
ftp.adfa.oz.au (Australia) /pub/tex/ctan
ftp.fcu.edu.tw (Taiwan) /pub2/tex
ftp.germany.eu.net (Deutschland) /pub/packages/TeX
ftp.cs.ruu.nl (The Netherlands) /pub/tex-archive
ftp.uu.net (Virginia, USA) /pub/text-processing/TeX
nic.switch.ch (Switzerland) /mirror/tex
Known mirrors of the CTAN reside on (alphabetically):
dongpo.math.ncu.edu.tw (Taiwan) /tex-archive
gw.pacbell.com (California, USA) /mirror/ftp.shsu.edu/tex-archive
ftp.center.osaka-u.ac.jp (Japan) /CTAN
ftp.ccu.edu.tw (Taiwan) /pub/tex
ftp.cs.rmit.edu.au (Australia) /tex-archive
ftp.duke.edu (North Carolina, USA) /tex-archive
ftp.gwdg.de (Deutschland) /pub/dante
ftp.jussieu.fr (France) /pub4/TeX/CTAN
ftp.loria.fr (France) /pub/unix/tex/ctan
ftp.mpi-sb.mpg.de (Deutschland) /pub4/tex/mirror/ftp.dante.de
ftp.muni.cz (The Czech Republic) /pub/tex/CTAN
ftp.riken.go.jp (Japan) /pub/tex-archive
ftp.uni-bielefeld.de (Deutschland) /pub/tex
ftp.uni-stuttgart.de (Deutschland) /tex-archive (/pub/tex)
ftp.usafa.af.mil (Colorado, USA) /mirrors/packages/TeX
ftp.u-aizu.ac.jp (Japan) /pub/CTAN
ftpserver.nus.sg (Singapore) /pub/zi/TeX
kadri.ut.ee (Estonia) /pub/tex
src.doc.ic.ac.uk (England) /packages/tex/uk-tex
sunsite.unc.edu (North Carolina, USA) /pub/packages/TeX
wuarchive.wustl.edu (Missouri, USA) /packages/TeX
Please send updates to this list to <CTAN-Mgr@SHSU.edu>.
The participating hosts in the Comprehensive TeX Archive Network are:
ftp.dante.de (Deutschland)
-- anonymous ftp /tex-archive (/pub/tex /pub/archive)
-- gopher on node sun.dante.de
-- e-mail via ftpmail@dante.de
-- Administrator: <ftpmaint@dante.de>
ftp.shsu.edu (Texas, USA)
-- anonymous ftp and gopher /tex-archive (/pub/tex /pub/archive)
-- NFS mountable from ftp.SHSU.edu:/pub/ftp/tex-archive
-- e-mail via ftpmail@ftp.SHSU.edu
-- World Wide Web access on www.SHSU.edu
-- Administrator: <CTAN-Mgr@SHSU.edu>
ftp.tex.ac.uk (England)
-- anonymous ftp /tex-archive (/pub/tex /pub/archive)
-- gopher on node gopher.tex.ac.uk
-- NFS mountable from nfs.tex.ac.uk:/public/ctan/tex-archive
-- World Wide Web access on www.tex.ac.uk
-- Administrator: <ctan-uk@tex.ac.uk>
================================================================================
Archive-Date: Sat, 27 May 1995 14:30:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 27 May 1995 15:29:41 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: show of hands
To: TWG-TDS@SHSU.edu
Message-ID: <801602981.201338.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
barring disasters, i'll be at the st. petersburg tug meeting.
-- bb
================================================================================
Archive-Date: Sat, 27 May 1995 14:57:09 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: show of hands
Date: Sat, 27 May 1995 20:56:14 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:157120:950527195621"@cl.cam.ac.uk>
i shall be at TUG95
s
================================================================================
Archive-Date: Sat, 27 May 1995 15:40:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 27 May 95 13:39:10 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505272039.AA23028@cfcl.com>
To: TWG-TDS@SHSU.edu
Subject: Re: show of hands
It looks like neither Vicki nor I will be able to get to TUG95 (SIGH).
-r
================================================================================
Archive-Date: Mon, 29 May 1995 02:40:10 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 29 May 95 09:41:10 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9505290741.AA02668@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: TDS on CTAN
Joachim wrote:
> Ulrik, I had more pieces like your WWW document about the doc/
> tree in mind. What's the URL for that? I didn't find a link in your
> home page.
I'm sorry, but I'm afraid it's not current accessible at all. Besides
it is very incomplete and I really can't afford the time to work on it
at the moment, much as I would like it.
The current state of affairs is that I've merged the files with the
actual TeX installation I've been setting up here recently, with the
intention to allow navigating through the most important directories
of the texmf tree to see what files are installed where, read some
description, and even view the individual files where appropriate.
Of course, this crucially relies on the abilitiy to access the texmf
directory via some symbolic link in the public_html directory. In our
current setup, this isn't possible at the moment because the Solaris
server disk where the texmf tree resides isn't mounted on the SunOS
machine running the WWW-Server. Therefore there is no way to access
these files by WWW at the moment, not even for local users here.
I hope we'll get this sorted out sooner or later.
Cheers,
Ulrik.
P.S. Joachim, as you're so eager to get it, I'll send you a shar file
containing the files, but I wouldn't like to put it up for distribution
at this stage. There's still a lot left to be done about it.
================================================================================
Archive-Date: Mon, 29 May 1995 10:58:05 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 29 May 1995 08:57:41 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505291557.IAA21853@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Show of hands
Not yet certain, but I plan still to try to be at the Tug meeting.
================================================================================
Archive-Date: Mon, 29 May 1995 12:37:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 29 May 95 19:33:10 SET
From: GOOSSENS@CERNVM.cern.ch
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: TDS on CTAN
To: TWG-TDS@SHSU.edu
As a member of the EuroTeX Programming Committee I am looking for somebody
(Norman?) who would be willing to come to Papendaal (in the Netherlands)
during the week of September 4th-8th to present and discuss TDS to the
European TeX users, who cannot make it to Florida this year (it means the
vast majority of them). We have a slot foreseen in the program but we
have no speaker yet. Any volunteers?
Sincere thanks. Michel Goossens
================================================================================
Archive-Date: Mon, 29 May 1995 14:49:57 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <19718.9505291944@ristol.dcs.ed.ac.uk>
To: twg-tds@shsu.edu
Subject: Comments on TeX directory structure
Date: Mon, 29 May 1995 20:44:20 +0100
From: David Aspinall <da@dcs.ed.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Dear Working Group,
I have been following the standard proposal fairly closely for some
time whilst building our new TeX installation, and I have accumulated
a few suggestions and questions. They follow below.
There is a lot of text, but I hope you will find time to consider what
I say at least briefly, and that it provides you with some useful
feedback.
Many thanks for the good work,
- David.
------------
David Aspinall, email: David.Aspinall@dcs.ed.ac.uk
Department of Computer Science, URL: http://www.dcs.ed.ac.uk/home/da
University of Edinburgh, Tel: +44 131 650 5898
King's Buildings, Fax: +44 131 667 7209
Edinburgh. EH9 3JZ
**********************************************************************
I've divided my comments following the section numbers of the draft
standard. I'm looking at version 0.77 dated 18th May.
2. Basics.
I am unhappy about the policy for "local" files. It seems to me
that keeping a separate tree for local adjustments and extensions,
whilst the ideal solution, is a large overhead. It compromises the
advantages you claim in the first place, of having a single tree
containing all TeX-related files.
Out of interest, the management of a single tree actually requires
*four* similar trees per architecture in our Unix system (for
reasons to do with controlling installation and file propagation
across the network). IMHO, doubling this represents an unreasonably
large effort for such a small number of files (probably < 1%).
I am strongly reluctant to implement it.
Instead I have followed the practise of using "local" as a package
name, or directory division, for example:
tex/latex/local/
csletter/
csthesis/
doc/html/local/
index.html /* master index to documentation */
doc/local /* documentation for local additions to
TeX tree */
Of course, this may lead to filename clashes, and the standard
decrees that search order is unspecified. But this seems no worse
than in any other case of name clash. Either the search order
should be resolved in a site-specific and non-standard way (for
example, searching "local" subtrees first), or the original files
could be removed from the tree. I have been following the first
approach, although we have no name clashes yet anyway.
I kindly ask that "local" could be reserved everywhere for this
kind of usage, so that administrators can choose between having two
TeX trees (strict orthodoxy) or making minor extensions within the
single tree (a more liberal interpretation).
3. Macros.
(i) Should "initex" be a format?
I expected to see "initex" used as a format. I thought it would be
sensible to use things like:
tex/initex/latex/base/latex.ltx (perhaps omitting "base/")
tex/initex/texinfo/texinfo.tex
So categorizing files which *generate* other formats as being
suitable for use by initex. I notice that the TDS compliant example
has an "initex" directory under "latex". It doesn't make much sense
to me to have latex.ltx stored under tex/latex/ because I understand
tex/latex to consist of inputs *used* by the latex format.
Similarly, I don't really want texinfo.tex to be on the path when
I'm already running "texinfo"; I expect to sensibly set TEXINPUTS
according to the format being used, roughly:
TEXINPUTS.<format> = $TEXMF/tex/<format>//
in Kpathsearch speak. (As indeed the standard suggests).
I think that putting all the <format> related files under
tex/<format> is an accidental reversion to archive-oriented rather
than installation-oriented organization. (Unless it is intentional
for some reason I don't understand).
(ii) LaTeX font macros.
I wanted to preserve the "supplier typeface" scheme when installing
the non-psnfss LaTeX files from the psfonts distribution, it seemed
strange to have it for tfm's, vf's, etc but not .sty and .fd's.
So I have directories like this:
tex/latex/fonts/adobe/bookman /* .sty and .fd files */
tex/latex/fonts/monotype/perpetua
In any case, I am not sure where the TDS presently proposes to put
these files? Simply using "bookman" or "perpetua" as the package
name could result in clashes. (Maybe a single directory "psfonts"
would suffice, and be the "correct" answer at the moment, though).
(iii) Huge directories.
Obviously the new situation is much better than having a single
TEXINPUTS directory! But I'm concerned that the "misc" directories
like texmf/tex/latex/misc/ could become rather big, and more
importantly contain no indication of where files came from. This
breaks one of the original advantages touted by the TDS for having a
"package" subdivision.
For example, the mixing up of "contrib/supported", and
"contrib/other" from CTAN. Might further separations be introduced?
I've used this:
tex/latex/misc from CTAN contrib/supported
tex/latex/comisc from CTAN contrib/other
tex/latex/external from other non-local sources
(but I don't like the name "comisc", particularly). We have a few
spare subdirectory levels to play with here, remember...
4. Fonts.
I've already communicated with Karl Berry about mode names, so that
he proposed the change to the "high mode" format. A few other
things I'd like to mention:
(i) "unknown" as a mode name.
Sometimes the mode of a pk or gf file may be unknown, or perhaps
generated by some defunct or seldom-used program (e.g., Knuth's
ransom font on CTAN). Therefore reserving "unknown" as a mode name
would be useful.
(ii) "unknown" and "mystery" as supplier and typeface names.
I think there is a similar need for default names for the
supplier and typeface parts of the directory structure. This is
because we may sometimes be dealing with fonts that have are not
named under Karl Berry's scheme (for example, user's fonts) and
so we shouldn't attempt to guess directories for them.
I have used "mystery" for both the supplier and typeface in these
cases, to distinguish from a font which is really officially
categorised as being from an "unknown" source.
[I notice that using the code "9" for unknown suppliers in Karl's
scheme means filenames that begin with a digit, which is (or was?)
disallowed by the TDS.]
(iii) Canonical mode names.
Something else which I talked with Karl about was the fact that
his modes.mf declares a huge number of mode names, but many are
aliases to particular "canonical" mode names (which are <=8
characters long).
I wonder whether one of the commandments ought to be "thou shalt
use canonical mode names" since this avoids potential problems with
massively duplicating pk files, or using directory names which are
too long. If this is already the intention, it should be
explicitly stated in the document.
(I use symbolic links like "laserwriter -> cx" to resolve
non-canonical names, but of course this isn't available to all
architectures).
(iv) Fontname maps.
I'm using these for generating directory names, but I'm not sure
where to put them? At the moment, I use:
texmf/fonts/fontname
I don't feel that the .map files belong in doc/fontname.
7. BibTeX.
Are subdirectories of bibtex/bib and bibtex/bst to be allowed?
I would expect the usual division by <package>. There are a huge
number of .bib files out there!
[Additional comments]
A. File dates
In making my TeX installation, I've been extremely careful to
preserve the archive file dates on the files that I install.
File dates are an invaluable clue to a file's identity, especially
since many TeX-related files do not carry version numbers.
If you agree with me, I would suggest that the standard echoed this
viewpoint, in particular urging people who distribute TeX trees to
respect original file dates as far as possilbe.
[I have experienced practical problems with this matter: Karl
Berry's get-you-going "library" set, lib.tar.gz, contains several
files with newer dates than those distributed on CTAN, though they
turn out to be identical in fact. When I upgraded our installation
to a full set of files from CTAN, it involved overwriting supposedly
newer files with "older" ones; this caused our network
file-distribution software to barf in a particularly bad way and me
to get very confused! I suspect other archiving or backup tools
could be disrupted by this kind of thing too. If people are going
to mix-and-match TeX trees it is important that file identity is
maintained]
B. A temporary subtree of TEXMF is needed
Generating pk (and other font) files on-the-fly, we need somewhere
in the tree to put these. But it cannot be the standard
distributed TEXMF directory, since (in our network, at least) it is
read-only and would create security problems besides. This is one
place where I *have* duplicated fragments of the TeX tree (seeing
no alternative), in fact, by putting a link
$TEXMF/tmp -> /usr/local/var/texmf
and making directories such as /usr/local/var/texmf/fonts.
(/usr/local/var is a world-writable temporary directory shared
across all hosts). The plan is to have a clever script
automatically install font files from /usr/local/var if they are
used several times and appear to be standardly-available fonts.
I notice that in the example compliant TeX installation, there is a
directory "fonts/tmp", which has pk files stored under mode names
only. If this is to be adopted officially, could it be documented?
[And if it is, why is <supplier>/<typeface> not included under
/tmp/pk?]
C. Library directory texmf/lib
Just as there is an optional provision for binary files, in
texmf/bin/ it would be handy to also have texmf/lib/. Particularly
since texmf/ might already be in /usr/local/lib !
(For us this contains libkpathsea.a)
D. Examples
More examples would help greatly! In the early stages of setting up
our installation, I had many questions which I resolved with the
help of real distributions of trees (including the example map.files).
E. Bugs
In the example TDS compliant installation map.files, there are
several bugs, such as:
. "fonts/src" is used instead of "fonts/source"
. mf/ does not have the designated subdirectories, and should be
called metafont/
. pk files are stored in the long filename format without also the
short filename format
================================================================================
Archive-Date: Tue, 30 May 1995 04:22:24 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0sGNQB-00005aC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 30 May 95 10:17 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: show of hands
I won't be attending TUG 95.
Alan.
================================================================================
Archive-Date: Tue, 30 May 1995 06:52:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 30 May 1995 07:51:01 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505301151.HAA07686@jasper.ora.com>
To: GOOSSENS@crnvma.cern.ch
CC: TWG-TDS@SHSU.edu
Subject: Re: TDS on CTAN
Reply-To: TWG-TDS@SHSU.edu
> As a member of the EuroTeX Programming Committee I am looking for somebody
> (Norman?) who would be willing to come to Papendaal (in the Netherlands)
> during the week of September 4th-8th to present and discuss TDS to the
I'd be willing, nay, delighted to come, but I fear it's not in my budget.
Is someone else willing and able to carry the flag to Papendaal?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Duct tape is like the Force: it has a light side
Production Tools Specialist | and a dark side and it holds the universe
O'Reilly & Associates, Inc. | together.
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
Archive-Date: Tue, 30 May 1995 07:31:48 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505301029.MAA15488@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Comments on TeX directory structure
To: TWG-TDS@SHSU.edu
Date: Tue, 30 May 1995 12:29:52 +0200 (MESZ)
CC: da@dcs.ed.ac.uk
Content-Type: text
David wrote:
>
> (i) Should "initex" be a format?
Hear, hear. (David, that was an original proposal of mine, later
rejected.) Most committee members felt that it was too much hassle to
separate the files even more just for those few INITEX-only files.
The existing directory tex/latex/initex/ in the TDS example
installation is an oversight, it was introduced at the time when we
discussed it and I forgot to delete it. Thanks for the hint, I'll
dismiss it. (I'll try to do this tonight.)
> For example, the mixing up of "contrib/supported", and
> "contrib/other" from CTAN. Might further separations be introduced?
> I've used this:
>
> tex/latex/misc from CTAN contrib/supported
> tex/latex/comisc from CTAN contrib/other
> tex/latex/external from other non-local sources
>
> (but I don't like the name "comisc", particularly). We have a few
> spare subdirectory levels to play with here, remember...
This was discussed, too. And it was felt that the introduction of a
new subdir level has two disadvantages: (1) LaTeX is handled
differently from other formats, and (2) we don't have so many spare
levels left...
> 7. BibTeX.
>
> Are subdirectories of bibtex/bib and bibtex/bst to be allowed?
>
> I would expect the usual division by <package>. There are a huge
> number of .bib files out there!
Nice idea, I'd support it. Anyone else, too?
> B. A temporary subtree of TEXMF is needed
Yep. At my installation, texmf/ is read-only, too.
> Generating pk (and other font) files on-the-fly, we need somewhere
> in the tree to put these. [...]
> I notice that in the example compliant TeX installation, there is a
> directory "fonts/tmp", which has pk files stored under mode names
> only. If this is to be adopted officially, could it be documented?
> [And if it is, why is <supplier>/<typeface> not included under
> /tmp/pk?]
Oh, that's simple to answer: Because the MakeTeXPK script from the
kpathsea 2.5 distribution does not support it. That's also the reason
why there are long file names.
That's a problem: How much shall the TDS example installation show
real usage? Shall I cut off the file listings from the fonts/tmp/pk/
tree? (Thinking about it, shouldn't it be better named fonts/pk/tmp/,
now that we turned the mode upfront?)
> C. Library directory texmf/lib
>
> Just as there is an optional provision for binary files, in
> texmf/bin/ it would be handy to also have texmf/lib/. Particularly
> since texmf/ might already be in /usr/local/lib !
>
> (For us this contains libkpathsea.a)
There is a place already: Somewhere below texmf/web2c/, most probably
in a platform-specific subdirectory. As you'll mount your texmf/ tree
on several platforms, you'll have several libkpathsea.a and won't be
able to store them in one directory anyhow. texmf/lib/ would be too
Unix-centric, IMHO; the TDS should stay platform-neutral.
> E. Bugs
>
> In the example TDS compliant installation map.files, there are
> several bugs, such as:
Oops, I checked and noticed that I forgot to update the map.* files
after the last Big Renaming (tm) [the one with src/ -> source/, and
mf/ -> metafont/]. I'll did it just now and expect that it will be on
CTAN rather soon.
I hope to be able to provide more example parts in the future. I'll
concentrate on stuff that isn't there right now. (Fonts, in particular
PostScript fonts. But I'm waiting for the new psnfss before I'm going
to approach that.)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Tue, 30 May 1995 08:05:00 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 30 May 1995 09:04:12 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505301304.AA17779@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: da@dcs.ed.ac.uk
Subject: Comments on TeX directory structure
Thanks very much for your comments.
More examples would help greatly! In the early stages of setting up
The document itself should stay small. Just putting in the two example
trees we have in the document took significant amounts of time.
We do point to the full example tree, although the document doesn't
ratify it as a ``standard''. I doubt many committee members have had
time to investigate Joachim's tree, much as we all appreciate him making
it :-). (I know I haven't done so yet.)
Just as there is an optional provision for binary files, in
texmf/bin/ it would be handy to also have texmf/lib/.
I'd be more inclined to take bin/ out than to add lib/, frankly.
I think such things vary so widely there is little point in trying to
standardize them, and they just give the wrong impression that the TDS
is trying to mandate your local sysadmin setup. (Especially spsun413 --
does anyone in the world actually have a binary directory by that name?
I doubt it.)
All that said, I suppose adding lib/ doesn't cost much. Perhaps instead
we should say `additional directories for system- and site-dependent
files, such as executables and libraries, can be added at the TeX
administrator's convenience; for example, bin/ and lib/'.
I think a change like this should come, if at all, after the public
review, and we have more of a sense.
(For us this contains libkpathsea.a)
There's little point in installing this, by the way, since it's not
(presently) a shared library ...
I kindly ask that "local" could be reserved everywhere for this
kind of usage, so that administrators can choose between having two
TeX trees (strict orthodoxy) or making minor extensions within the
single tree (a more liberal interpretation).
I like this idea. I think it will be very popular with the audience, too :-).
However, I doubt any of us wants to make a change this sweeping before
the public review draft goes out. (It will take *ages* to add all the text,
believe me.) Instead, perhaps we should have a tds.additions file that
summarizes our plans for the next draft.
(Which reminds me: Norm, the draft doesn't mention jasper anywhere any
more, does it? Because we'll want to keep that for private updates/new
versions without affecting what's on CTAN ...)
(i) Should "initex" be a format?
We've been back and forth on that a zillion times :-).
I'm sure we'll think about it again. Later.
I wanted to preserve the "supplier typeface" scheme when installing
the non-psnfss LaTeX files from the psfonts distribution, it seemed
I can't remember how that got decided.
In any case, I am not sure where the TDS presently proposes to put
these files? Simply using "bookman" or "perpetua" as the package
Just dump them all into the sty/ directory, I thought.
But I'm concerned that the "misc" directories
like texmf/tex/latex/misc/ could become rather big, and more
importantly contain no indication of where files came from.
The files themselves are supposed to contain that information. That's a
much more reliable way to do it than by a directory name.
Having a whole lot of directories containing a single file doesn't seem
like a win to me. Maybe I'm misunderstanding what you're suggesting.
(i) "unknown" as a mode name.
(ii) "unknown" and "mystery" as supplier and typeface names.
Something like this seems fine to me. After the review.
I have used "mystery" for both the supplier and typeface in these
cases, to distinguish from a font which is really officially
categorised as being from an "unknown" source.
I don't understand.
[I notice that using the code "9" for unknown suppliers in Karl's
scheme means filenames that begin with a digit, which is (or was?)
disallowed by the TDS.]
I thought leading digits were allowed now.
I wonder whether one of the commandments ought to be "thou shalt
use canonical mode names" since this avoids potential problems with
massively duplicating pk files, or using directory names which are
too long. If this is already the intention, it should be
explicitly stated in the document.
Hmm ... I suppose you're right. It's left pretty implicit as it stands.
(iv) Fontname maps.
I'm using these for generating directory names, but I'm not sure
where to put them? At the moment, I use:
My thought was texmf/fontname/*.map, considering fontname as an
``application''. Another possibility is texmf/web2c/fontname/*.map (or
`kpathsea' instead of `web2c', perhaps). It's vaguely possible other
implementations than kpathsea/web2c will use the fontname maps, though.
Are subdirectories of bibtex/bib and bibtex/bst to be allowed?
I would expect the usual division by <package>. There are a huge
number of .bib files out there!
Except .bib files (and .bst's) typically don't come in packages.
I don't think we can mandate anything here, but we should probably say
that subdirectories at the option of the installer are ok?
[I have experienced practical problems with this matter: Karl
Berry's get-you-going "library" set, lib.tar.gz, contains several
files with newer dates than those distributed on CTAN, though they
Oops. My fault. Must have lost the dates somewhere along the way.
I hate it that ftp doesn't just preserve the damn dates in the first place.
Ultra-bogosity.
I would suggest that the standard echoed this
viewpoint, in particular urging people who distribute TeX trees to
respect original file dates as far as possilbe.
Yes, this seems a good idea.
Generating pk (and other font) files on-the-fly, we need somewhere
in the tree to put these. But it cannot be the standard
This is a tough problem, and there are so many different needs out there.
We'll have to think seriously about it.
Simply including/allowing a tmp/ directory is no problem (that could
fall under the site-dependent rubric mentioned above). Any structure
below that, well ...
Thanks again for your careful comments!
================================================================================
Archive-Date: Tue, 30 May 1995 09:25:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505301423.QAA18229@spice.iti.informatik.th-darmstadt.de>
Subject: Re: TDS on CTAN
To: TWG-TDS@SHSU.edu
Date: Tue, 30 May 1995 16:23:38 +0200 (MESZ)
Content-Type: text
Norm wrote:
>
> > As a member of the EuroTeX Programming Committee I am looking for somebody
> > (Norman?) who would be willing to come to Papendaal (in the Netherlands)
> > during the week of September 4th-8th to present and discuss TDS to the
>
> I'd be willing, nay, delighted to come, but I fear it's not in my budget.
> Is someone else willing and able to carry the flag to Papendaal?
I hope to be there. Luckily, Papendaal is only a few hours to drive away.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Tue, 30 May 1995 10:30:21 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: TDS on CTAN
Date: Tue, 30 May 1995 16:26:50 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:119500:950530152717"@cl.cam.ac.uk>
i willl be at EuorTeX, the dear willing, and can TDSize if no-one
elsse does.
sebastian
================================================================================
Archive-Date: Tue, 30 May 1995 12:57:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 30 May 1995 13:56:59 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505301756.NAA19735@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: 0.78 comments
Reply-To: TWG-TDS@SHSU.edu
> Implementations can store implementation-specific files
>
> Implementations => Sites
Check.
> latter (directory-based) scheme
>
> Suggest deleting `(directory-based)'.
Check.
> an effort to determine
>
> an => the
Check.
Moving to version 0.98 and going public (without announcement yet).
Cheers,
norm
---
Norman Walsh <norm@ora.com> | If your nose runs and your feet smell, you're
Production Tools Specialist | built upside down.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
Archive-Date: Tue, 30 May 1995 13:01:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 30 May 1995 14:00:13 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199505301800.OAA19764@jasper.ora.com>
To: David Aspinall <da@dcs.ed.ac.uk>
CC: TWG-TDS@SHSU.edu
Subject: Comments on TeX directory structure
Reply-To: TWG-TDS@SHSU.edu
David,
Your comments are very much appreciated. However, there will be no more
significant changes to the document before the first public release.
We will review your suggestions as soon as possible.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "It can be shown that for any nutty theory,
Production Tools Specialist | beyond-the-fringe political view or strange
O'Reilly & Associates, Inc. | religion there exists a proponent on the Net.
90 Sherman Street | The proof is left as an exercise for your
Cambridge, MA 02140 | kill-file."
(617) 354-5800/661-1116 FAX |
================================================================================
Archive-Date: Wed, 31 May 1995 03:45:42 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: da@dcs.ed.ac.uk
Subject: Re: Comments on TeX directory structure
Date: Wed, 31 May 1995 09:43:38 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:232320:950531084401"@cl.cam.ac.uk>
I'd concur with David that reserving "local" is a good idea; and i'd
assumed that bst files would have a package structure too.
but your cs*.cls/sty should be a package called edinbcs, IMHO
>
> I wanted to preserve the "supplier typeface" scheme when installing
> the non-psnfss LaTeX files from the psfonts distribution, it seemed
> strange to have it for tfm's, vf's, etc but not .sty and .fd's.
>
> So I have directories like this:
>
> tex/latex/fonts/adobe/bookman /* .sty and .fd files */
> tex/latex/fonts/monotype/perpetua
>
> In any case, I am not sure where the TDS presently proposes to put
> these files? Simply using "bookman" or "perpetua" as the package
> name could result in clashes. (Maybe a single directory "psfonts"
> would suffice, and be the "correct" answer at the moment, though).
an interesting question. it should be addressed in the documenattion
for the new psfonts (have you seen fonts/psfonts.beta?). i'd propose
tex/latex/psfonts/<supplier>/<font> to mimic exactly the distribution
names. does that hit too many directory levels? unless Karl disagrees,
i'll document this somewhere. PSNFSS is a package of itself, as it
combines various fonts in one style file.
> (iii) Huge directories.
>
> Obviously the new situation is much better than having a single
> TEXINPUTS directory! But I'm concerned that the "misc" directories
> like texmf/tex/latex/misc/ could become rather big, and more
people can abuse anything. you cant *not* have a misc...
sebastian
================================================================================
Archive-Date: Wed, 31 May 1995 05:09:42 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505311003.MAA14101@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Comments on TeX directory structure
To: TWG-TDS@SHSU.edu
Date: Wed, 31 May 1995 12:03:31 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> (Which reminds me: Norm, the draft doesn't mention jasper anywhere any
> more, does it? Because we'll want to keep that for private updates/new
> versions without affecting what's on CTAN ...)
After the public review release, our new versions will be available as
CTAN:tds/working-paper/, to distinguish it from CTAN:tds/draft/ where
the version advertised for public review will stay.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 31 May 1995 05:13:54 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505311003.MAA14101@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Comments on TeX directory structure
To: TWG-TDS@SHSU.edu
Date: Wed, 31 May 1995 12:03:31 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> (Which reminds me: Norm, the draft doesn't mention jasper anywhere any
> more, does it? Because we'll want to keep that for private updates/new
> versions without affecting what's on CTAN ...)
After the public review release, our new versions will be available as
CTAN:tds/working-paper/, to distinguish it from CTAN:tds/draft/ where
the version advertised for public review will stay.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 31 May 1995 07:58:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 31 May 1995 08:57:41 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: Comments on TeX directory structure
To: TWG-TDS@SHSU.edu
Message-ID: <801925061.61839.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
i'd like to second karl's suggestion for a tds.additions file, or
something like it.
actually, maybe tds.suggestions might be better -- it could list
suggestions with a brief comment about whether the item is new, is
planned for inclusion, or had been discussed previously and rejected.
i also like the idea of a specific "local" level -- first item in
the supplementary file?
-- bb
================================================================================
Archive-Date: Wed, 31 May 1995 09:16:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 31 May 1995 10:16:03 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505311416.AA29055@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Comments on TeX directory structure
After the public review release, our new versions will be available as
CTAN:tds/working-paper/, to distinguish it from CTAN:tds/draft/ where
As a user, I would never guess that `draft' is more public than
`working-paper'.
I suggest tds/public-review-version and tds/working-drafts, or something
equally unequivocal.
Actually, I think I'd suggest the drafts don't go on CTAN at all,
but just on jasper.
================================================================================
Archive-Date: Wed, 31 May 1995 09:18:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 31 May 1995 10:18:07 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199505311418.AA29067@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Comments on TeX directory structure
tex/latex/psfonts/<supplier>/<font> to mimic exactly the distribution
names. does that hit too many directory levels? unless Karl disagrees,
*I* don't disagree, but I seem to remember latex folk preferring
other arrangements. I don't remember the details any more, and I'm too
worn out to look it up in the archives ...
Archive-Date: Thu, 01 Jun 1995 08:14:35 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 1 Jun 1995 09:14:02 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199506011314.JAA19728@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: CTAN:/tds organization (YIKES!)
Reply-To: TWG-TDS@SHSU.edu
>
> After the public review release, our new versions will be available as
> CTAN:tds/working-paper/, to distinguish it from CTAN:tds/draft/ where
>
> As a user, I would never guess that `draft' is more public than
> `working-paper'.
>
> I suggest tds/public-review-version and tds/working-drafts, or something
> equally unequivocal.
>
> Actually, I think I'd suggest the drafts don't go on CTAN at all,
> but just on jasper.
I agree. Actually, I just looked at /tds on CTAN for the first time and
I'm a little disturbed by the volume of material. I think it's too confusing.
I'd like to recommend a sweeping reorganization of that area:
IMHO,
/tds/draft-standard should be a mirror of ftp://jasper.ora.com/pub/twg-tds
/tds/supplementary-materials should contain everything else (i.e., everything
that is currently in the /tds tree).
/tds/README should be a symlink to draft-standard/README
/tds/ANNOUNCE should be a symlink to draft-standard/ANNOUNCE
And let's get rid of the SGML files and other old versions and stuff that
are currently in /tds (and would go in /tds/supplementary-materials under
my scheme).
Comments?
Cheers,
norm
---
Norman Walsh <norm@ora.com> | Bill Gates should limit his salary to the number
Production Tools Specialist | of bytes addressable by the latest version of
O'Reilly & Associates, Inc. | MS-DOS, and be taxed based on the number of
90 Sherman Street | bytes of RAM needed by the latest version of
Cambridge, MA 02140 | MS-Windows.
(617) 354-5800/661-1116 FAX |
================================================================================
Archive-Date: Thu, 01 Jun 1995 08:15:57 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 1 Jun 1995 09:15:29 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199506011315.JAA19751@jasper.ora.com>
To: twg-tds@shsu.edu
Subject: Draft Standard 0.98 available publically
Reply-To: TWG-TDS@SHSU.edu
Folks,
I've installed the draft standard 0.98 in the "public" places on jasper:
ftp://jasper.ora.com/pub/twg-tds
and
http://jasper.ora.com/twg-tds
If no one finds errors in these files, I'll make the public announcement
on Monday morning.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | You are in a twisty little maze of URLs, all
Production Tools Specialist | alluring.
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
Archive-Date: Thu, 01 Jun 1995 18:15:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 1 Jun 1995 19:13:41 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506012313.AA29138@terminus.cs.umb.edu>
To: twg-tds@shsu.edu
Subject: Re: CTAN:/tds organization (YIKES!)
/tds/draft-standard should be a mirror of ftp://jasper.ora.com/pub/twg-tds
/tds/supplementary-materials should contain everything else (i.e., everything
that is currently in the /tds tree).
/tds/README should be a symlink to draft-standard/README
/tds/ANNOUNCE should be a symlink to draft-standard/ANNOUNCE
Comments?
Sounds good to me.
> Actually, I think I'd suggest the drafts don't go on CTAN at all,
> but just on jasper.
I agree.
I think doing this (keeping the commitee-only drafts only on jasper)
will do a lot to reduce confusion. I really hope this is how it ends up.
================================================================================
Archive-Date: Thu, 01 Jun 1995 18:44:35 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506012343.BAA16261@spock.iti.informatik.th-darmstadt.de>
Subject: Re: CTAN:/tds organization (YIKES!)
To: TWG-TDS@SHSU.edu
Date: Fri, 2 Jun 1995 01:43:18 +0200 (MESZ)
Content-Type: text
Norm wrote:
>
> I agree. Actually, I just looked at /tds on CTAN for the first time and
> I'm a little disturbed by the volume of material. I think it's too confusing.
The CTAN team can simply exclude tds/*archive* from mirroring, then
all the material you find confusing is gone.
But I want to mention that
-- I received quite some mails in the past week that told me that
they would like to see even more examples than those currently in
tds/archives/. Noone mentioned that it was too confusing.
-- I think it's important to have a backlog of old working papers
to be able to tell people about the history of our work. (More on
this below.)
> /tds/draft-standard should be a mirror of ftp://jasper.ora.com/pub/twg-tds
> /tds/supplementary-materials should contain everything else (i.e., everything
> that is currently in the /tds tree).
The CTAN team has to select the directory where they mirror my files
to, they can also stop to mirror them at all. I don't have any
problem with that, I will provide them on my ftp server anyhow. (With
currently 12 GB, ftp.th-darmstadt.de is one of the larger German
servers; the few megabytes do not matter.)
> /tds/README should be a symlink to draft-standard/README
On my ftp server, I would not do this. A README has to tell about
contents and structure of a respective subtree, to support (human)
clients that browse the archive. The README in draft-standard will
tell about the draft standard, not about the whole tds/ tree. If the
whole tds/ subtree has only the draft standard, one does not need
that subdirectory at all.
Of course, the CTAN team is free to think otherwise.
> /tds/ANNOUNCE should be a symlink to draft-standard/ANNOUNCE
That's a very good idea, OTOH.
> And let's get rid of the SGML files and other old versions and stuff that
> are currently in /tds
ftp.th-darmstadt.de:pub/tex/tds/draft/ is a direct (daily) mirror of
jasper.ora.com. If you delete the SGML files there, they will get
deleted here the next day.
As explained above, I think the drafts archive is very valuable, much
too many documents suffer from the fact that no proper history is
available for them.
In fact, when I come around to do it, I would even like to add
the complete mailing list backlog. IMHO, that's one of the most
important lessons we can learn from the TeX project: It's important
to have a good project diary, a backlog of decisions, and a
repository with old revisions. (The first two are available, and the
last is often badly missing.)
You've read the mail we recently received -- the one that puts up
lots of our old topics again? That's because the draft does not
mention the history of decisions, as standards usually do. IMO, the
mailing list backlog and draft archives are at least a small bit of a
working group memory.
Joachim
PS: I'm about to leave, and will not have Email connection until
Wednesday morning. We're going sailing for the next four days, and
won't have an Internet connection on our boat. ;-) So don't expect
further reactions from me, decide as you wish.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 02 Jun 1995 11:31:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 2 Jun 1995 09:29:37 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506021329.AA26035@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: CTAN:/tds organization (YIKES!)
As explained above, I think the drafts archive is very valuable, much
Archiving *past* drafts on CTAN:tds seems valuable.
(In a clearly-marked `past-drafts/' or some such directory.)
It's *future* drafts, that we are just messing around with,
that I don't think should appear on CTAN 24 hours after Norm releases one.
When we make the next public release, all the previous drafts can be put
in CTAN again (as past drafts). And so on. It's pretty trivial -- store
tds.tex in an RCS file.
In fact, when I come around to do it, I would even like to add
the complete mailing list backlog. IMHO, that's one of the most
I agree.
important lessons we can learn from the TeX project: It's important
to have a good project diary, a backlog of decisions, and a
repository with old revisions. (The first two are available, and the
last is often badly missing.)
Did anyone (Norm?) save the different drafts as they came out? I didn't.
You've read the mail we recently received -- the one that puts up
lots of our old topics again? That's because the draft does not
mention the history of decisions, as standards usually do. IMO, the
We have some rationale in there now. I'm not opposed to adding more;
especially in response to reader questions about why such-and-such is
like it is.
A simple ChangeLog for the tds directory would help.
Norm, did you keep anything like that?
================================================================================
Archive-Date: Fri, 02 Jun 1995 15:31:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 2 Jun 1995 09:29:37 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506021329.AA26035@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: CTAN:/tds organization (YIKES!)
As explained above, I think the drafts archive is very valuable, much
Archiving *past* drafts on CTAN:tds seems valuable.
(In a clearly-marked `past-drafts/' or some such directory.)
It's *future* drafts, that we are just messing around with,
that I don't think should appear on CTAN 24 hours after Norm releases one.
When we make the next public release, all the previous drafts can be put
in CTAN again (as past drafts). And so on. It's pretty trivial -- store
tds.tex in an RCS file.
In fact, when I come around to do it, I would even like to add
the complete mailing list backlog. IMHO, that's one of the most
I agree.
important lessons we can learn from the TeX project: It's important
to have a good project diary, a backlog of decisions, and a
repository with old revisions. (The first two are available, and the
last is often badly missing.)
Did anyone (Norm?) save the different drafts as they came out? I didn't.
You've read the mail we recently received -- the one that puts up
lots of our old topics again? That's because the draft does not
mention the history of decisions, as standards usually do. IMO, the
We have some rationale in there now. I'm not opposed to adding more;
especially in response to reader questions about why such-and-such is
like it is.
A simple ChangeLog for the tds directory would help.
Norm, did you keep anything like that?
================================================================================
Archive-Date: Sat, 03 Jun 1995 23:17:31 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 03 Jun 95 14:26:30 SET
From: GOOSSENS@CERNVM.cern.ch
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: TDS on CTAN
To: TWG-TDS@SHSU.edu
On Tue, 30 May 1995 16:23:38 +0200 (MESZ) Joachim Schrod said:
>Norm wrote:
>>
>> > As a member of the EuroTeX Programming Committee I am looking for somebody
>> > (Norman?) who would be willing to come to Papendaal (in the Netherlands)
>> > during the week of September 4th-8th to present and discuss TDS to the
>>
>> I'd be willing, nay, delighted to come, but I fear it's not in my budget.
>> Is someone else willing and able to carry the flag to Papendaal?
>
>I hope to be there. Luckily, Papendaal is only a few hours to drive away.
>
> Joachim
>
Thanks, Joachim, so I shall write down your name as "rapporteur" of the
tds effort. It would be nice that you (together with your collaborators)
could write a few pages (or an extended abstract, since you have your
reference document) explaining the WG's work. Deadline: end of June (I shall
henceforth only contact Joachim about technical details relating to his
presentation at Papendaal). Sincerely, Michel Goossens
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
>Computer Science Department
>Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Tue, 06 Jun 1995 19:11:58 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506070011.CAA21376@spock.iti.informatik.th-darmstadt.de>
Subject: Re: CTAN:/tds organization (YIKES!)
To: TWG-TDS@SHSU.edu
Date: Wed, 7 Jun 1995 02:11:40 +0200 (MESZ)
Content-Type: text
You wrote:
>
> As explained above, I think the drafts archive is very valuable, much
>
> Archiving *past* drafts on CTAN:tds seems valuable.
That's the stuff that's currently available on CTAN. It's the stuff
that Norm said it should be deleted in his opinion.
> Did anyone (Norm?) save the different drafts as they came out? I didn't.
All drafts released by Norm are on CTAN. I attach a list below. The
new one has not been copied to the archive yet, I've just returned
from my sailing trip (literally).
Joachim
----------------
total 5482
-rw-rw-r-- 1 3001 102 25455 Feb 26 22:27 tds-0.3-940721.tar.gz
-rw-rw-r-- 1 3001 102 515674 Feb 26 22:27 tds-0.49-941010.tar.gz
-rw-rw-r-- 1 3001 102 95279 Feb 26 22:27 tds-0.50-941118.tar.gz
-rw-rw-r-- 1 3001 102 95331 Feb 26 22:27 tds-0.60-950201.tar.gz
-rw-rw-r-- 1 3001 102 97500 Feb 26 22:27 tds-0.61-950202.tar.gz
-rw-rw-r-- 1 3001 102 97355 Feb 26 22:32 tds-0.61-950210.tar.gz
-rw-rw-r-- 1 3001 102 99313 Mar 3 18:37 tds-0.62-950302.tar.gz
-rw-rw-r-- 1 3001 102 115299 Mar 9 12:27 tds-0.64-950308.tar.gz
-rw-rw-r-- 1 3001 102 118319 Mar 11 19:14 tds-0.66-950310.tar.gz
-rw-rw-r-- 1 3001 102 133856 Mar 16 12:15 tds-0.67-950315.tar.gz
-rw-rw-r-- 1 3001 102 133529 Mar 17 17:20 tds-0.68-950316.tar.gz
-rw-rw-r-- 1 3001 102 185239 Mar 22 17:33 tds-0.69-950321.tar.gz
-rw-rw-r-- 1 3001 102 177384 Mar 30 16:16 tds-0.70-950328.tar.gz
-rw-rw-r-- 1 3001 102 143590 Apr 14 15:11 tds-0.71-950413.tar.gz
-rw-rw-r-- 1 3001 102 145025 May 8 16:55 tds-0.72-950505.tar.gz
-rw-rw-r-- 1 3001 102 104487 May 13 16:47 tds-0.74-950512.tar.gz
-rw-rw-r-- 1 3001 102 135400 May 17 12:52 tds-0.75-950516.tar.gz
-rw-rw-r-- 1 3001 102 134388 May 18 18:16 tds-0.76-950518.tar.gz
-rw-rw-r-- 1 3001 102 140689 May 19 09:36 tds-0.77-950518.tar.gz
-rw-rw-r-- 1 3001 102 101839 May 26 12:19 tds-0.78-950525.tar.gz
----------------
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Tue, 13 Jun 1995 14:27:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 13 Jun 1995 15:22:01 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199506131922.PAA16088@jasper.ora.com>
To: texhax@tex.ac.uk, info-tex@shsu.edu, tex-archive@math.utah.edu, tex-implementors@math.ams.org
CC: twg-tds@shsu.edu
Subject: Announcing: TWG-TDS Draft Standard 0.98
Reply-To: TWG-TDS@SHSU.edu
The TUG Technical Working Group on a TeX Directory Structure is
pleased to announce that a draft of the proposed TeX Directory
Structure standard is available for public review. You can get it by
FTP from:
<CTAN host>:/tex-archive/tds/draft-standard/
(The `/tex-archive' may vary; see the end of this message for a list of
possible hosts.)
The draft standard is available in LaTeX, PostScript, TeXinfo, HTML,
and SGML formats.
Comments and suggestions are welcome. Please communicate them by email to
twg-tds@shsu.edu
or by paper mail to
Norman Walsh
O'Reilly & Associates, Inc.
90 Sherman Street
Cambridge, MA 02140 USA
The primary purpose of this document is to describe a standard TeX
Directory Structure (TDS) for macros, fonts, and other such
implementation-independent TeX files. As a matter of practicality, it
also suggests ways to incorporate the rest of the TeX files into a
single structure. In the not-so-long run a consistent directory
structure will make it much easier to install and maintain TeX. We
hope that administrators and developers of both free and commercial
implementations of TeX will adopt this standard. It has been designed
to work on all modern systems. In particular, this Technical Working
Group (TWG) believes it is usable under Unix, MS-DOS, OS/2, MacOS, and
VMS.
We hope to publish another draft, or make the final release (depending
on the volume of comments and concerns) shortly after TUG 95.
-- the TUG TWG on a TeX Directory Structure
------------------------------------------------------------------------
prompt$ finger ctan@ftp.shsu.edu
[pip.shsu.edu]
[...]
In order to reduce network load, it is recommended that you use the
Comprehensive TeX Archive Network (CTAN) host which is located in the
closest network proximity to your site. Alternatively, you may wish to
obtain a copy of the CTAN via CD-ROM (see help/CTAN.cdrom for details).
Known partial mirrors of the CTAN reside on (alphabetically):
ftp.adfa.oz.au (Australia) /pub/tex/ctan
ftp.fcu.edu.tw (Taiwan) /pub2/tex
ftp.germany.eu.net (Deutschland) /pub/packages/TeX
ftp.cs.ruu.nl (The Netherlands) /pub/tex-archive
ftp.uu.net (Virginia, USA) /pub/text-processing/TeX
nic.switch.ch (Switzerland) /mirror/tex
Known mirrors of the CTAN reside on (alphabetically):
dongpo.math.ncu.edu.tw (Taiwan) /tex-archive
gw.pacbell.com (California, USA) /mirror/ftp.shsu.edu/tex-archive
ftp.center.osaka-u.ac.jp (Japan) /CTAN
ftp.ccu.edu.tw (Taiwan) /pub/tex
ftp.cs.rmit.edu.au (Australia) /tex-archive
ftp.duke.edu (North Carolina, USA) /tex-archive
ftp.gwdg.de (Deutschland) /pub/dante
ftp.jussieu.fr (France) /pub4/TeX/CTAN
ftp.loria.fr (France) /pub/unix/tex/ctan
ftp.mpi-sb.mpg.de (Deutschland) /pub4/tex/mirror/ftp.dante.de
ftp.muni.cz (The Czech Republic) /pub/tex/CTAN
ftp.riken.go.jp (Japan) /pub/tex-archive
ftp.uni-bielefeld.de (Deutschland) /pub/tex
ftp.uni-stuttgart.de (Deutschland) /tex-archive (/pub/tex)
ftp.usafa.af.mil (Colorado, USA) /mirrors/packages/TeX
ftp.u-aizu.ac.jp (Japan) /pub/CTAN
ftpserver.nus.sg (Singapore) /pub/zi/TeX
kadri.ut.ee (Estonia) /pub/tex
src.doc.ic.ac.uk (England) /packages/tex/uk-tex
sunsite.unc.edu (North Carolina, USA) /pub/packages/TeX
wuarchive.wustl.edu (Missouri, USA) /packages/TeX
Please send updates to this list to <CTAN-Mgr@SHSU.edu>.
The participating hosts in the Comprehensive TeX Archive Network are:
ftp.dante.de (Deutschland)
-- anonymous ftp /tex-archive (/pub/tex /pub/archive)
-- gopher on node sun.dante.de
-- e-mail via ftpmail@dante.de
-- Administrator: <ftpmaint@dante.de>
ftp.shsu.edu (Texas, USA)
-- anonymous ftp and gopher /tex-archive (/pub/tex /pub/archive)
-- NFS mountable from ftp.SHSU.edu:/pub/ftp/tex-archive
-- e-mail via ftpmail@ftp.SHSU.edu
-- World Wide Web access on www.SHSU.edu
-- Administrator: <CTAN-Mgr@SHSU.edu>
ftp.tex.ac.uk (England)
-- anonymous ftp /tex-archive (/pub/tex /pub/archive)
-- gopher on node gopher.tex.ac.uk
-- NFS mountable from nfs.tex.ac.uk:/public/ctan/tex-archive
-- World Wide Web access on www.tex.ac.uk
-- Administrator: <ctan-uk@tex.ac.uk>
================================================================================
Archive-Date: Tue, 13 Jun 1995 19:23:00 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Tue, 13 Jun 1995 17:23:12 -0700
Message-ID: <199506140023.RAA15688@tashkent.berkeley.edu>
To: twg-tds@shsu.edu
Subject: TWG-TDS: some minor nits
I have a few comments about the TDS copy I got from SHSU today.
1. In tds.dvi, the table of contents is a blank page.
2. I tried to re-LaTeX tds.dvi, but couldn't because I could not find the
file tdsguide.cls, either on CTAN or in a limited search on jasper.
3. Bottom of page 3: "{\tt command} Commands are typeset in italics."
Shouldn't either \tt be changed to \it or italics be changed to typewriter
type?
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
Archive-Date: Wed, 14 Jun 1995 03:08:49 CDT
Sender: owner-twg-tds@SHSU.edu
From: Bernard GAULLE <gaulle@idris.fr>
Reply-To: TWG-TDS@SHSU.edu
Date: Wed, 14 Jun 1995 10:08:53 +0200
Message-ID: <199506140808.KAA03873@murnau.idris.fr>
To: twg-tds@shsu.edu
Subject: Printer resolution
As far as i understood correctly the draft on TDS, i think that there
could be at least one problem in the future, due to the lack of no
printer resolution directory level. By now few PostScript printers can
work at various resolution, eg 300 and 600dpi, and obviously PK files
aren't the same:
????
texmf/fonts/pk/public/cm/r300/dpi300/cmr10.300pk
texmf/fonts/pk/public/cm/r600/dpi300/cmr10.300pk
????
And there is a strong probability that such facilities were
generalized by manufacturers in the next future.
Any solution?
--bg
================================================================================
Archive-Date: Wed, 14 Jun 1995 03:18:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Jun 1995 10:20:57 +0200
From: Thomas Herter <Thomas.Herter@mch.sni.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506140820.KAA11106@pgtd0143.mch.sni.de>
To: info-tex@SHSU.edu, tex-archive@math.utah.edu, tex-implementors@math.ams.org, texhax@tex.ac.uk
CC: twg-tds@SHSU.edu
Subject: Re: Announcing: TWG-TDS Draft Standard 0.98
Content-Type: text
w> The TUG Technical Working Group on a TeX Directory Structure is
w> pleased to announce that a draft of the proposed TeX Directory
w> Structure standard is available for public review. You can get it by
w> FTP from:
w>
w> <CTAN host>:/tex-archive/tds/draft-standard/
Hallo Norman,
please note, that the file tdsguide.cls is missing in the tds/draft-standard/latex
subdirectory. Moreover, I can not find this file in the whole tds tree.
I think, I would be correct to provide this class file with the LaTeX source.
Thomas.
--
Thomas Herter email: thomas.herter@mch.sni.de
+89 636-49973 100275.541@compuserve.com
================================================================================
Archive-Date: Wed, 14 Jun 1995 05:27:59 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506141005.MAA24028@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Printer resolution
To: TWG-TDS@SHSU.edu
Date: Wed, 14 Jun 1995 12:05:20 +0200 (MESZ)
CC: gaulle@idris.fr
Content-Type: text
Beranrd wrote:
>
> As far as i understood correctly the draft on TDS, i think that there
> could be at least one problem in the future, due to the lack of no
> printer resolution directory level. [...]
It's in the mode name.
>
> texmf/fonts/pk/public/cm/r300/dpi300/cmr10.300pk
That's not a valid TDS name.
texmf/fonts/pk/cx/public/cm/dpi300/cmr10.pk
^^
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 14 Jun 1995 05:40:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Jun 1995 11:40:36 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: gaulle@idris.fr, CHAA006@vms.rhbnc.ac.uk
Message-ID: <950614114036.2020341b@vms.rhbnc.ac.uk>
Subject: RE: Printer resolution
Dear Bernard --
Although not a member of TWG-TDS (merely an interested observer and
occasional contributor), I was interested yet puzzled by your recent comment:
>> As far as i understood correctly the draft on TDS, i think that there
>> could be at least one problem in the future, due to the lack of no
>> printer resolution directory level. By now few PostScript printers can
>> work at various resolution, eg 300 and 600dpi, and obviously PK files
>> aren't the same:
Firstly, if one is using a PostScript printer, presumably one is also using
the BaKoMa outline renditions of Computer Modern rather than PK-format
bitmaps? Secondly, it is not at all clear to me why it is obvious that
``PK files aren't the same'' when you cite as example:
>> ????
>> texmf/fonts/pk/public/cm/r300/dpi300/cmr10.300pk
>> texmf/fonts/pk/public/cm/r600/dpi300/cmr10.300pk
>> ????
Are you really suggesting that there should be two different versions of
CMR10.300PK, one for use at 300dpi and one at 600dpi for one and the same
printer? If you are, then (a) the CMR10.300PK when used at 600dpi will
be used only if the user asks for CMR10 scaled 500 (an unusual request),
and (b) even if he/she does ask for such a reduced size, it is not at all
clear to my why the `standard' CMR10.300PK for that printer (i.e. the 300dpi
version) will be any different to a custom 600dpi version scaled 500. The
MetaFont book, if I read it correctly, suggests that the two will be identical.
I am sure I am missing your point, but then perhaps so are many other readers,
so perhaps I could ask you to clarify?
Very best wishes,
* Phil.
================================================================================
Archive-Date: Wed, 14 Jun 1995 05:55:00 CDT
Sender: owner-twg-tds@SHSU.edu
From: Bernard GAULLE <gaulle@idris.fr>
Reply-To: TWG-TDS@SHSU.edu
Date: Wed, 14 Jun 1995 12:53:55 +0200
Message-ID: <199506141053.MAA04440@murnau.idris.fr>
To: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
CC: TWG-TDS@SHSU.edu
Subject: Re: Printer resolution
>>>>> On Wed, 14 Jun 1995 12:05:20 +0200 (MESZ),
>>>>> Joachim Schrod <schrod@iti.informatik.th-darmstadt.de> write about "Re: Printer resolution":
JS> Beranrd wrote:
>
> As far as i understood correctly the draft on TDS, i think that there
> could be at least one problem in the future, due to the lack of no
> printer resolution directory level. [...]
JS> It's in the mode name.
JS> texmf/fonts/pk/cx/public/cm/dpi300/cmr10.pk
JS> ^^
Let's imagine you are using various device resolutions in the
same document, how could you specify that in order that your
MakeTeXPK shell run with the appropriate mode name, ie
device resolution ?
Phil's opinion "The MetaFont book, if I read it correctly, suggests that
the two will be identical" let me in a puzzled state. I wonder...
--bg
================================================================================
Archive-Date: Wed, 14 Jun 1995 06:52:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Jun 1995 07:51:51 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506141151.AA06227@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu, gaulle@idris.fr
Subject: Re: Printer resolution
Let's imagine you are using various device resolutions in the
same document, how could you specify that in order that your
MakeTeXPK shell run with the appropriate mode name, ie
device resolution ?
Any given run of your dvi driver must have one and only one target
resolution. This is a logical necessity, so far as I can see. I don't
understand how it can be meaningful to generate a document for more than
one device at a time.
I think Joachim said it all: it's in the mode name.
================================================================================
Archive-Date: Wed, 14 Jun 1995 06:59:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Jun 1995 12:58:56 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950614125856.20203302@vms.rhbnc.ac.uk>
Subject: Re: Printer resolution
>> Phil's opinion "The MetaFont book, if I read it correctly, suggests that
>> the two will be identical" let me in a puzzled state. I wonder...
OK, let me clarify: do we first of all agree that the three tuning parameters,
{blacker, fillin & o_correction} will be the same for the same rendering
engine regardless of resolution: that, for example, a hypothetical LaserJet V
with available resolutions of 300, 600 & 1200 dpi will need three mode_defs,
but the only difference between them will be the pixels_per_inch? If we
don't agree here, then it is clear why you might want two different versions
of CMR10.300PK for one and the same printer; if, however, we _do_ agree,
then the MetaFont book makes it plain that these three incantations will
generate identical versions of CMR10.300GF:
$ metafont \mode=ljvthreehundredppi; mag=1; input cmr10
$ metafont \mode=ljvsixhundredppi; mag=0.5; input cmr10
$ metafont \mode=ljvtwelvehundredppi; mag=0.25; input cmr10
** Phil.
================================================================================
Archive-Date: Wed, 14 Jun 1995 07:13:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Jun 1995 08:11:31 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199506141211.IAA07412@jasper.ora.com>
To: texhax@tex.ac.uk, info-tex@SHSU.edu, tex-archive@math.utah.edu, tex-implementors@math.ams.org
CC: twg-tds@SHSU.edu
Subject: TWG-TDS: some minor nits
Reply-To: TWG-TDS@SHSU.edu
> From: vojta@math.berkeley.edu (Paul Vojta)
> Date: Tue, 13 Jun 1995 17:23:12 -0700
>
> I have a few comments about the TDS copy I got from SHSU today.
>
> 1. In tds.dvi, the table of contents is a blank page.
Fixed.
> 2. I tried to re-LaTeX tds.dvi, but couldn't because I could not find the
> file tdsguide.cls, either on CTAN or in a limited search on jasper.
Fixed. I added these files. (Joachim, if you have a more recent version
please let me know.)
> 3. Bottom of page 3: "{\tt command} Commands are typeset in italics."
> Shouldn't either \tt be changed to \it or italics be changed to typewriter
> type?
Yes. That will be corrected in the next draft.
Thanks, Paul.
These fixes are available immediately from ftp://jasper.ora.com/pub/twg-tds
They will be available from CTAN within a day or so.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "The First Amendment is often inconvenient. But
Production Tools Specialist | that is besides the point. Inconvenience does
O'Reilly & Associates, Inc. | not absolve the government of its obligation to
90 Sherman Street | tolerate speech." -- Justice Anthony Kennedy, in
Cambridge, MA 02140 | 91-155
(617) 354-5800/661-1116 FAX |
================================================================================
Archive-Date: Wed, 14 Jun 1995 07:15:13 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506141015.MAA18431@spice.iti.informatik.th-darmstadt.de>
Subject: Re: TWG-TDS: some minor nits
To: TWG-TDS@SHSU.edu
Date: Wed, 14 Jun 1995 12:15:30 +0200 (MESZ)
CC: vojta@math.berkeley.edu
Content-Type: text
Paul wrote:
>
> 2. I tried to re-LaTeX tds.dvi, but couldn't because I could not find the
> file tdsguide.cls, either on CTAN or in a limited search on jasper.
As tds/README tells, the macros are in tds/misc/, in tdsguide-1.1.tar.gz.
An unpacked version of this tar file will be provided RSN, for the
convenience of those who search the class file by name.
Actually, it was planned that latex/tds.tex should be self-contained,
but this plan was dropped somewhere on the way.
Cheers,
Joachim
PS: Don't get me wrong, but it's quite common nowadays that one has
to use the base name of a style file to find it on CTAN.
PPS: TDS folks: I sent a respective mail privately to Thomas Herter,
too.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 14 Jun 1995 09:36:55 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506141425.QAA01680@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Printer resolution
To: TWG-TDS@SHSU.edu
Date: Wed, 14 Jun 1995 16:25:09 +0200 (MESZ)
Content-Type: text
Phil wrote:
>
> OK, let me clarify: do we first of all agree that the three tuning parameters,
> {blacker, fillin & o_correction} will be the same for the same rendering
> engine regardless of resolution: that, for example, a hypothetical LaserJet V
> with available resolutions of 300, 600 & 1200 dpi will need three mode_defs,
> but the only difference between them will be the pixels_per_inch?
No. For instance, concerning HP LaserJet 4:
mode_def cx = % Canon CX, SX, LBP-LX
mode_param (pixels_per_inch, 300);
mode_param (blacker, 0);
mode_param (fillin, .2);
mode_param (o_correction, .6);
mode_common_setup_;
enddef;
mode_def ljfour = % 600dpi HP LaserJet 4
mode_param (pixels_per_inch, 600);
mode_param (blacker, .25);
mode_param (fillin, 0);
mode_param (o_correction, 1);
mode_common_setup_;
enddef;
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 14 Jun 1995 09:42:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506141125.NAA22782@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Printer resolution
To: gaulle@idris.fr (Bernard GAULLE)
Date: Wed, 14 Jun 1995 13:25:54 +0200 (MESZ)
CC: schrod@iti.informatik.th-darmstadt.de, TWG-TDS@SHSU.edu
Content-Type: text
Bernard wrote:
>
> Let's imagine you are using various device resolutions in the
> same document,
???? Sorry, but I cannot parse that sentence.
I can't use various device resolutions in one document. (I can use
different magnifications, but that's another topic, cared for by the
dpiXXX/ directories.) That's because one uses one modedef, and the
device resolution is part of that modedef. MakeTeXPK gets the modedef
from the driver, btw.
Perhaps I wasn't clear enough in my first message. Yes, there exist
devices with two resolutions, most notably HP LJ 4s and many impact
printers. For each resolution a different modedef must be used. (That
is not something we invented, that's basic METAFONT functionality.)
As the modedef is part of the full file name, the device resolution
is part of it, too.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 14 Jun 1995 11:08:53 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506141132.NAA21785@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Printer resolution
To: TWG-TDS@SHSU.edu
Date: Wed, 14 Jun 1995 13:32:22 +0200 (MESZ)
Content-Type: text
Phil wrote:
>
> Are you really suggesting that there should be two different versions of
> CMR10.300PK, one for use at 300dpi and one at 600dpi for one and the same
> printer?
Yes, Phil, there are.
E.g., one for the modedef cx, and one for the modedef ljfour. Due to
blacker (&c) differences, they might be even different. After all,
the device may (will?) render differently in 300dpi & 600dpi, too.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 14 Jun 1995 12:24:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 14 Jun 1995 18:25:00 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950614182500.20203081@vms.rhbnc.ac.uk>
Subject: Re: Printer resolution
>> E.g., one for the modedef cx, and one for the modedef ljfour. Due to
>> blacker (&c) differences, they might be even different. After all,
>> the device may (will?) render differently in 300dpi & 600dpi, too.
Ah well, I stand corrected. Whilst I was prepared to believe that in
principle one might need different mode defs, I am surprised to learn
that there really is a printer on which such subtle differences can
be observed.
** Phil.
================================================================================
Archive-Date: Thu, 15 Jun 1995 16:48:40 CDT
Sender: owner-twg-tds@SHSU.edu
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
Reply-To: TWG-TDS@SHSU.edu
Date: Thu, 15 Jun 1995 15:26:19 -0600
To: twg-tds@shsu.edu
CC: beebe@math.utah.edu
Subject: Remarks on ``A Directory Structure for TeX Files 0.98''
Message-ID: <CMM.0.91.0.803251579.beebe@plot79.math.utah.edu>
On p. 1, Introduction, paragraph 2, mention should be made of Windows NT
(it is mentioned later on).
On p. 10, end of section 4.1, it should be noted that dpi == dots per inch.
Too bad the US remains the only nation in the world using that obsolete
system of units.
On p. 10, section 4.1.1 and p. 17, section A.3, mention is made of
a filename cache. I've had such a cache implemented in my (still
unreleased) DVI driver family 3.0 since March 1992 and find that
it works quite well. The cache file is simple: just a list of
file names (mostly fonts) like this:
/usr/local/lib/tex/ams/amsfonts/pk-files/300dpi/cmbsy5.300pk
...
/usr/local/lib/tex/musictex/tfm/sluruu16.tfm
For convenience, TeX and UNIX shell style comments are supported. On
our systems, this file is about 4390 lines (208KB of file) in the
current version, covering all of our installed font files.
The final component acts as the key in a hash table lookup, and
provided the cache file is sorted, only one copy is made of the
directory path. Consequently, for our cache file, the amount of
memory required for filename strings is about 56KB, and for the hash
table itself, about 41KB, for a total of under 100KB, which is modest
in the workstation world.
Tests have shown that the time to read the cache file and internalize
it is well under a second; the contents can be tuned to local needs,
e.g. shortened to reduce internal memory use, and speed startup.
Every file open (other than for the cache file itself, and for startup
configuration files, because they might alter the cache file location)
goes through the cache algorithm:
(1) if the file is found in the cache, and can be opened
successfully, return success
(2) if the file is found in the cache, but cannot be opened,
issue a warning message about a stale cache, and go to (3)
(3) revert to directory path search
One disadvantage is that in order for the user to override the cached
location of a file, in order to provide a private replacement, s/he
must provide a modified (or empty) cache file, because the directory
order in the search path has no effect on a cache lookup. A
command-line option to the DVI driver program could do this as well,
but so far, the need has been infrequent. However, this is LESS
likely to be the case for TeX itself, since users often have modified
versions of system macro files, but rarely do for font files.
The warning message in (2) has proved to be important, because some of
our users port a portion of our TeX tree to off-campus machines,
possibly invalidating the cache.
A second disadvantage is that the 8+3 DOS filename length limitation
that led to the adoption in the TWG-TDS proposal of the
dpi300/cmr10.pk name flavor over cmr10.300pk conflicts with use of the
base filename as a key; solutions are to retain both flavors in the
tree, as proposal suggests, or to add a hack (ugh...) to my generic
file cache support code to build in knowledge of the equivalence of
dpixyz/foo.bar with foo.xyzbar. I suspect I'll stick with the former;
my DVI drivers can support both flavors of names.
A year or so ago, after I installed a new release of UNIX TeX with
directory searching, I got numerous user complaints about slow
startup. Timing tests, and use of the Sun SunOS trace, and Sun
Solaris truss, system call tracer, showed that every invocation of TeX
was taking 5 to 10 wall clock seconds to recursively read selected
directories in the TeX tree (I just counted a total of 16572 files in
455 directories). Given that we have high-performance RISC
workstations that can TeX the TeXbook at almost 20 pages/second (3 to
5 pages/sec is typical of entry-level UNIX workstations), this is a
TERRIBLE startup penalty. I therefore rebuilt TeX with the directory
path search code disabled, and thereby silenced user complaints.
While I applaud the effort at making a universal system-independent
TeX directory structure, I do caution that the performance hit at
large sites from the adoption of mandatory subdirectory path searching
in TeXware will certain make some end users unhappy. On the other
hand, it will certainly help to alleviate the problem of long search
paths; on our NeXT systems, we have already hit a stupid shell limit
of 1024 character in environment variable names, and had to trim the
default paths accordingly.
========================================================================
Nelson H. F. Beebe Tel: +1 801 581 5254
Center for Scientific Computing FAX: +1 801 581 4148
Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu
University of Utah URL: http://www.math.utah.edu/~beebe
Salt Lake City, UT 84112, USA
========================================================================
================================================================================
Archive-Date: Thu, 15 Jun 1995 17:50:06 CDT
Sender: owner-twg-tds@SHSU.edu
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
Reply-To: TWG-TDS@SHSU.edu
Date: Thu, 15 Jun 1995 15:26:19 -0600
To: twg-tds@shsu.edu
CC: beebe@math.utah.edu
Subject: Remarks on ``A Directory Structure for TeX Files 0.98''
Message-ID: <CMM.0.91.0.803251579.beebe@plot79.math.utah.edu>
On p. 1, Introduction, paragraph 2, mention should be made of Windows NT
(it is mentioned later on).
On p. 10, end of section 4.1, it should be noted that dpi == dots per inch.
Too bad the US remains the only nation in the world using that obsolete
system of units.
On p. 10, section 4.1.1 and p. 17, section A.3, mention is made of
a filename cache. I've had such a cache implemented in my (still
unreleased) DVI driver family 3.0 since March 1992 and find that
it works quite well. The cache file is simple: just a list of
file names (mostly fonts) like this:
/usr/local/lib/tex/ams/amsfonts/pk-files/300dpi/cmbsy5.300pk
...
/usr/local/lib/tex/musictex/tfm/sluruu16.tfm
For convenience, TeX and UNIX shell style comments are supported. On
our systems, this file is about 4390 lines (208KB of file) in the
current version, covering all of our installed font files.
The final component acts as the key in a hash table lookup, and
provided the cache file is sorted, only one copy is made of the
directory path. Consequently, for our cache file, the amount of
memory required for filename strings is about 56KB, and for the hash
table itself, about 41KB, for a total of under 100KB, which is modest
in the workstation world.
Tests have shown that the time to read the cache file and internalize
it is well under a second; the contents can be tuned to local needs,
e.g. shortened to reduce internal memory use, and speed startup.
Every file open (other than for the cache file itself, and for startup
configuration files, because they might alter the cache file location)
goes through the cache algorithm:
(1) if the file is found in the cache, and can be opened
successfully, return success
(2) if the file is found in the cache, but cannot be opened,
issue a warning message about a stale cache, and go to (3)
(3) revert to directory path search
One disadvantage is that in order for the user to override the cached
location of a file, in order to provide a private replacement, s/he
must provide a modified (or empty) cache file, because the directory
order in the search path has no effect on a cache lookup. A
command-line option to the DVI driver program could do this as well,
but so far, the need has been infrequent. However, this is LESS
likely to be the case for TeX itself, since users often have modified
versions of system macro files, but rarely do for font files.
The warning message in (2) has proved to be important, because some of
our users port a portion of our TeX tree to off-campus machines,
possibly invalidating the cache.
A second disadvantage is that the 8+3 DOS filename length limitation
that led to the adoption in the TWG-TDS proposal of the
dpi300/cmr10.pk name flavor over cmr10.300pk conflicts with use of the
base filename as a key; solutions are to retain both flavors in the
tree, as proposal suggests, or to add a hack (ugh...) to my generic
file cache support code to build in knowledge of the equivalence of
dpixyz/foo.bar with foo.xyzbar. I suspect I'll stick with the former;
my DVI drivers can support both flavors of names.
A year or so ago, after I installed a new release of UNIX TeX with
directory searching, I got numerous user complaints about slow
startup. Timing tests, and use of the Sun SunOS trace, and Sun
Solaris truss, system call tracer, showed that every invocation of TeX
was taking 5 to 10 wall clock seconds to recursively read selected
directories in the TeX tree (I just counted a total of 16572 files in
455 directories). Given that we have high-performance RISC
workstations that can TeX the TeXbook at almost 20 pages/second (3 to
5 pages/sec is typical of entry-level UNIX workstations), this is a
TERRIBLE startup penalty. I therefore rebuilt TeX with the directory
path search code disabled, and thereby silenced user complaints.
While I applaud the effort at making a universal system-independent
TeX directory structure, I do caution that the performance hit at
large sites from the adoption of mandatory subdirectory path searching
in TeXware will certain make some end users unhappy. On the other
hand, it will certainly help to alleviate the problem of long search
paths; on our NeXT systems, we have already hit a stupid shell limit
of 1024 character in environment variable names, and had to trim the
default paths accordingly.
========================================================================
Nelson H. F. Beebe Tel: +1 801 581 5254
Center for Scientific Computing FAX: +1 801 581 4148
Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu
University of Utah URL: http://www.math.utah.edu/~beebe
Salt Lake City, UT 84112, USA
========================================================================
================================================================================
Archive-Date: Fri, 16 Jun 1995 11:30:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 16 Jun 1995 10:31:48 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506161431.AA22985@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu, beebe@math.utah.edu
Subject: Re: Remarks on ``A Directory Structure for TeX Files 0.98''
A year or so ago, after I installed a new release of UNIX TeX with
directory searching, I got numerous user complaints about slow
Disk-based searching is unavoidably slow.
The TDS tree is less maintainable than the web2c 6.1 tree, precisely to
try to speed up this case. Personally, I think that is a futile effort,
but other developers did not want to implement caching -- even though,
as you say, that solves the problems, and it's easy to do. Sigh. But,
it's not going to change now, I very much doubt.
web2c 6.1 + the kpathsea 2.6 patch (which has the caching) doesn't have
the slow startup problems.
TERRIBLE startup penalty. I therefore rebuilt TeX with the directory
path search code disabled, and thereby silenced user complaints.
Disabling the code is certainly a draconian solution!
But, whatever worked.
Thanks for your comments, of course.
================================================================================
Archive-Date: Fri, 16 Jun 1995 15:20:10 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Fri, 16 Jun 1995 13:20:30 -0700
Message-ID: <199506162020.NAA20939@tashkent.berkeley.edu>
To: twg-tds@shsu.edu
Subject: one more minor comment on TWG-TDS
I have one more minor comment on TWG-TDS:
On page 19, ``availble'' (spelling).
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
Archive-Date: Mon, 19 Jun 1995 18:24:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 19 Jun 1995 15:13:11 +0200
From: David Kastrup <dak@pool.informatik.rwth-aachen.de>
Reply-To: TWG-TDS@SHSU.edu
Subject: A few notes to the TDS-standard
To: twg-tds@shsu.edu
Message-ID: <199506191313.PAA14206@stan.goethe.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
The TDS standard specifies that the directories dpi??? contain the
resolution in dpi in the file name. However, it is never mentioned
*what* this means. The resolution, as seen by metafont, is a fixed
point number. The resolution in file names usually is a natural
number. Magstep calculation gives, exactly, irrational numbers.
So how to arrive at the integer to be used? Using metafont arithmetic,
or real arithmetic? Using truncation, or rounding?
Another point: I do find it dissatisfactorily that *all* ways to
generate fonts my non-Metafont ways are supposed to yield different
directory names. As the fonts have supposedly no other mode
information than the resolution, it seems dissatisfactory to separate
their font paths in a way which makes it necessary to mention all
tools when giving a typical search path.
For example, when using a deskjet and a laserjet, you will have to
specify the metafont-mode specific directories as well as *all*
directories for "device independent" 300dpi modes. I don't like
this.
--
David Kastrup, Goethestr. 20, D-52064 Aachen Tel: +49-241-72419
Email: dak@pool.informatik.rwth-aachen.de Fax: +49-241-79502
================================================================================
Archive-Date: Tue, 20 Jun 1995 07:52:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Jun 1995 14:51:46 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Magnification
To: twg-tds@shsu.edu
Message-ID: <01HRXKZ7MOXU000O4Q@VzdmzA.ZDV.Uni-Mainz.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Well, the magnification is in fact well defined, and is always rational,
even in the case of \magstephalf. The authorative source of this is plain
TeX, where magstephalf is defined to be 1095. All other magsteps are of the
same accuracy (this matters only for magstep 4 and 5). I have changed the
Sauter tools in version 2.3 to reflect this policy, the new release of the
dc fonts will do so, too.
The dpi numbers are a problem, because they are even more rounded. Sensible
dvi-driver always examine a number `one off' if the initial load failed.
--J"org Knappen.
P.S. As far as <mode> in non-MF fonts is concerned, one could stretch the
notion of mode to the method of deriving a tfm file and vf files from the
original ps fonts, which would give us ``modes'' like afmtotfm, psnfss1,
psnfss2. And yes, there are good reasons to save the old versions of the
psfonts, say you want to print replacement pages for a already published
book.
================================================================================
Archive-Date: Tue, 20 Jun 1995 15:40:17 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Tue, 20 Jun 1995 12:40:55 -0700
Message-ID: <199506201940.MAA24245@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Magnification
On Tue Jun 20 06:58:50 1995, KNAPPEN@VKPMZD.kph.Uni-Mainz.DE writes:
> Well, the magnification is in fact well defined, and is always rational,
> even in the case of \magstephalf. The authorative source of this is plain
> TeX, where magstephalf is defined to be 1095.
IMHO, the authoritative source is the TeXbook, which states on page 17:
There's also \magstephalf, which magnifies by $\sqrt{1.2}$, i.e.,
halfway between steps 0 and 1.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
Archive-Date: Tue, 20 Jun 1995 15:55:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 20 Jun 1995 16:55:03 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506202055.AA14732@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu, dak@pool.informatik.rwth-aachen.de
Subject: Re: A few notes to the TDS-standard
*what* this means. The resolution, as seen by metafont, is a fixed
point number. The resolution in file names usually is a natural
Clearly, you are right and we should clarify this in the next version.
The intent, at least in my mind, is that the ``dpi'' is the
resolution part of the name that Metafont generates. Which is to say,
the rounded integer of hppp at the first shipout time.
For example, when using a deskjet and a laserjet, you will have to
specify the metafont-mode specific directories as well as *all*
directories for "device independent" 300dpi modes. I don't like this.
I don't like it either. xdvi's path, for example, is complicated as it
stands in order to get bitmaps for PostScript fonts.
But, I don't know of a viable alternative. Can you offer one?
================================================================================
Archive-Date: Tue, 20 Jun 1995 16:35:01 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506202050.WAA20213@spice.iti.informatik.th-darmstadt.de>
Subject: Re: A few notes to the TDS-standard
To: TWG-TDS@SHSU.edu
Date: Tue, 20 Jun 1995 22:50:23 +0200 (MESZ)
CC: dak@pool.informatik.rwth-aachen.de
Content-Type: text
David wrote:
>
> The TDS standard specifies that the directories dpi??? contain the
> resolution in dpi in the file name. However, it is never mentioned
> *what* this means.
The same number as used by MF in its output file name.
Norman, do you add this clarification to the TODO list?
> Another point: I do find it dissatisfactorily that *all* ways to
> generate fonts my non-Metafont ways are supposed to yield different
> directory names. As the fonts have supposedly no other mode
> information than the resolution, it seems dissatisfactory to separate
> their font paths in a way which makes it necessary to mention all
> tools when giving a typical search path.
>
> For example, when using a deskjet and a laserjet, you will have to
> specify the metafont-mode specific directories as well as *all*
> directories for "device independent" 300dpi modes. I don't like
> this.
Any counter-proposals? How about
fonts/pk/non-mf/<utility>/dpi<dpi>/<font>.pk
? This way one would have only two directory (trees) in the search path.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Thu, 22 Jun 1995 19:27:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 23 Jun 1995 02:27:57 CET +0100
From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" <SPIELER@linac.ikp.physik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Message-ID: <00992499.6AF00BC4.1@linac.ikp.physik.th-darmstadt.de>
Subject: Comments and questions concerning draft 0.98, directory layout
Hello, Dear TWG-TDS committee!
I have tried to convert our local TeX installation (VMS) to the directory
layout as recommended by TDS draft 0.98. This work resulted in the
following comments and questions:
A) I do not like the name `source' for the root of the merged
METAFONT font sources (.mf) and property list (.pl) files tree.
I would prefer the name "/texmf/fonts/mf/" over "/texmf/fonts/source/".
And, the `property list' (.pl) files should get their own subtree,
headed with "/texmf/fonts/pl".
The name "..../source" is somehow inconsistent, since the other
subtrees <type> names specify the file type more precicely.
If you want to stay with `source', it would be consequent to
merge ALL font sources (namely: METAFONT, property list, and type1 (!!))
under this subtree root. Similary, the `afm' and `tfm' subtrees should
should then merged in a common subtree named something like `metric';
and all pixel file formats (.pk, .gf, and the obsolete .pxl) should
be located under a common `bitmap' root:
/texmf
/fonts
/source/<vendor>/<typeface> .mf, .pl, .pfa, .pfb, .mp (...) files
/metric/<vendor>/<typeface> .afm, .tfm (...) files
/bitmap/<vendor>/<typeface> .gf, .pk, .pxl (...) files
B) There are some `non-font' metric files (used for test purpose) that
do not fit well in the TDS structure, examples are `dummy.tfm' (supplied
with the AMS fonts, and used for syntax checking) and `trip.tfm'.
In my opinion, the TDS standard should specify a reserved <typeface>
name where these nonprintable font metrics and there respective
sources can be located.
(By the way, is there a reserved `misc' <typeface> name for
`single file font packages', similar to the `misc' package name in
the tex macro tree?)
C) In my eyes, the location of the .mft style files under the reserved format
name mft in the TeXinputs tree is a bad idea. These .mft files are not
used by TeX at all. Many implementations of the MFT program do not
automatically scan the TeXinputs path for .mft files (e.g. emTeX,
including the betatest releases; or Public MFT for DOS; or the DECUS VMS
implementation). The `tradition' mentioned in the TDS document seems
to be based solely on one or two (but quite popular) UNIX implementations
where MFT was modified to search the TeXinputs path for .mft style files.
The right solution would be a top level directory "mft/" under "/texmf/"
for the mft style files, the "mftmac.tex" macros should be put into
the same location as for example "webmac.tex" (probably
"/texmf/tex/plain/misc" , or "/texmf/tex/plain/base").
If do not want to specify a top level directory for the currently
available four mft style files (plain.mft, cmbase.mft, e.mft, and a
polish.mft; name are from CTAN), an alternative would be to
put them in the same directory as the .mf source files they accompany.
D) I have found some inconsistencies between the draft document and
Joachim Schrod's sample installation:
a) The draft locates the /hyphen directory below /generic, but
in map.files it is a <format> directory.
b) Should special files of a format package which are only used for
the IniTeX run located under <format>/base (as the documents recommends),
or should they put under <format>/initex (as in map.files)?
(This is problematic especially for LaTeX2e's ".ltx" files.)
c) In the sample installation, the config files for LaTeX are partly
collected in /texmf/tex/latex/config/, but texsys.cfg resides in
/texmf/tex/latex/initex/ !
(Where should I put my other IniTeX-only LaTeX config files, as
hyphen.cfg, fontmath.cfg ?)
A side remark:
When many different packages of a given format use local configuration
files, collecting all these files in the common "reserved package"
directory "config/" might lead to a quite (over)crowed configuration
directory. Somebody who is not familiar with the installed packages
may have difficulties to associate the config files with their
package directory.
E) A last question:
How should the `musictex' package get installed? The musictex macros
are primarily intended to be used with plain TeX, but there is an
additional LaTeX interface (usable for smaller sample insertions).
The LaTeX style files should probably go into /texmf/tex/latex/musictex/;
but the main macros, should the located under "plain" or under "generic"
(The main macros are needed by the LaTeX interface!).
I wish that my comments and questions help to clarify the TDS standard
document.
Many thanks,
Christian Spieler
================================================================================
Archive-Date: Fri, 23 Jun 1995 03:02:36 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Fri, 23 Jun 1995 01:03:09 -0700
Message-ID: <199506230803.BAA26869@tashkent.berkeley.edu>
To: twg-tds@shsu.edu
Subject: A comment on the proposed TDS standard
The proposed TeX Directory Structure (TDS) standard discusses how a
subdirectory structure can help with system administration. However,
I would also like to see some provision for expanding the allowable name
space for TeX input files.
As I see it, TeX currently has a problem: the name space for \input files
is too small. For example, the TDS can accommodate at most one article.sty
file. This has the following disadvantages:
o Since LaTeX 209 has an ``article'' style, AmSTeX cannot have one;
instead they end up calling their article style ``amsart.''
o A smooth transition from LaTeX 209 to LaTeX2e was possible only because
style files changed their suffix from .sty to .cls. But I would
hate to be changing suffixes every time there's a major new release
of LaTeX.
What I would like to see would be something modeled after the way #include
files are handled in C. Specifically, one should be able to say, e.g.,
\input latex2e/article.sty
and have TeX look for files named article.sty within the directory
texmf/tex/latex2e instead of within the directory texmf/tex.
I first heard this idea (possibly slightly different) from Tomas Rokicki,
and I think it's a good one.
Given the lateness of this suggestion, it may be a bit much to expect this
to go in as a required part of the standard. But I feel that it should be
seriously considered at some point. One possibility would be to mention
it as an optional extension.
Sincerely,
Paul Vojta
vojta@math.berkeley.edu
================================================================================
Archive-Date: Fri, 23 Jun 1995 04:43:43 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 23 Jun 95 10:43:27 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9506230943.AA19354@r8d.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: vojta@math.berkeley.edu
Subject: Re: A comment on the proposed TDS standard
> As I see it, TeX currently has a problem: the name space for \input files
> is too small. For example, the TDS can accommodate at most one article.sty
> file. This has the following disadvantages:
In fact this is not true (and there are article.sty files in both the
old 2.09 distribution, if you decide to keep it on your local machine)
and the current LaTeX distribution.
The TDS structure suggests setting separate TEXINPUT paths (in environment
variables or config files or dialog boxes or whatever) for each
format. So there may well be an article.sty under texmf/tex/latex and
another one under texmf/tex/latex209
> o A smooth transition from LaTeX 209 to LaTeX2e was possible only because
> style files changed their suffix from .sty to .cls. But I would
> hate to be changing suffixes every time there's a major new release
> of LaTeX.
Style files in 2e still mainly have .sty extension, (array.sty etc)
and even for the `main' style files which do become .cls under the new
LaTeX, we still distribute article.sty so as to support third party
files that were written by extending article.sty as in
\input{article.sty}
\renewcommand{.....}
> What I would like to see would be something modeled after the way #include
> files are handled in C. Specifically, one should be able to say, e.g.,
> \input latex2e/article.sty
> and have TeX look for files named article.sty within the directory
> texmf/tex/latex2e instead of within the directory texmf/tex.
This would not work for the example you give (although the extended
input searching might be useful in other contexts)
The LaTeX syntax for inputting `article' is \documentclass{article}
and putting explicit paths in a document is a `bad thing' as it messes
upo document portability. So in order for this to work the LaTeX
kernel would need to be changed so that \documentclass{article}
resolved down to \input latex2e/article.cls. However as we have to
make LaTeX work on a variety of machines (some without any notion of a
directory structure) I do not see how we could do this in any portable
way.
David
================================================================================
Archive-Date: Fri, 23 Jun 1995 10:55:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506231102.NAA13158@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Comments and questions concerning draft 0.98, directory layout
To: TWG-TDS@SHSU.edu
Date: Fri, 23 Jun 1995 13:02:16 +0200 (MESZ)
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Content-Type: text
Christian wrote:
>
> A) I do not like the name `source' for the root of the merged
> METAFONT font sources (.mf) and property list (.pl) files tree.
`source-for-mfware' was too long and wasn't ISO 9660 compliant... :-)
> I would prefer the name "/texmf/fonts/mf/" over "/texmf/fonts/source/".
> And, the `property list' (.pl) files should get their own subtree,
> headed with "/texmf/fonts/pl".
> The name "..../source" is somehow inconsistent, since the other
> subtrees <type> names specify the file type more precicely.
Hmm, type1/ lumps together pfa/ & pfb/, too.
> If you want to stay with `source', it would be consequent to
> merge ALL font sources (namely: METAFONT, property list, and type1 (!!))
> under this subtree root. Similary, the `afm' and `tfm' subtrees should
> should then merged in a common subtree named something like `metric';
> and all pixel file formats (.pk, .gf, and the obsolete .pxl) should
> be located under a common `bitmap' root:
I wouldn't mind to change to such a layout. IMHO it's better than
introducing even more font-level directories.
> (By the way, is there a reserved `misc' <typeface> name for
> `single file font packages', similar to the `misc' package name in
> the tex macro tree?)
Good idea, we could put dummy.{tfm,pl} there. Btw, I think the best
place for trip.tfm is the texmf/source/ tree, as it is only needed for
the build of TeX.
> C) In my eyes, the location of the .mft style files under the reserved format
> name mft in the TeXinputs tree is a bad idea.
Full agreement.
> D) I have found some inconsistencies between the draft document and
> Joachim Schrod's sample installation:
>
> a) The draft locates the /hyphen directory below /generic, but
> in map.files it is a <format> directory.
Hmm, did we really decide to move hyphen/? Grmbl, I'm going to check
with the mail archive and will change it accordingly. (Or will come
back to the list for further discussion.)
> b) Should special files of a format package which are only used for
> the IniTeX run located under <format>/base (as the documents recommends),
> or should they put under <format>/initex (as in map.files)?
> (This is problematic especially for LaTeX2e's ".ltx" files.)
They shall be placed in <format>/base/. texsys.cfg goes to
latex/base/ if it's the unchanged version from the distribution, to
latex/config/ otherwise.
That problem with the example installation was brought to my attention
about 4 weeks ago. Since June was approaching, I decided to wait for
the new LaTeX release and fix it then. I.e., I'll do it in the
weekend, as the new release exists since two days. :)
> (Where should I put my other IniTeX-only LaTeX config files, as
> hyphen.cfg, fontmath.cfg ?)
latex/config/
> When many different packages of a given format use local configuration
> files, collecting all these files in the common "reserved package"
> directory "config/" might lead to a quite (over)crowed configuration
> directory. Somebody who is not familiar with the installed packages
> may have difficulties to associate the config files with their
> package directory.
You're completely right. OTOH, putting them in the package's directory
will yield problems when the package gets updated and one has to
decide which files must be kept and which ones can be deleted.
> [musictex] The LaTeX style files should probably go into /texmf/tex/latex/musictex/;
> but the main macros, should the located under "plain" or under "generic"
> (The main macros are needed by the LaTeX interface!).
Then they go in generic/.
> I wish that my comments and questions help to clarify the TDS standard
> document.
Thanks a lot for your comments.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 23 Jun 1995 12:38:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 23 Jun 1995 13:39:03 -0400
From: Norman Walsh <norm@ora.com>
Message-ID: <199506231739.NAA02852@jasper.ora.com>
To: TWG-TDS@SHSU.edu
Subject: Norm is on Vacation...
Reply-To: TWG-TDS@SHSU.edu
Folks,
I'll be on vacation from 6/24 (tomorrow) through 7/5. I won't
be reading mail or even thinking about computers...see you
(virtually) in a week.
Cheers,
norm
---
Norman Walsh <norm@ora.com> | "Whatever you do may seem insignificant, but it
Production Tools Specialist | is most important that you do it" -- Ghandi
O'Reilly & Associates, Inc. |
90 Sherman Street |
Cambridge, MA 02140 |------------------------------------------------
(617) 354-5800/661-1116 FAX | URL: http://jasper.ora.com/norm
================================================================================
Archive-Date: Sat, 24 Jun 1995 10:09:11 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Sat, 24 Jun 1995 08:09:51 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506241509.IAA20950@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, dak@pool.informatik.rwth-aachen.de
Subject: Re: A few notes to the TDS-standard
I am not sure I understand the question. The calculations in METAFONT yield
floating-point numbers a good deal of the time, but they are rounded
before they get to file names. There is the unfortunate fact that
some drivers at least in the past handled rounding in ways that resulted
in the tiresome conflict between 328 and 329 dpi---that used to cause
all sorts of tiresome messages---but standard magstep values, which are
hardwired into TeX (TeXbook p. 349) produce pretty standard results
nowadays. Convention has been to take the rounding done by METAFONT and
arbitrarily declare that to be "correct" for the indication of resolution.
A search on either side of the calculated value in a dvi interpreter is
going to pick up the METAFONT generated value pretty quickly.
One of the nice things about allowing a bit of fudging is that it permits
large magsteps in one series (e.g. 120dpi) to continue into another series
(e.g. 300dpi, since 120 * magstep(5.0) is 299dpi). It may not be "clean"
but it works, so long as a limited search on either side of the exact
calculated value is allowed for.
I join with Karl, of course, in deploring the complexity that has been
introduced into the pk tree, but the die is cast, the Rubicon is crossed,
the chips are down and judgement has been rendered. Long live the king.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
Archive-Date: Sat, 24 Jun 1995 11:17:41 CDT
Sender: owner-twg-tds@SHSU.edu
From: dak@POOL.Informatik.RWTH-Aachen.DE (David Kastrup)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9506241617.AA29202@tabaqui>
Subject: Re: A few notes to the TDS-standard
To: mackay@cs.washington.edu (Pierre MacKay)
Date: Sat, 24 Jun 1995 18:17:45 +0200 (MET DST)
CC: TWG-TDS@SHSU.edu
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
>
> I am not sure I understand the question. The calculations in METAFONT yield
> floating-point numbers a good deal of the time, but they are rounded
> before they get to file names.
That's just it. The TDS does not specify that the directory resolutions
are to be the rounded MF numbers. This should be clarified.
> Convention has been to take the rounding done by METAFONT and
> arbitrarily declare that to be "correct" for the indication of resolution.
This convention has to find its way into the standard.
> A search on either side of the calculated value in a dvi interpreter is
> going to pick up the METAFONT generated value pretty quickly.
>
> One of the nice things about allowing a bit of fudging is that it permits
> large magsteps in one series (e.g. 120dpi) to continue into another series
> (e.g. 300dpi, since 120 * magstep(5.0) is 299dpi). It may not be "clean"
> but it works, so long as a limited search on either side of the exact
> calculated value is allowed for.
Ugh, ugh, ugh. This is *not* the tyupesetting quality we were bargaining
for when separating even, say, HPDeskJet and hplaser directories.
>
> I join with Karl, of course, in deploring the complexity that has been
> introduced into the pk tree, but the die is cast, the Rubicon is crossed,
> the chips are down and judgement has been rendered. Long live the king.
When a draft standard is announced? Hardly.
================================================================================
Archive-Date: Sat, 24 Jun 1995 23:40:22 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Sat, 24 Jun 1995 20:49:41 -0700
Message-ID: <199506250349.UAA28878@tashkent.berkeley.edu>
To: twg-tds@shsu.edu
Subject: Re: A comment on the proposed TDS standard
CC: carlisle@cs.man.ac.uk
On Fri, 23 Jun 95 10:43:27 BST, David Carlisle <carlisle@cs.man.ac.uk> writes:
> > As I see it, TeX currently has a problem: the name space for \input files
> > is too small. For example, the TDS can accommodate at most one article.sty
> > file. This has the following disadvantages:
>
> In fact this is not true (and there are article.sty files in both the
> old 2.09 distribution, if you decide to keep it on your local machine)
> and the current LaTeX distribution.
I stand corrected.
> Style files in 2e still mainly have .sty extension, (array.sty etc)
> and even for the `main' style files which do become .cls under the new
> LaTeX, we still distribute article.sty so as to support third party
> files that were written by extending article.sty as in
> \input{article.sty}
> \renewcommand{.....}
Then perhaps the current transition from latex209 to latex2e is not so
smooth after all.
------
> > What I would like to see would be something modeled after the way #include
> > files are handled in C. Specifically, one should be able to say, e.g.,
>
> > \input latex2e/article.sty
>
> > and have TeX look for files named article.sty within the directory
> > texmf/tex/latex2e instead of within the directory texmf/tex.
>
> This would not work for the example you give (although the extended
> input searching might be useful in other contexts)
>
> The LaTeX syntax for inputting `article' is \documentclass{article}
> and putting explicit paths in a document is a `bad thing' as it messes
> upo document portability. So in order for this to work the LaTeX
> kernel would need to be changed so that \documentclass{article}
> resolved down to \input latex2e/article.cls.
That was what I had in mind. The user would say \documentclass{article}
and the LaTeX macro package would internally translate that into
\input latex2e/article.cls.
Or, someone who wanted to make up their own format called ``foobar'' would
be able to let their format have a style called ``article,'' and call
the style file ``article.sty.'' Users might then put
``\input foobar/article.sty'' in their documents, with the understanding
that directory foobar would contain the currently preferred version of the
input files for the foobar format. This is analogous to how
``#include <X11/Xlib.h>'' is handled.
> However as we have to
> make LaTeX work on a variety of machines (some without any notion of a
> directory structure)
On a variety of TeX implementations, you mean.
> I do not see how we could do this in any portable way.
How about (in the LaTeX macro package):
\def\inputdirectory{latex/}
\newread\foobar
\openin\foobar=\inputdirectory latex.tex
\ifeof\foobar % (TeXbook page 217)
\def\inputdirectory{}%
\fi
\closein\foobar
Then \documentclass{article} would eventually lead to:
\input \inputdirectory article.cls
More to the point, though, you seem to be saying, ``we can't do:
B. change \documentclass in LaTeX to expand to \input latex2e/...
right now because it requires
A. certain semantics for ``\input foo/bar[.ext]''
which is unsupported on many implementations.''
I am not asking you to change anything in LaTeX right now. I am asking
a standards body to consider change (A). Doing so would, after a period of
time, enable the LaTeX team (if they so decide) to implement (B), and give
certain benefits to other macro package authors.
That is how progress takes place in the presence of an installed base.
-------
> The TDS structure suggests setting separate TEXINPUT paths (in environment
> variables or config files or dialog boxes or whatever) for each
> format. So there may well be an article.sty under texmf/tex/latex and
> another one under texmf/tex/latex209
Suggests? In the sense of ``to mention or imply as a possibility,'' yes:
TDS> By providing a format directory, path searching can be
TDS> limited to only those directories that contain relevant files.
TDS> Although some of these formats can also
TDS> be used as macro packages, the \abbr{TDS} nevertheless stores them as
TDS> formats. By adjusting the {\TeX} inputs search
TDS> path, it is straightforward to use them as macro packages under
TDS> another format, whereas placing them in the tree of another format
TDS> would completely obscure their possible use as a format.
But, as I read it, it does not make a recommendation either for or against
this practice.
Also, later it says:
TDS> a recursive search beginning at \path|texmf/tex|
TDS> is a correct path for {\TeX} inputs in a \abbr{TDS} tree.
Putting separate paths in a config file is, IMHO, a real kludge. It means
you have to dig into the config file in order to install a format.
This makes it hard to automate such an installation. It also means that
% tex foobar
where foobar.tex contains:
\input amstex
\documentstyle{amsppt}
...
is not equivalent to
% amstex foobar
where foobar.tex contains:
\documentstyle{amsppt}
...
because the input paths will be different.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
Archive-Date: Mon, 26 Jun 1995 13:40:38 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Mon, 26 Jun 1995 11:15:22 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506261815.LAA18317@june.cs.washington.edu>
To: dak@POOL.Informatik.RWTH-Aachen.DE
CC: TWG-TDS@SHSU.edu
Subject: Re: A few notes to the TDS-standard
> One of the nice things about allowing a bit of fudging is that it permits
> large magsteps in one series (e.g. 120dpi) to continue into another series
> (e.g. 300dpi, since 120 * magstep(5.0) is 299dpi). It may not be "clean"
> but it works, so long as a limited search on either side of the exact
> calculated value is allowed for.
Ugh, ugh, ugh. This is *not* the tyupesetting quality we were bargaining
for when separating even, say, HPDeskJet and hplaser directories.
Don't get me wrong. This is a way around the endless proliferation of
SCREEN fonts, at least at this site. But I really don't expect the
difference between 299dpi and 300dpi will be noticeable in the rare
use of magstep(5.0) anyway, even if blacker and fillin values change a
bit. I found Brian Reid's diatribe about the corruption of taste
resulting from viewing fonts at 300dpi when I was cleaning up
recently. It is still true, even if he did join the corrupters.
>
> I join with Karl, of course, in deploring the complexity that has been
> introduced into the pk tree, but the die is cast, the Rubicon is crossed,
> the chips are down and judgement has been rendered. Long live the king.
When a draft standard is announced? Hardly.
The amount of momentum in a draft standard is usually overwhelming.
================================================================================
Archive-Date: Mon, 26 Jun 1995 14:19:39 CDT
Sender: owner-twg-tds@SHSU.edu
From: "ALAN A DUNWELL" <DUNWELL@jnov.colorado.edu>
To: twg-tds@shsu.edu
Date: Mon, 26 Jun 1995 13:20:00 MST
Subject: TWG-TDS 0.98....
Reply-To: TWG-TDS@SHSU.edu
CC: Hammond@Solarz
Howdy All,
Having read through your proposal I congratulate you all on your
attempts to bring some order to chaos. For the most part, what you
are proposing is similar or in line with what we have been trying to
implement locally, since we must support Mac, DOS, Windows, VMS,
VMS/AXP, Ultrix, and OSF/1. A coherent structure is very much in our
interest.
Several comments:
- On your naming of the TeX Root as texmf, I find your reasoning
quite weak. For years anything with 'mf' referred to METAFONT, not
other pieces of the TeX family. What is wrong with something as
straight forward as tex or texroot (tex_root?)?
- Comments on the TeX Root also apply to the change from 'inputs' to
'tex'. What was wrong with 'inputs' or its alternate 'macros'?
- I understand your reasons for spreading out packages into various
branches such as source, doc, tex, a tough call there. I personally
prefer to have a package in just one area, but such is life. Having
chosen this split structure, I encourage you to try to get vendors
purveyors of a package to also provide 'clean-up' scripts that will
seek-and-destroy all old version files. Even with the old system,
packages tended to have pieces and parts all over the place with not
identifiable names (e.g. RevTeX). At the very least they should
provide a program that does a recursive search on any platform and
prepares a location list of all old files. This will help provide the
poor software managers with a hope of keeping the scrap piles under
control.
Alan Dunwell
Software Manager, JILA
(aka: Cosmic Center for Detritus Accretion?)
!-----------------------------------------------------------------------!
!Reply to: !
! Alan A. Dunwell, JILA - CB440, University of Colo., Boulder,Co. 80309 !
! E-Mail - DUNWELL@JNOV.COLORADO.EDU or DUNWELL@JILA.COLORADO.EDU !
! Voice - (303) 492-5308 FAX - (303) 492-5235 !
!-----------------------------------------------------------------------!
================================================================================
Archive-Date: Tue, 27 Jun 1995 06:06:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 27 Jun 1995 12:06:34 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950627120634.202022c7@vms.rhbnc.ac.uk>
Subject: Re: A comment on the proposed TDS standard
>> How about (in the LaTeX macro package):
>> \def\inputdirectory{latex/}
>> \newread\foobar
>> \openin\foobar=\inputdirectory latex.tex
>> \ifeof\foobar % (TeXbook page 217)
>> \def\inputdirectory{}%
>> \fi
>> \closein\foobar
>> Then \documentclass{article} would eventually lead to:
>> \input \inputdirectory article.cls
Unfortunately all of this is predicated on the assumption that a directory
can be specified as a prefix; whilst this is true for some operating systems
(MS/DOS, Unix, etc.), it is not true for others (e.g. VMS) unless the
`directory' is really a logical name. Thus for VMS one has two alternate
syntaces:
\input node::disc:[directory.subdirectory]filename.extension;version
and
\input logical_name:filename.extension;version
Only the latter could be supported using the mechanism suggested.
** Phil.
================================================================================
Archive-Date: Wed, 28 Jun 1995 05:12:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 28 Jun 1995 11:11:18 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950628111118.2020463c@vms.rhbnc.ac.uk>
Subject: Sincere apologies...
... my neuron must have ceased firing when I wrote:
>> Unfortunately all of this is predicated on the assumption that a directory
>> can be specified as a prefix; whilst this is true for some operating systems
>> (MS/DOS, Unix, etc.), it is not true for others (e.g. VMS) unless the
>> `directory' is really a logical name. Thus for VMS one has two alternate
>> syntaces:
>> \input node::disc:[directory.subdirectory]filename.extension;version
>> and
>> \input logical_name:filename.extension;version
>> Only the latter could be supported using the mechanism suggested.
Only the brain-dead could have failed to realise that the directory is
a prefix in both cases; I simply cannot explain how I came to think that
it was not.
** Phil.
================================================================================
Archive-Date: Thu, 29 Jun 1995 15:53:20 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Jun 1995 16:52:07 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506292052.AA02792@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: twg-tds@shsu.edu, Hammond%Solarz@niord.shsu.edu
Subject: Re: TWG-TDS 0.98....
- On your naming of the TeX Root as texmf, I find your reasoning
quite weak. For years anything with 'mf' referred to METAFONT, not
Web2c has used a default directory of `texmf' for ``years''. No one's
ever complained about it meaning only Metafont.
other pieces of the TeX family. What is wrong with something as
straight forward as tex or texroot (tex_root?)?
I find `texmf' more straightforward than `texroot'. I guess this is a
matter of opinion.
- Comments on the TeX Root also apply to the change from 'inputs' to
'tex'. What was wrong with 'inputs' or its alternate 'macros'?
`inputs' is inappropriate because programs other than TeX have input files.
`macros' likewise, to some extent. Also, we saw no reason not to use the
program name for TeX input files just as we did for every other kind of
file. And, Web2c and perhaps other implementations have used `tex' as
the ``inputs'' directory name for quite some time.
chosen this split structure, I encourage you to try to get vendors
purveyors of a package to also provide 'clean-up' scripts that will
I agree.
================================================================================
Archive-Date: Thu, 29 Jun 1995 15:53:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Jun 1995 16:51:56 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506292051.AA02783@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Subject: Re: Comments and questions concerning draft 0.98, directory layout
merge ALL font sources (namely: METAFONT, property list, and type1 (!!))
I'm not sure type1's should be lumped with the others.
/source/<vendor>/<typeface> .mf, .pl, .pfa, .pfb, .mp (...) files
/metric/<vendor>/<typeface> .afm, .tfm (...) files
/bitmap/<vendor>/<typeface> .gf, .pk, .pxl (...) files
Seems like a good idea to me.
do not fit well in the TDS structure, examples are `dummy.tfm' (supplied
with the AMS fonts, and used for syntax checking) and `trip.tfm'.
dummy.tfm goes wherever Barbara says it goes.
As Joachim says, trip.tfm doesn't need to be installed anywhere (and
probably shouldn't be).
(By the way, is there a reserved `misc' <typeface> name for
`single file font packages', similar to the `misc' package name in
the tex macro tree?)
I don't see the need. A font always comes in multiple files, doesn't it?
The source, the metric, the glyphs. That's not true for macro packages.
C) In my eyes, the location of the .mft style files under the reserved format
name mft in the TeXinputs tree is a bad idea. These .mft files are not
I suppose. I'm not opposed to moving it to the top-level. I guess you're
right about the ``tradition'' being web2c-centric.
How should the `musictex' package get installed? The musictex macros
Can't you make a .fmt file out of it, thus texmf/tex/musictex/...?
I wish that my comments and questions help to clarify the TDS standard
Thanks for taking the trouble to send them.
================================================================================
Archive-Date: Thu, 29 Jun 1995 15:55:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Jun 1995 16:52:26 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506292052.AA02872@terminus.cs.umb.edu>
To: schrod@iti.informatik.th-darmstadt.de
CC: TWG-TDS@SHSU.edu, dak@pool.informatik.rwth-aachen.de
Subject: Re: A few notes to the TDS-standard
Any counter-proposals? How about
fonts/pk/non-mf/<utility>/dpi<dpi>/<font>.pk
I guess this is a good idea. As David pointed out to me offline, it's
dubious that anyone would ever want to search on only the gsftopk fonts
and not ps2pk, or vice versa. (And they still could do this if they
wanted, anyway.)
We do definitely have to keep the <utility> directory level, though,
since someone might generate their 300dpi times-roman with both
utilities, and the fonts aren't the same. They may not care which one
they get, but they shouldn't overwrite each other.
As a picayune point, I don't like the name `non-mf'.
How about `modeless'?
================================================================================
Archive-Date: Thu, 29 Jun 1995 23:34:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 29 Jun 1995 16:51:56 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199506292051.AA02783@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Subject: Re: Comments and questions concerning draft 0.98, directory layout
merge ALL font sources (namely: METAFONT, property list, and type1 (!!))
I'm not sure type1's should be lumped with the others.
/source/<vendor>/<typeface> .mf, .pl, .pfa, .pfb, .mp (...) files
/metric/<vendor>/<typeface> .afm, .tfm (...) files
/bitmap/<vendor>/<typeface> .gf, .pk, .pxl (...) files
Seems like a good idea to me.
do not fit well in the TDS structure, examples are `dummy.tfm' (supplied
with the AMS fonts, and used for syntax checking) and `trip.tfm'.
dummy.tfm goes wherever Barbara says it goes.
As Joachim says, trip.tfm doesn't need to be installed anywhere (and
probably shouldn't be).
(By the way, is there a reserved `misc' <typeface> name for
`single file font packages', similar to the `misc' package name in
the tex macro tree?)
I don't see the need. A font always comes in multiple files, doesn't it?
The source, the metric, the glyphs. That's not true for macro packages.
C) In my eyes, the location of the .mft style files under the reserved format
name mft in the TeXinputs tree is a bad idea. These .mft files are not
I suppose. I'm not opposed to moving it to the top-level. I guess you're
right about the ``tradition'' being web2c-centric.
How should the `musictex' package get installed? The musictex macros
Can't you make a .fmt file out of it, thus texmf/tex/musictex/...?
I wish that my comments and questions help to clarify the TDS standard
Thanks for taking the trouble to send them.
Archive-Date: Sun, 02 Jul 1995 07:21:34 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507021220.OAA21808@spock.iti.informatik.th-darmstadt.de>
Subject: Re: A few notes to the TDS-standard
To: TWG-TDS@SHSU.edu
Date: Sun, 2 Jul 1995 14:20:38 +0200 (MESZ)
CC: dak@pool.informatik.rwth-aachen.de
Content-Type: text
Pierre wrote:
>
> > One of the nice things about allowing a bit of fudging is that it permits
> > large magsteps in one series (e.g. 120dpi) to continue into another series
> > (e.g. 300dpi, since 120 * magstep(5.0) is 299dpi). It may not be "clean"
> > but it works, so long as a limited search on either side of the exact
> > calculated value is allowed for.
> Ugh, ugh, ugh. This is *not* the tyupesetting quality we were bargaining
> for when separating even, say, HPDeskJet and hplaser directories.
>
> Don't get me wrong. This is a way around the endless proliferation of
> SCREEN fonts, at least at this site.
Just a note: Of course, for _one_ modedef it's not possible to decide
when one wants to use 299dpi & when 300dpi. That's due to the
different mag computation of TeX & METAFONT.
The mail archive of the now-defunct DVI Driver Committee keeps an
analysis of Tom Rokicki how far dpi values may differ & still be the
same. I remember something about 2 pixels. (Sorry, can't look it up
currently, I'm writing this mail from home.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 03 Jul 1995 12:07:02 CDT
Sender: owner-twg-tds@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: mimi@scri.fsu.edu
Subject: draft copies at TUG95
Date: Mon, 03 Jul 1995 17:45:53 +0100
From: Sebastian Rahtz <Sebastian.Rahtz@cl.cam.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <"swan.cl.cam.:026720:950703164601"@cl.cam.ac.uk>
I have, i think, got my boss to pay for printed copies of the TDS
report, bound in with the UKTUG FAQ, to be distributed to all the
delegates at TUG95. I am just off on holiday, and it'll be toolate
when i get back, but i have left the job to be processed, so fingers
crossed i'll bring 100 copies to the US with me.
someone else can do the same for EuroTeX...
sebastian
================================================================================
Archive-Date: Wed, 05 Jul 1995 08:02:25 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <drw@umassmed.UMMED.EDU>
From: drw@umassmed.UMMED.EDU (Doug Waud)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507051301.AA03279@umassmed.UMMED.EDU>
Subject: a typo?
To: twg-tds@shsu.edu
Date: Wed, 5 Jul 95 9:01:42 EDT
Hi
I have just finished reading ``A Directory Structure for TeX files''
(V 0.98, june 14, 1995). I am pleased you are trying to get some
standardization here. Good job.
At risk of seeming picky, I write to mention a minor typo/glitch. I
find I have trouble spotting my own such boo-boos and write in the
spirit that you too may appreciate some outside help. I confess also
to feeling somewhat guilty about always being a consumer of TeX
stuff and not able (still rather inexperienced) to contribute more.
In any case, at the bottom of page 10 you explain that
files are the names ...
but I believe there is no antecedent for that ``files''. Perhaps you
had intended to put it at the end of the line
texmf/metafont/package/
eight lines earlier.
(No need to waste time on a reply just to be polite!)
drw
--
******************************************************************************
Douglas R. Waud (S7-137) (Bitnet: drw@umassmed)
Department of Pharmacology (Internet: drw@ummed.edu)
U. Massachusetts Med. Sch. (aka 146.189.16.2)
55 Lake Avenue North (FAX: 508-856 5080)
Worcester, MA, 01655-0216 (Voice: 508 856 3339)
******************************************************************************
================================================================================
Archive-Date: Wed, 05 Jul 1995 09:06:37 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 05 Jul 1995 16:06:01 CET +0100
From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" <SPIELER@linac.ikp.physik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Message-ID: <00992E79.AFD54F44.2700@linac.ikp.physik.th-darmstadt.de>
Subject: Names of the <type> level in fonts dir tree
Hello,
Joachim replied to my comment on the <type> name for Metafont/Property
list sources, where I `suggested' to merge all different types in
only three subdirs (source, metrics, bitmap):
> Christian wrote:
> > [...]
> > If you want to stay with `source', it would be consequent to
> > merge ALL font sources (namely: METAFONT, property list, and type1 (!!))
> > under this subtree root. Similary, the `afm' and `tfm' subtrees should
> > should then merged in a common subtree named something like `metric';
> > and all pixel file formats (.pk, .gf, and the obsolete .pxl) should
> > be located under a common `bitmap' root:
>
> I wouldn't mind to change to such a layout. IMHO it's better than
> introducing even more font-level directories.
>
It was not my intention to change the TDS layout in this direction. Perhaps
I was misunderstood.
In my eyes, the split of the font directory tree into different <type>
type=type1, tfm, afm, pk, etc.) branches has the intention to separate
the search paths for programs that read different formats (types) of
font information. I want the TDS to maintain this goal.
When you consider this intention, there is a difference between
`source' containing both Metafont and PLtoTF sources and `type1' containing
both binary and text PS font sources. Many programs that use PS font sources
(Postscript interpreters, or xx-to-postscript converters like `dvips') can
read both binary and text format PS sources, here it makes sense to
use a common directory branch. In contrast, I never managed to get
METAFONT processing a property list, nor does a Property List reader
(pltotf) produce anything usefull from a METAFONT source.
Therefore, my perfered suggestion is:
The branch `source' (whose name is too "generic", anyway) should be
splitted into `mf' and `pl'.
There are a lot of other examples in the TDS where the file extension
string is (re)used as a directory name (.tex, .pk, .gf, ...).
Best regards,
Christian Spieler
================================================================================
Archive-Date: Wed, 05 Jul 1995 18:51:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 5 Jul 1995 19:50:14 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507052350.AA24282@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Subject: Re: Names of the <type> level in fonts dir tree
The branch `source' (whose name is too "generic", anyway) should be
splitted into `mf' and `pl'.
I don't have any big objection to this. Christian is certainly correct
that MF can't process PL files :-).
As I recall, the original reason for `source' was so things like awk
programs, fontinst inputs, etc., would legitimately go with the Metafont
sources where they belong. If we switch to `mf' and `pl', we should say
the directory name isn't necessary a 100% perfect reflection of the
files therein.
Pierre?
================================================================================
Archive-Date: Thu, 06 Jul 1995 10:32:08 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Thu, 6 Jul 1995 08:31:32 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507061531.IAA24105@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Names of the <type> level in fonts dir tree
CC: mackay@cs.washington.edu
For METAFONTS, "source" is clearly *.mf files, almost exclusively,
but I think that is missing the point. I use "source" for uncompiled
"source" of whatever sort, together with program text (also source, in a
sense) for shell scripts, awk and sed. Reviewing the BaskervilleMT
and AGaramond "source" directories I have been working in, I find
that I have some face specific scripts that I haven't had time
to generalize, lots of vpls, which I use all the time, fully
disassembled font files with the ps suffix (this means fully
human-readable files derived from pfa files) and even mf files
made with ps2mf. If I had PL files they would be there too.
This collection seems to me entirely consistent, and it down not
(that's does not) overfill the directory. Every one of these
categories in human-readable, even the ps files derived from the
pfa files. I can see no purpose in breaking this directory down
into even smaller units. None of its content can be used directly for
output. It all has to be processed first.
So I am going to vote very strongly for keeping "source" and
defining it as something like "human readable program text sources
for compilation into fonts or metric files, together with any
related program text specific to that task."
At the very least, this means PL, VPL, MF, and disassembled font PS
files.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
Archive-Date: Thu, 06 Jul 1995 10:52:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 6 Jul 95 16:51:24 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507061551.AA12775@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Names of the <type> level in fonts dir tree
I would generally favour splitting pl and mf. Looking at Pierre's
comments
... Reviewing the BaskervilleMT and AGaramond "source" directories
I have been working in, I find that I have some face specific
scripts that I haven't had time to generalize, lots of vpls, which
I use all the time, fully disassembled font files with the ps
suffix (this means fully human-readable files derived from pfa
files) and even mf files....
This seems to go back (Oh no!) to the whole discussion about the
organisation of the font tree.
I would say that someone `working' on a particular font should have
that font in some working directory and in that directory is quite
likly to keep all related scripts and files.
However it seems to me that the TDS tree is essentially a repository
for `fixed' installed files, and in that case it makes sense to split
the tree based on `search paths'.
David
================================================================================
Archive-Date: Thu, 06 Jul 1995 12:19:13 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Thu, 6 Jul 1995 10:18:32 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507061718.KAA05210@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Names of the <type> level in fonts dir tree
CC: mackay@cs.washington.edu
I admit that I wasn't thinking about the proliferation
of ./font/<types> that is now official, but the argument
four "human-readable source" still stands, even if
"source" is right down (my trees are rooted where roots normally
grow) in the ./fonts/ directory. Are we going to have
./fonts/vpl/...
./fonts/pl/...
./fonts/mf/..
./fonts/ps-from-pfa/...
and so on ad infinitum? Under ordinary circumstances, how often
do PL files get used anyway. Probably less often than vpl files.
I am increasingly unclear about what "search paths" means, but
it seems that we are getting to the point of saying that every
official suffix has a search patth?
In that case, we need $TEXMF/ltx/... $TEXMF/cls/... $TEXMF/sty/...
$TEXMF/dtx/... etc.
The argument is essentially the same, except that it requires
splitting up the LaTeX2e input files in ways that the LaTeX
consortium disapproves of.
Either we have some minimally intelligent path searching or
we don't. "source" is not a very broad category---no broader
than "base" or "contrib" which are also not suffiz-related
directory names. If path searching can find appropriate files
with a variety of files under the broad range of ./tex/latex/...
why is the much smaller ./fonts/source/... impossible.
The bare list of directories for the UnixTeX distribution has gone
from 24 pages to 30 pages with the proliferation of directories
and it is only about a quarter TDS-conformant as is. A sheaf
of 29 pages of directory names is already so bewildering that
I beg of you not to make it thicker by this sort of (what else to cal it)
hair-splitting.
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
Archive-Date: Thu, 06 Jul 1995 12:44:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 6 Jul 95 18:44:06 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507061744.AA12967@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Names of the <type> level in fonts dir tree
> I am increasingly unclear about what "search paths" means, but
> it seems that we are getting to the point of saying that every
> official suffix has a search patth?
Not extensions on the files, which are largely irrelevant here, but
the program doing the searching. ie the things that are traditionally
assigned to variables like TEXINPUT MFINPUT etc. The reason for having
(say) tfm as a top level directory is so that you can specify a tfm
search path that only consists of tfm files. The argument for
splitting off mf is the same. Your LaTeX cls/sty example is spurious
as the TDS tree does already allow the specification of an input path
for LaTeX files.
A top level mf directory is certainly more consistent with the way the
rest of the tds has evolved, but I can not say I am that bothered
either way as in practice, for a distributed TDS, the <source> tree will
most likely only consist of mf files (I dont see that many pl files
on ctan) and so setting the mf input path to be that tree will not
do too much harm.
David
================================================================================
Archive-Date: Thu, 06 Jul 1995 13:17:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 6 Jul 1995 14:15:57 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507061815.AA02405@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Names of the <type> level in fonts dir tree
Not extensions on the files, which are largely irrelevant here, but
the program doing the searching. ie the things that are traditionally
There isn't anything that searches for PL files (that I know of), unless
some implementations have modified pltotf to do both
searching. (Something that would have little value, as far as I can see.)
I don't see anything wrong with keeping mf's and pl's and awk scripts
and whatever else in a directory called `source'. As David says, there
aren't enough pl's etc. to matter (in terms of speed), so why
overspecify and say `only mf files go there'?
================================================================================
Archive-Date: Thu, 06 Jul 1995 13:40:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 6 Jul 1995 14:39:56 -0400
From: jgealow@mtl.mit.edu (Jeffrey C. Gealow)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507061839.AA23304@mtl.mit.edu>
To: twg-tds@shsu.edu
Subject: commments on TDS
I have a few comments on the TDS version 0.98. I administer UNIX
workstations. We use several different platforms.
Given the constraints presented in Section 2.2, I think the
organization detailed in the TDS is very good.
Having all files under a single hierarchy (often /usr/local/texmf) is
very convenient. I prefer this approach to the use of both
/usr/local/bin and /usr/local/lib/texmf directories. The hierarchical
structure makes it easy to maintain copies of our installations using
rdist.
For Solaris 2.x systems, the natural location for the texmf directory
is /opt, not /usr/local. Perhaps this difference should be noted
in the TDS.
I'm glad texmf/fonts/type was chosen over texmf/fonts/supplier. Given
appropriate Makefiles or installation scripts, I don't think the
fonts/supplier organization would be any easier to administer than the
proposed fonts/type organization. I think it important to have a
standard that can be adopted quickly, with a minimum amount of
trouble. The primary authors of important packages like dvips and
xdvi don't seem to adopting sophisticated font-searching facilities.
Thank you for your efforts.
Jeff
================================================================================
Archive-Date: Fri, 07 Jul 1995 03:00:52 CDT
Sender: owner-twg-tds@SHSU.edu
From: Bernard GAULLE <gaulle@idris.fr>
Reply-To: TWG-TDS@SHSU.edu
Date: Fri, 7 Jul 1995 09:59:50 +0200
Message-ID: <199507070759.JAA06572@murnau.idris.fr>
To: twg-tds@shsu.edu
CC: PICHERAL@univ-rennes1.FR
Subject: Where are the format files?
Hello dear "TSD workers",
As far as i can read, few changes have been made in the final TDS
description document.
In past drafts, specially in one of November, there was an "ini"
directory in which formats files could be placed. Some components
like "hyphen" are now elsewhere, no pb for that. But...
In the current document i don't see where i can put the format
files. May be, i'm blind?
--bg
PS: By the way what are the "mft" files?
================================================================================
Archive-Date: Fri, 07 Jul 1995 04:42:00 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0sU9tt-0001iIC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 7 Jul 95 10:40 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Names of the <type> level in fonts dir tree
>There isn't anything that searches for PL files
fontinst does. When running fontinst, you need to munge your
TEXINPUTS path to include the AFM and PL directories. Of course,
fontinst is so slow that searching all the mf files probably isn't
going to make that much difference to performance...
Alan.
================================================================================
Archive-Date: Fri, 07 Jul 1995 09:09:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 7 Jul 1995 10:09:19 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507071409.AA20324@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Names of the <type> level in fonts dir tree
fontinst does. When running fontinst, you need to munge your
TEXINPUTS path to include the AFM and PL directories. Of course,
fontinst is so slow that searching all the mf files probably isn't
going to make that much difference to performance...
Indeed.
If anything separating mf/pl will make performance worse, because there
will be still more directories.
I still think combining the metrics, bitmaps, etc. would be a plausible
change (even though that isn't what Christian was suggesting). That
would cut down on the number of directories, and the directories
still won't get very large. In practice, all it means is combining afm+tfm,
I think.
================================================================================
Archive-Date: Fri, 07 Jul 1995 09:12:26 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 7 Jul 1995 10:05:32 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507071405.AA20313@ra.cs.umb.edu>
To: gaulle@idris.fr
CC: twg-tds@shsu.edu
Subject: Re: Where are the format files?
In the current document i don't see where i can put the format
files. May be, i'm blind?
There's still an ini/ directory (or is initex/ now), I thought.
It's just one more directory down.
PS: By the way what are the "mft" files?
Used by Knuth's mft program. (Prettyprints Metafont sources.)
It'll probably be moved to the top level in the next version.
================================================================================
Archive-Date: Fri, 07 Jul 1995 09:49:58 CDT
Sender: owner-twg-tds@SHSU.edu
From: Bernard GAULLE <gaulle@idris.fr>
Reply-To: TWG-TDS@SHSU.edu
Date: Fri, 7 Jul 1995 16:48:25 +0200
Message-ID: <199507071448.QAA07961@murnau.idris.fr>
To: "K. Berry" <kb@cs.umb.edu>
CC: twg-tds@shsu.edu, PICHERAL@univ-rennes1.FR
Subject: Re: Where are the format files?
>>>>> On Fri, 7 Jul 1995 10:05:32 -0400,
>>>>> "K. Berry" <kb@cs.umb.edu> write about "Re: Where are the format files?":
KB> In the current document i don't see where i can put the format
KB> files. May be, i'm blind?
KB> There's still an ini/ directory (or is initex/ now), I thought.
Unfortunately NO! in the current draft-standard V 0.98 of June,14.
--bg
================================================================================
Archive-Date: Fri, 07 Jul 1995 10:22:03 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507071517.RAA23587@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Where are the format files?
To: TWG-TDS@SHSU.edu
Date: Fri, 7 Jul 1995 17:17:13 +0200 (MESZ)
CC: kb@cs.umb.edu, PICHERAL@univ-rennes1.fr, gaulle@idris.fr
Content-Type: text
You wrote:
>
> >>>>> On Fri, 7 Jul 1995 10:05:32 -0400,
> >>>>> "K. Berry" <kb@cs.umb.edu> write about "Re: Where are the format files?":
> KB> In the current document i don't see where i can put the format
> KB> files. May be, i'm blind?
>
> KB> There's still an ini/ directory (or is initex/ now), I thought.
>
> Unfortunately NO! in the current draft-standard V 0.98 of June,14.
page 6, last item, bottom of page.
For each TeX port one directory is allocated. The sub-structure of
this directory is up to the author(s) of the respective port. I.e.,
it's the choice of Karl to name the directory web2c/ini/ or
web2c/initex/ or whatever [but see below].
As for the rational: The TDS fixes only the names of directories for
implementation-independent files. Nevertheless it recommends the
usage of a TeX port directory, as many people want to mount the same
TeX tree on different platforms, e.g., wants to use the same texmf
tree for both Unix & DOS systems. To have one ini/ top-level
directory would counterfeit that aim.
Concerning the naming of the web2c FMT subdir:
Karl -- if you take wishes: Please add a version number there as
well; e.g., web2c/ini/v7.0/. Or simply web2c/v7.0/. It's often not
possible to update the TeX port on every platform that's served by a
texmf file system in one rush. And if the FMT format changes one gets
an unusable installation. Placing texmf.cnf & the FMT files in a
version-specific subdirectory enables the smooth migration to a next
version of TeX.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 07 Jul 1995 13:32:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 7 Jul 1995 13:32:35 -0400
From: jgealow@mtl.mit.edu (Jeffrey C. Gealow)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507071732.AA00590@mtl.mit.edu>
To: mackay@cs.washington.edu
Subject: Re: commments on TDS
CC: twg-tds@shsu.edu
Pierre MacKay:
As you suspect, I have not had much interest in using different fonts.
Nor has anyone else at my research lab. We use cm fonts and LaTeX
fonts and might investigate use of PostScript fonts.
While I may not know what font organization works best for users
interested in fonts, I think I have a pretty good understanding of of
the issues as they relate to my site.
You said that /fonts/type/mode/supplier/typeface/dvi creates a
proliferation of subdirectories. Yet
/fonts/supplier/typeface/type/mode/dvi requires the same number of
subdirectories.
The primary authors of xdvi and dvips have not incorporated kpathsea
into their distributions. For each new xdvi or dvips release, someone
must re-incorporate kpathsea to create xdvik or dvipsk. There have
been no new releases of dvips for many months, so dvips and dvipsk
are in sync. But xdvi is at Patchlevel 20 while xdvik remains
at Patchlevel 18. So if we had a /fonts/supplier organization,
we would currently not be able to enjoy the support for PostScript
specials recently added to xdvi.
(Do you know why Rokicki and Vojta have not make kpathsea an integral
part of their packages?)
It appears that the complexity of kpathsea and the /fonts/supplier
organization may have made it much more difficult to maintain a
coherent UNIX TeX et al. distribution. The web2c archive is currently
very messy. The primary distribution is divided among several tar
files, some to be extracted into the target directory, some to be
extracted into the source directory. Then there is a newer "source"
distribution. And documentation divided among unixtex.ftp, a dozen
*.help files, and README files included in the tar files. Compare the
the difficulty of installing gcc or emacs-19 or the difficulty of
installing old University of Washington UnixTeX distributions to the
difficulty of installing the TeX et al. using the current web2c
archive.
You wrote, "I genuinely dislike ./fonts/<type> because it is enforced
in an attempt to make it easy for the machine and the hell with the
human user, which strikes me as the wrong way round for software."
But /fonts/supplier is not better for the user if it hinders software
development.
I recognize that Karl Berry has done a tremendous amount of work for
the good of the TeX community. I am very grateful to him, you, and
all the others who have worked on TeX. I intend my comments to be
constructive. If they are not, I apologize for my criticisms.
Jeff
================================================================================
Archive-Date: Fri, 07 Jul 1995 14:22:34 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Fri, 7 Jul 1995 12:21:14 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507071921.MAA17811@june.cs.washington.edu>
To: jgealow@mtl.mit.edu
CC: twg-tds@shsu.edu
Subject: Re: commments on TDS
As you suspect, I have not had much interest in using different fonts.
Nor has anyone else at my research lab. We use cm fonts and LaTeX
fonts and might investigate use of PostScript fonts.
The availability of PostScript fonts is to a great extent the thing
that really drove the development of path-searching and hence
(ultimately) the TDS. Without them, a few flat directories are
adequate. I used to link all files of a specific category into
link-farms until path searching got as good as it is now. That
allowed me to continue using environment variables. In a purely CM
environment, the TEXPKS environment or something like is probably all
that is needed. Once a taste for fonts enters in, however, the
environment paths get too long very fast, and either the link-farm or
intelligent path-searching is needed. (Or, of course, a single
mile-wide directory of regular files.)
While I may not know what font organization works best for users
interested in fonts, I think I have a pretty good understanding of of
the issues as they relate to my site.
I suspect that your present organization is tuned very well to your
present needs. It probably doesn't need path-searching very much
at all. But if you branch out into things like fonts, you are almost
certain to find that, in the absence of path-searching, it becomes
a horrendous task to figure out what is filed where.
You said that /fonts/type/mode/supplier/typeface/dvi creates a
proliferation of subdirectories. Yet
/fonts/supplier/typeface/type/mode/dvi requires the same number of
subdirectories.
That's right, *once the path has been established*. But I was counting
the number of distinct inodes needed to accommodate a given font-rich
environment in either arrangement. I haven't had time to figure out just
why, but i actually tried both, and came up with almost a third more inodes
in the <type> first arrangement. The horror of dpiNNN proliferation
is another matter entirely, and I can only hope that the need for it will
ultimately wane. The directory list that I make up for UnixTeX increased
from 20 pages (I had thought the old listing was 24, but it was actually
20) to 30. Most of the extra pages are filled with dpiNNN directories.
The primary authors of xdvi and dvips have not incorporated kpathsea
into their distributions. For each new xdvi or dvips release, someone
must re-incorporate kpathsea to create xdvik or dvipsk. There have
been no new releases of dvips for many months, so dvips and dvipsk
are in sync. But xdvi is at Patchlevel 20 while xdvik remains
at Patchlevel 18. So if we had a /fonts/supplier organization,
we would currently not be able to enjoy the support for PostScript
specials recently added to xdvi.
(Do you know why Rokicki and Vojta have not make kpathsea an integral
part of their packages?)
In one case, because it comes under GNU licensing, though perhaps
the GNU library license might get around that. I am not sure in the
other.
It appears that the complexity of kpathsea and the /fonts/supplier
organization may have made it much more difficult to maintain a
coherent UNIX TeX et al. distribution.
the /fonts/supplier organization is no more complex than the /fonts/type
organization. Both are going to require intelligent path searching
if there are more branches on the tree than can be fit into an
environment path variable. This fact continues to be misunderstood.
If you are looking for Adobe Garamond in a tree which includes a
dozen or so faces each from a dozen or so suppliers there will be
approximately 144 final goal directories containing tfms. The difference is
simply in what the name of those final goal directories is. In
/fonts/supplier organization, they will all be named "tfm", while in
a /fonts/tfm organization they will presumably be named for the typeface.
There will still be 144 of them, and I doubt that any current operating
system will support an environment variable long enough to hold 144
paths strung end to end. At a certain point, intelligent path-searching
is an unavoidable necessity. Karl has pointed this out again and again,
It isn't a matter of whether it is done in kpathsea, it is a matter of
whether it is done at all.
The web2c archive is currently
very messy. The primary distribution is divided among several tar
files, some to be extracted into the target directory, some to be
extracted into the source directory. Then there is a newer "source"
distribution. And documentation divided among unixtex.ftp, a dozen
*.help files, and README files included in the tar files. Compare the
the difficulty of installing gcc or emacs-19 or the difficulty of
installing old University of Washington UnixTeX distributions to the
difficulty of installing the TeX et al. using the current web2c
archive.
I blush, and recall how wonderful it was to have Elizabeth keeping things
going. I still work on it, however, and have just made up a 3.14159
UnixTeX, with texmf runtime support that is about 1/4 TDS-conformant.
(Yes, the xdvi is a couple of revisions back of the leading edge, but
kpathsea-2.6 is incorporated into everything, and xdvi makes up bitmaps
from any PostScript font it can find.) I even did the cm files into
the DOS-compatible tree, but I am not sure I can face going on with that.
For one thing, once bitmaps are made up, it is a fairly complex business
arranging them into dpiNNN directories. Metafont still uses NNNgf as
its output suffix, and no one, I hope, is seriously considering changing
that. (Think of how it could cripple the running of a Metafont script
if every magstep came out as cmr10.pk.)
You wrote, "I genuinely dislike ./fonts/<type> because it is enforced
in an attempt to make it easy for the machine and the hell with the
human user, which strikes me as the wrong way round for software."
But /fonts/supplier is not better for the user if it hinders software
development.
I'm not sure it does. The problem seems to be one of making up the
specifications so that they express the real needs of users, future
as well as present. I sometimes think that on this subject only Karl (with
myself as an enthusiastic disciple) has an eye on the needs of the
future.
I recognize that Karl Berry has done a tremendous amount of work for
the good of the TeX community. I am very grateful to him, you, and
all the others who have worked on TeX. I intend my comments to be
constructive. If they are not, I apologize for my criticisms.
Pierre
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
Archive-Date: Fri, 07 Jul 1995 14:30:38 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 7 Jul 1995 13:32:35 -0400
From: jgealow@mtl.mit.edu (Jeffrey C. Gealow)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507071732.AA00590@mtl.mit.edu>
To: mackay@cs.washington.edu
Subject: Re: commments on TDS
CC: twg-tds@shsu.edu
Pierre MacKay:
As you suspect, I have not had much interest in using different fonts.
Nor has anyone else at my research lab. We use cm fonts and LaTeX
fonts and might investigate use of PostScript fonts.
While I may not know what font organization works best for users
interested in fonts, I think I have a pretty good understanding of of
the issues as they relate to my site.
You said that /fonts/type/mode/supplier/typeface/dvi creates a
proliferation of subdirectories. Yet
/fonts/supplier/typeface/type/mode/dvi requires the same number of
subdirectories.
The primary authors of xdvi and dvips have not incorporated kpathsea
into their distributions. For each new xdvi or dvips release, someone
must re-incorporate kpathsea to create xdvik or dvipsk. There have
been no new releases of dvips for many months, so dvips and dvipsk
are in sync. But xdvi is at Patchlevel 20 while xdvik remains
at Patchlevel 18. So if we had a /fonts/supplier organization,
we would currently not be able to enjoy the support for PostScript
specials recently added to xdvi.
(Do you know why Rokicki and Vojta have not make kpathsea an integral
part of their packages?)
It appears that the complexity of kpathsea and the /fonts/supplier
organization may have made it much more difficult to maintain a
coherent UNIX TeX et al. distribution. The web2c archive is currently
very messy. The primary distribution is divided among several tar
files, some to be extracted into the target directory, some to be
extracted into the source directory. Then there is a newer "source"
distribution. And documentation divided among unixtex.ftp, a dozen
*.help files, and README files included in the tar files. Compare the
the difficulty of installing gcc or emacs-19 or the difficulty of
installing old University of Washington UnixTeX distributions to the
difficulty of installing the TeX et al. using the current web2c
archive.
You wrote, "I genuinely dislike ./fonts/<type> because it is enforced
in an attempt to make it easy for the machine and the hell with the
human user, which strikes me as the wrong way round for software."
But /fonts/supplier is not better for the user if it hinders software
development.
I recognize that Karl Berry has done a tremendous amount of work for
the good of the TeX community. I am very grateful to him, you, and
all the others who have worked on TeX. I intend my comments to be
constructive. If they are not, I apologize for my criticisms.
Jeff
================================================================================
Archive-Date: Mon, 10 Jul 1995 10:17:59 CDT
Sender: owner-twg-tds@SHSU.edu
From: Bart Childs <bart@cs.tamu.edu>
Reply-To: TWG-TDS@SHSU.edu
Date: Mon, 10 Jul 1995 10:17:15 -0500
Message-ID: <199507101517.KAA19738@lanczos>
To: twg-tds@shsu.edu
Subject: logo font
While reviewing the TDS document, I notice METAPOST presented in a font
that appears to be an entension of the logo10 font, the characters
P and S are new. Is this a new ``standard'' version of this font?
Good work! Bart Childs
================================================================================
Archive-Date: Mon, 10 Jul 1995 10:46:09 CDT
Sender: owner-twg-tds@SHSU.edu
From: Bart Childs <bart@cs.tamu.edu>
Reply-To: TWG-TDS@SHSU.edu
Date: Mon, 10 Jul 1995 10:45:52 -0500
Message-ID: <199507101545.KAA18279@solar.cs.tamu.edu>
To: twg-tds@shsu.edu
Subject: TDS
On pages 9 and 10 the directory names
.../typeface/dpi/ are referenced. Something like
.../typeface/dpi#/ gives a stronger hint that resolution comes
in to affect it. The gentle use of sltt helps... You are precise in
calling such problems ``vexing'', but that is an understatement.
On page 11 in section 6, first paragraph.
..., except that it outputs PostScript; instead of bitmaps.
John Hobby wrote me that all of MetaFont is there in MetaPost and
that it indeed can output tfm files ...
I suggest a writing like:
..., except that its primary purpose is the output of an encapsulated
PostScript file for each figure.
Either I am confused or there is a discrepancy between pages
12 and 13 of draft TDS version 0.98.
On page 12 under `general' two examples are given by Schrod and Doob.
On page 13, these appear in general/texcomp and tex/, respectively.
I commend the committee on doing a great job on a much needed
project. You have had to make many compromises, but that is
necessary.
Regards, Bart Childs
================================================================================
Archive-Date: Mon, 10 Jul 1995 10:47:36 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 10 Jul 95 17:49:49 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507101549.AA21023@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: Bart Childs <bart@cs.tamu.edu>
Subject: Re: logo font
> While reviewing the TDS document, I notice METAPOST presented in a font
> that appears to be an entension of the logo10 font, the characters
> P and S are new. Is this a new ``standard'' version of this font?
Well, this depends on what you call new. As far as I know, the letters
`P' and `S' were already included in the 1993 revison of Knuth's files
(see CTAN:systems/knuth/lib and CTAN:systems/knuth/local/lib).
Only the file logo.mf actually changed, all the other logoxx.mf files
remain unchanged and just need to be regenerated. For LaTeX2e, check
out the mflogo package in CTAN:macros/latex/contrib/supported/mflogo.
If I ever find time to update that package, I might consider providing
an archive files containing all the necessary logoxx.{mf,tfm} files
which are currently scattered around on CTAN in serveral places.
Cheers,
Ulrik Vieth. (the one who brough METAPOST into the TDS document)
================================================================================
Archive-Date: Mon, 10 Jul 1995 10:52:50 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199507101530.RAA22814@spice.iti.informatik.th-darmstadt.de>
Subject: Re: logo font
To: TWG-TDS@SHSU.edu
Date: Mon, 10 Jul 1995 17:30:30 +0200 (MESZ)
CC: bart@cs.tamu.edu
Content-Type: text
You wrote:
>
> While reviewing the TDS document, I notice METAPOST presented in a font
> that appears to be an entension of the logo10 font, the characters
> P and S are new. Is this a new ``standard'' version of this font?
(a) yes. From DEK's current distribution.
(b) It's an oversight that the logo font is used. (Obviously my
explanations weren't good enough. ;-) Norm literally took the macro
distribution which has a configuration file (tdsguide.cfg) with code
to switch on the usage of logo fonts. The original intention was that
the distributed DVI file is TeXed without that configuration file so
that installations with old logo fonts won't have any problems with it.
Sigh. One should not implement too many fine-grained features.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 10 Jul 1995 15:39:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 10 Jul 95 17:49:49 +0200
From: vieth@xerxes.thphy.uni-duesseldorf.de
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9507101549.AA21023@thphy.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: Bart Childs <bart@cs.tamu.edu>
Subject: Re: logo font
> While reviewing the TDS document, I notice METAPOST presented in a font
> that appears to be an entension of the logo10 font, the characters
> P and S are new. Is this a new ``standard'' version of this font?
Well, this depends on what you call new. As far as I know, the letters
`P' and `S' were already included in the 1993 revison of Knuth's files
(see CTAN:systems/knuth/lib and CTAN:systems/knuth/local/lib).
Only the file logo.mf actually changed, all the other logoxx.mf files
remain unchanged and just need to be regenerated. For LaTeX2e, check
out the mflogo package in CTAN:macros/latex/contrib/supported/mflogo.
If I ever find time to update that package, I might consider providing
an archive files containing all the necessary logoxx.{mf,tfm} files
which are currently scattered around on CTAN in serveral places.
Cheers,
Ulrik Vieth. (the one who brough METAPOST into the TDS document)
================================================================================
Archive-Date: Tue, 11 Jul 1995 15:23:50 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Tue, 11 Jul 1995 13:23:43 -0700
Message-ID: <199507112023.NAA16202@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: commments on TDS
On Fri Jul 7 11:50:14 1995, jgealow@mtl.mit.edu (Jeffrey C. Gealow) wrote:
> (Do you know why Rokicki and Vojta have not make kpathsea an integral
> part of their packages?)
The reasons I have not made kpathsea an integral part of xdvi are (1) it comes
with the GPL, which conflicts with my practice of putting xdvi on the X11R*
contrib tape, and (2) it's quite a bit larger than I'd like: 8000+ lines
vs. 800+ for font_open.c.
--Paul Vojta, vojta@math.berkeley.edu
Archive-Date: Mon, 07 Aug 1995 08:55:38 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508071354.PAA13483@spice.iti.informatik.th-darmstadt.de>
Subject: Re: EuroTeX proceedings (fwd)
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Mon, 7 Aug 1995 15:54:53 +0200 (MESZ)
Content-Type: text
Hi, as you might remember, I didn't say `no' when Michel asked me to
present the TDS draft at EuroTeX in Arnheim. Now I had to prepare a
memo to appear in the proceedings. Below is it, FYI. I hope I haven't
misrepresented the group's position.
May anybody who was at TUG '95 please summarize the TDS panel/BOF
there?
Cheers,
Joachim
---------------- snip snap ----------------------------------------
% tds/eurotex95/memo.tex 06 Aug 95
%------------------------------------------------------------
%
% Memo on the TDS presentation at EuroTeX '95
%
% [LaTeX]
\documentclass{article}
\usepackage{path}
\begin{document}
\title{The Proposed \TeX{} Directory Structure}
\author{Joachim Schrod}
\maketitle
The past has seen many discussions why \TeX{} is conceived to be so
difficult. Four years ago, at Euro\TeX{}~'91 in Paris, we even had a
panel on ``Why is \TeX{} unusable?'' A basic critic that came up in
almost all these discussions was (a)~the difficulty to install \TeX{}
and maintain the installed system afterwards, (b)~that there is no
agreement what components belong to an installed \TeX{} system, and
(c)~that the structure of \TeX{} installations is too different from
site to site, thereby making it difficult to maintain a \TeX{}
installation.
Over the last 15~months, a TUG working group was busy to prepare a
draft for a standard \TeX{} Directory Structure (TDS). We hope to
serve the \TeX{} community by attacking item~(c) mentioned above. In
fact, when the draft will be accepted, we hope that item~(a), the
difficulty to install and maintain \TeX{} systems, will be reduced as
well.
The TDS draft addresses primarily the \TeX{} system administrator at a
site and people preparing \TeX{} distributions. It explicates where
files of a package will reside in a final installation, thus making it
easier for the administrator to find his or her way around. If someone
is responsible for \TeX{} installations on more than one platform, it
will also reduce the needed time to find files as the structures will
all be the same.
One \TeX{} system can be used (e.g., via NFS mount or mounted from a
CD-ROM) for both Unix-based workstations and DOS-based PCs, thereby
reducing the maintenance time again. To support that aim, only the
location of implementation-independent files are fixed, locations for
implementation- and platform-dependent files are only recommended.
If developers of a package can assume a common directory structure,
the package's installation can be automated, or at least the
instructions can be made very specific. Last, but not least, many
users will be interested in a defined installation structure, as they
want to have a look at the system they are using.
The basic idea behind the TDS is that the files from a distributed
package may fall in different categories: macro files for one (or even
more) \TeX{} formats, fonts and font metrics, auxiliary files for
utility programs, etc. For each category, a package gets assigned a
set of directories where its files are placed. If more than one file
exists for a category, a whole (exclusive) directory is allocated
for that package. Otherwise this file is placed in a directory named
\texttt{misc}.
When an update for such a package arrives, the current files in the
assigned directories (or the one file in \texttt{misc}) may be thrown
away and the new ones may be installed. (It's as -- or even more --
important to know which files to remove on update, as to know which
files to install. Everybody, who has maintained any system for some
time, has stumbled over that problem.)
This distribution of files over a directory tree implies that both
\TeX{} ports and utility programs (like \texttt{DVI} drivers) must be
able to search a file recursively in a directory tree. A survey among
developers showed that most widely used \TeX{} software supports
subdirectory searching already, other implementations will get it
soon. Actually, the majority of developers were not willing to spend
much work in sophisticated cache and search strategies, so the
proposed layout pays attention to that restriction. As always, one had
to make compromises.
Members of the working group are Barbara Beeton, Karl Berry, Vicki
Brown, David Carlisle, Alan Jeffrey, Pierre MacKay, Rich Morin,
Sebastian Rahtz, Joachim Schrod, Elizabeth Tachikawa, Ulrik Vieth, and
Norman Walsh (chair). These members have either years of experience in
maintaining \TeX{} systems or they are active in preparing
distributions for important \TeX{} packages or they are engaged in the
preparation of complete \TeX{} distributions (or all of these points).
So we are reasonably confident that our proposal is no hot air; it is
in use already and we hope that it will be utilized by all important
\TeX{} distributions in the future.
The current TDS draft is available on any CTAN host, in various
formats (\LaTeX{}, \texttt{DVI}, \textsc{PostScript}, etc.) It is
placed in subdirectories of \path|/tex-archive/tds/|. Any feedback to
that draft should be sent by email to \path|twg-tds@shsu.edu| or by
paper mail to the chair of the working group (Norman Walsh, O'Reilly
\& Associates, Inc., 90~Sherman Street, Cambridge, MA~02140, USA)\@.
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% LocalWords: Euro package's Vicki Carlisle MacKay Morin Tachikawa Ulrik
% LocalWords: Vieth tds twg shsu edu
---------------- snip snap ----------------------------------------
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 07 Aug 1995 15:38:30 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 07 Aug 1995 16:38:01 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: EuroTeX proceedings (fwd)
To: TWG-TDS@SHSU.edu
Message-ID: <807827881.679606.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
joachim,
a few editorial comments ...
panel on ``Why is \TeX{} unusable?'' A basic critic that came up in
^^^^^^ criticism
Over the last 15~months, a TUG working group was busy to prepare a
^^^^^^^^^^^^^^^^^^^
has been busy preparing
fact, when the draft will be accepted, we hope that item~(a), the
^^^^^^^ is
location of implementation-independent files are fixed, locations for
^ ;
files to install. Everybody, who has maintained any system for some
^ don't need comma
time, has stumbled over that problem.)
^ don't need this one either
subdirectory searching already, other implementations will get it
^ ;
So we are reasonably confident that our proposal is no hot air; it is
^^ not
looks good. i'll be there to hear you present it.
my notes are in really bad shape, so unless nobody else volunteers
to summarize the tug'95 panel, i'd rather not.
cheers. -- bb
================================================================================
Archive-Date: Tue, 08 Aug 1995 03:54:58 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 8 Aug 1995 09:52:14 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508080852.JAA05055@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: EuroTeX proceedings (fwd)
References: <199508071354.PAA13483@spice.iti.informatik.th-darmstadt.de>
Joachim Schrod writes:
> May anybody who was at TUG '95 please summarize the TDS panel/BOF
> there?
It was relatively quiet. Norm presented the TDS, which everybody had
been given copies of, and there was general happines at the concept, I
think. The most significant comment (to my mind) came from Peter
Breitenlohner, who questioned whether the search *was* in fact
genuinely recursive, or could be implemented in other ways. in
essence, the argument is that fancyheadings.sty will *always* be found
at
<root>/tex/latex/fancyheadings/fancyheadings.sty
(silly example, apply an 8+3 algorithm), and we dont permit it to be
in
<root>/tex/latex/fancyheadings/something/fancyheadings.sty
because of our ISO limits on depth. The question is, *do* we mean
this? or can people use subdirectories ad nauseam? I'd argue that
Peter is essentially right, that we dont want and dont permit a
genuinely endless recursive search, but that such a system will find
stuff correctly in our system
there was also discussion about local files, whether they go in the
main TDS tree or in a parallel sparse tree. i think it was agreed that
the latter is preferable.
Don Knuth asked everyone to please start all paths with (Unixified)
.:.. because it was so useful a concept. whether one agrees or not, i
dont think this is our job
Norm, does this correspond with your memories?
Joachim, i think your draft is fine.
my personal view of the situation is that the *principles* of the TDS
are widely accepted and approved, and will be seen widely in the next
year. during that year people will break it in various interesting
ways, and a revision will be needed after experience
the important thing now is that we make a few changes (a ruling on the
Breitenlohner question is needed), taking into account the last couple
of months remarks, and issue the damn thing as version 1.0 in the next
month, with a firm agreement that it will remain unchanged for 6 or 12
months. dont lets let the "draft" label hang on any longer than at all
necessary
sebastian
================================================================================
Archive-Date: Tue, 08 Aug 1995 08:06:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 8 Aug 1995 14:01:45 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508081301.OAA10249@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: EuroTeX proceedings (fwd)
References: <199508071354.PAA13483@spice.iti.informatik.th-darmstadt.de>
Joachim Schrod writes:
> May anybody who was at TUG '95 please summarize the TDS panel/BOF
> there?
I just found my notes, and i see that someone also asked that we
suggest a standard list of environment variable names for TeX-related
tools. I am inclined to agree that an appendix giving a comprehensive
list for people to follow would be no bad thing
sebastian
================================================================================
Archive-Date: Tue, 08 Aug 1995 09:32:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 8 Aug 1995 10:32:02 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508081432.AA05317@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: EuroTeX proceedings (fwd)
Peter is essentially right, that we dont want and dont permit a
genuinely endless recursive search, but that such a system will find
I would say the TDS does not ``require'' a genuinely recursively search,
not that it does not ``want'' or ``permit'' such.
I certainly don't think we should recommend a hack implementation that does
not do real recursion. Better to keep silent on the subject, as we are now.
Ruling? I don't quite understand. Yes, the TDS says the file is in
tex/latex/fancyheadings/fancyheadings.sty. No, we do not recommend
implementors take short cuts and ``know'' about the subdirectory
structure. How does that sound?
there was also discussion about local files, whether they go in the
main TDS tree or in a parallel sparse tree. i think it was agreed that
the latter is preferable.
It's a real pain, either way. In reality, I bet most smallish sites will
just put their files in the main tree. I know I will.
Don Knuth asked everyone to please start all paths with (Unixified)
.:.. because it was so useful a concept. whether one agrees or not, i
dont think this is our job
We can't require it, but this wouldn't be a bad thing to
recommend. (Perhaps in this new environment variable section :-)
issue the damn thing as version 1.0 in the next month,
Norm, have you been keeping a list of the outstanding things to be
resolved? Or do we go back through the mail archives? Will you have time
to start making updates soon?
================================================================================
Archive-Date: Tue, 08 Aug 1995 09:49:51 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 8 Aug 1995 15:46:38 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508081446.PAA10897@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: EuroTeX proceedings (fwd)
References: <199508081432.AA05317@ra.cs.umb.edu>
> Ruling? I don't quite understand. Yes, the TDS says the file is in
> tex/latex/fancyheadings/fancyheadings.sty. No, we do not recommend
> implementors take short cuts and ``know'' about the subdirectory
> structure. How does that sound?
but why not take a "shortcut", if our number of directory levels means
that the position of fancyheadings.sty *is* fixed? we *dont* need a
recursive search
> It's a real pain, either way. In reality, I bet most smallish sites will
> just put their files in the main tree. I know I will.
until you get your CD version...
sebastian
================================================================================
Archive-Date: Tue, 08 Aug 1995 11:36:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 8 Aug 1995 10:21:33 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508081421.AA05264@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: EuroTeX proceedings (fwd)
I am inclined to agree that an appendix giving a comprehensive
list for people to follow would be no bad thing
I agree. Here's my current list, as a start.
If the meaning of any isn't clear, let me know.
(If I was really motivated, I'd write a draft for the section, but ...)
In addition to these, all my programs use one more font variable, named
for the program: DVIPSFONTS, XDVIFONTS, DVILJFONTS. This overrides
everything else.
KPSE_GF_ENVS "GFFONTS", KPSE_GLYPH_ENVS
KPSE_PK_ENVS "PKFONTS", "TEXPKS", KPSE_GLYPH_ENVS
KPSE_GLYPH_ENVS "GLYPHFONTS", "TEXFONTS"
KPSE_BASE_ENVS "MFBASES", "TEXMFINI"
KPSE_BIB_ENVS "BIBINPUTS", "TEXBIB"
KPSE_BST_ENVS "BSTINPUTS"
KPSE_CNF_ENVS "TEXMFCNF"
KPSE_FMT_ENVS "TEXFORMATS", "TEXMFINI"
KPSE_MEM_ENVS "MPMEMS", "TEXMFINI"
KPSE_MF_ENVS "MFINPUTS"
KPSE_MFPOOL_ENVS "MFPOOL", "TEXMFINI"
KPSE_MP_ENVS "MPINPUTS"
KPSE_MPPOOL_ENVS "MPPOOL", "TEXMFINI"
KPSE_MPSUPPORT_ENVS "MPSUPPORT"
KPSE_PICT_ENVS "TEXPICTS", KPSE_TEX_ENVS
KPSE_TEX_ENVS "TEXINPUTS"
KPSE_TEXPOOL_ENVS "TEXPOOL", "TEXMFINI"
KPSE_TFM_ENVS "TFMFONTS", "TEXFONTS"
KPSE_TROFF_FONT_ENVS "TRFONTS"
KPSE_VF_ENVS "VFFONTS", "TEXFONTS"
KPSE_DVIPS_CONFIG_ENVS "TEXCONFIG"
KPSE_DVIPS_HEADER_ENVS "DVIPSHEADERS"
================================================================================
Archive-Date: Tue, 08 Aug 1995 15:24:50 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 8 Aug 1995 16:23:47 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508082023.AA07710@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: EuroTeX proceedings (fwd)
but why not take a "shortcut", if our number of directory levels means
that the position of fancyheadings.sty *is* fixed? we *dont* need a
recursive search
I'd put it differently: I'd say we don't *need* a recursive search.
It still seems like the best thing to implement to me. What will happen
when the CD-ROM standard changes and we don't have to live with these
stupid restrictions? Why shoot ourselves in the foot by recommending an
inferior implementation?
Anyway, what exactly is Breit. planning? He wants to write something
that will fail if fancyheadings.sty is not in the appointed place, but
in a subdirectory thereof? Why? What's the gain?
Note I'm not talking about *requiring* a completely recursive
search. Any algorithm that finds the files in the places we say is
acceptable within the TDS world, I suppose. It's just a question of
what we recommend. I suggest we either be silent on this issue or
recommend a true recursive search.
> It's a real pain, either way. In reality, I bet most smallish sites will
> just put their files in the main tree. I know I will.
until you get your CD version...
I'll make a link farm.
================================================================================
Archive-Date: Tue, 08 Aug 1995 15:31:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 8 Aug 1995 10:24:24 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508081424.AA05276@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: EuroTeX proceedings (fwd)
we suggest a standard list of environment variable names for TeX-related
Sorry, didn't see this before. As for what we should suggest, I wouldn't
``suggest'' the TEXPKS and TEXBIB envvars in the previous
list. I'd also love to replace TEXPOOL/MFPOOL/MPPOOL with a single
TEXMFPOOL, but I don't think that's feasible at this point.
================================================================================
Archive-Date: Wed, 09 Aug 1995 13:59:12 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508091858.UAA08090@spice.iti.informatik.th-darmstadt.de>
Subject: Re: EuroTeX proceedings (fwd)
To: TWG-TDS@SHSU.edu
Date: Wed, 9 Aug 1995 20:58:40 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> Anyway, what exactly is Breit. planning? He wants to write something
> that will fail if fancyheadings.sty is not in the appointed place, but
> in a subdirectory thereof? Why? What's the gain?
In my personal opinion, Peter plans nothing. The TeX port he maintains
does full recursive directory searching since years. Peter just loves
to argue, as everybody who has spent an evening with him knows. (That
can be fun, and that can be horrible if you want to flirt with the
woman besides you... :-)
I had discussions on this topic three times with him; every time I've
told him that the TDS draft specifies a directory structure and not
any algorithm to handle that. It is descriptive and not prescriptive.
(I hope I got these English words right. ;-)
As with every standard, it is reasonable practice to check if the
descriptive specs may be implemented effectively enough. That has been
done.
I don't have the TDS draft here, perhaps we should emphasize the
above point more strongly. I would vote against any recommendation
for any algorithm. (You remember my insistence on good algorithms? I
would demand to fix caching and search tree pruning in the standard.
And then the whole topic of font layout is on the table again. You
won't open that box, will you? :-)
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 09 Aug 1995 14:01:34 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508091901.VAA08101@spice.iti.informatik.th-darmstadt.de>
Subject: Re: EuroTeX proceedings (fwd)
To: TWG-TDS@SHSU.edu
Date: Wed, 9 Aug 1995 21:01:01 +0200 (MESZ)
Content-Type: text
sebastian wrote:
>
> the important thing now is that we make a few changes (a ruling on the
> Breitenlohner question is needed), taking into account the last couple
> of months remarks, and issue the damn thing as version 1.0 in the next
> month, with a firm agreement that it will remain unchanged for 6 or 12
> months. dont lets let the "draft" label hang on any longer than at all
> necessary
I would prefer to wait until Arnheim has passed. (Partly for
political reasons, there are Europeans who want to be asked. They
won't have special answers or demands, but they want to be asked...)
But we could start to incorporate the requested changes already, to
publish the fixed document soon after Arnheim.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 09 Aug 1995 23:32:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 9 Aug 1995 17:32:17 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508092132.AA19966@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: EuroTeX proceedings (fwd)
told him that the TDS draft specifies a directory structure and not
any algorithm to handle that. It is descriptive and not prescriptive.
(I hope I got these English words right. ;-)
You did. I think we all agree on this. If Peter or someone else would
like to recommend wording changes, fine. If not, I am not opposed to
letting the current draft stand (in this area).
================================================================================
Archive-Date: Thu, 10 Aug 1995 04:17:40 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 10 Aug 1995 09:02:02 +0100
Message-ID: <9508100802.AA13648@philips.nl>
From: c753330@nlzcl1.decnet.philips.nl (Alex Kok)
Reply-To: TWG-TDS@SHSU.edu
To: "twg-tds@shsu.edu"@NLZMS.decnet.philips.nl
CC: C753330@nlzcl1.decnet.philips.nl
Subject: Experience with TWG-TDS
Dear TWG-TDS people,
Having heard and read about TDS, I thought that the best way to comment on TDS
is to implement it and report the findings. I have done so. My configuration is
a MicroVAX II running OpenVMS V6.2, TeX, Version 3.1415 [PD VMS 3.6], LaTeX2e
<1994/12/01> patch level 3. Page numbers refer to the PostScript version of the
TDS document (v0.98) as available on CTAN.
Of course, I found some things that seemed unclear or inconsistent. I also have
suggestions for improvement of the document, and the occasional typo. Some of
the additions I suggest may not be appropriate for TDS itself, but please
consider adding them in an appendix or a separate "TDS user guide" for
non-TeXperts. After all, the TDS document states it "...will also help TeX
users..." (Introduction, last line). There are many persons who just want to
get LaTeX to work, without having to delve into the details of MF, fonts, font
files, etc. The current TDS document is not understandable to them (I know, I'm
one of them).
I have done this kind of thing before, and for some items, I fully expect
reactions like "Wow, this guy is negative.", "Hey, yes, but everybody knows
such-and-such!" and "Yeah, but this is about TDS and TDS has nothing to do, in
principle, with specific applications like LaTeX!". In this case, I urge you
consider my points to be real, as they are to me. Everybody does NOT know.
Quite a few people want just LaTeX, and consider the rest unavoidable hassle.
Regards, and keep up the good work!
Alex Kok (c753330@nlzcl1.decnet.philips.nl)
====
TDS is a major improvement over previous practice with files scattered all over
the place in an inconsistent manner. Some people seem to object to the way TDS
scatters files. I do not find the "TDS scattering" of files (e.g. of packages:
in the TeX subtree and the doc subtree; and of fonts: in the fonts/pk and
fonts/tfm subtrees) objectionable; I'd rather say it is unavoidable. I'm glad a
decision has been made!
Suggestion: Add a list of file types and where to put them according to TDS.
This list should include these file types at least: .afm .base .cfg .clo .cls
.dat .def .drv .dtx .el .err .exe .fd .fmt .ini .ins .ist .lis .ltx .map .mf
.pk .pool .ppl .pro .ps .sty .tex .tfm .vf. This is to clear things up for types
like me who are not TeXperts and have never used MetaFont, Web, Tangle, Weave
etc. and do not know what all these file types are for.
Suggestion: Add a list of "packages" (like psnfss, lw35nfss, babel, tools,
graphics) and where to put them. I for one cannot say if e.g. Babel should go
in tex/generic/babel or tex/latex/babel.
It is unclear to me what is to be considered source in the case of LaTeX. There
are .DTX and .LTX files. Both can be considered source code, and the .DTX files
are ALSO documentation, hence should go in the doc tree...? This specific
example needs clarification.
I suggest to NOT clutter up the texmf directory with dvi driver program
directories, but to add a layer e.g. texmf/dvidrivers. This would lead to e.g.
texmf/dvidrivers/dvips/ (well, "dvidrivers" is too long, obviously, so you can
see I use a VMS system).
Why is there no indication where the format files go (e.g. latex.fmt)?? TDS
seems to shrug it off somewhere saying it is something local. If TDS does not
specify it, TDS should say explicitly that it is up to the TeX administrator.
Page 3, last line reads: "command Commands are typeset in italics" but the word
"command" is NOT set in italics but in roman (typewriter font).
Page 3, section 1.2: "packages": it is most unfortunate that this term is
different from what people are used to. This is confusing! Certainly for "the
TeX user"! I find it astonishing that you *acknowledge* that it is confusing
instead of changing this. Just as bad as Unix documentation (well, almost :-).
And now the single most confusing paragraph of the whole document:
Page 6, 2nd/3rd line from bottom: "configuration files" and where to put them
is in conflict with page 15: "config/ configuration files for format..."
Page 6, last paragraph: the terms "directories" and "subdirectories" are used
for (if I understand correctly) the same thing: a subdirectory of /texmf/.
Confusing.
Page 6, last paragraph: "... implementations ... in their own directories.".
What is an implementation other than a set of programs including binaries?
Should they not go in /texmf/bin/ or outside the texmf tree as specified on
page 7?
Page 7: The bin directory description may lead to different interpretations. It
does not make entirely clear where the executables go, and this is worse if
applied to "scripts" (e.g. Unix shell scripts, VMS DCL programs, MSDOS .BAT
files) like maketexpk. It leads to this:
Digital Unix executables: bin/axp
OpenVMS/AXP executables: bin/axp (oh dear, this is the same directory!)
Windows/NT AXP executables: bin/axp (oh dear, this is the same directory!)
OpenVMS VAX executables: bin/vax
OpenVMS VAX scripts: bin/? (common to VAX and AXP; I use bin/vms)
Unix scripts: bin/unix ?
HPUX specific scripts: bin/hpux ?
HPUX executables: bin/hpux or bin/parisc ?
The TDS is as good as useless here. I suggest to make this bit more specific or
to leave it out (almost) entirely (e.g. "the bin subtree can be used for
binaries as the local TeX admin sees fit."). Add something for the scripts
(strictly speaking, they are not covered in TDS as it is now). Maketexpk is
indispensible! An possibility would be to use bin/os for operating system
specific things (e.g. bin/vms/, bin/unix/, bin/hpux/) with optional
subdirectory for hardware architecture (e.g. bin/vms/axp/, bin/vms/vax/).
Page 7: A "specification" like TDS should SPECIFY, not say things like
"administrators may wish..." as in section 2.4.
Page 7, section 3: refers to mft files. What on earth are they? Never heard of
them. I have checked several TeX installations but I could not find any *.mft
files (there are *.tfm and *.fmt files, of course).
Page 7, section 3, bottom paragraph: doesn't plain.tex belong in the source
tree? An explanation or change is in order here.
Page 8, section 4: "As with macros, fonts need ...". TDS is about FILES not
FONTS and a non-TeXpert needs to read "font files" here, or an explanation what
a "font" is in relation to TDS (during implementation I have been forced to
learn about .gf, .pk, .tfm, .vf ...).
Page 12: "man is reserved for manual pages (Unix-style documentation)." What is
so special about Unix that it gets mentioned specifically? TeX runs on more
platforms than Unix. Consider adding "vmshelp is reserved for VMS help
libraries" and similar for other OSs.
Page 15, section 10: "binaries, by system type" is called "optional". I think
that a number of other things are also optional, e.g. some sites do not need
Metafont (just use LaTeX, no math, PS fonts), others do not need LaTeX (use
Metafont and plain TeX). This calls for more consistency.
Page 15, Section 10: I do not think DVIPS is a TeX application. It is a DVI
driver. AMSTeX, SliTeX, and LaTeX are TeX applications. I suggest to change the
wording.
Page 19, 8th line from below: "availble" should read "available". Don't you
guys use a spelling checker :-?
Page 20: The Email address of Sebastian Rahtz is incorrect (as you know
probably better than me). I have: s.rahtz@elsevier.co.uk
That's all folks!
================================================================================
Archive-Date: Thu, 10 Aug 1995 05:53:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 10 Aug 1995 12:44:03 +0200
Message-ID: <9508101044.AA06365@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
Subject: Re: Experience with TWG-TDS
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
Akex Kok wrote:
> Dear TWG-TDS people,
> Of course, I found some things that seemed unclear or inconsistent. I also have
> suggestions for improvement of the document, and the occasional typo. Some of
> the additions I suggest may not be appropriate for TDS itself, but please
> consider adding them in an appendix or a separate "TDS user guide" for
> non-TeXperts. After all, the TDS document states it "...will also help TeX
> users..." (Introduction, last line). There are many persons who just want to
> get LaTeX to work, without having to delve into the details of MF, fonts, font
> files, etc. The current TDS document is not understandable to them (I know, I'm
> one of them).
Thanks for your useful comments and suggestions. Let me try to answer a few of them:
> Suggestion: Add a list of file types and where to put them according to TDS.
> This list should include these file types at least: .afm .base .cfg .clo .cls
> .dat .def .drv .dtx .el .err .exe .fd .fmt .ini .ins .ist .lis .ltx .map .mf
> .pk .pool .ppl .pro .ps .sty .tex .tfm .vf. This is to clear things up for types
> like me who are not TeXperts and have never used MetaFont, Web, Tangle, Weave
> etc. and do not know what all these file types are for.
I think this was discussed, but the plan to produce a file format appendix was
never put into practice for the present TDS draft. If I remember correctly,
Norm even obtained permission from his publisher to reproudce the relevant
appendix from ``Making TeX work'' in the TDS draft, but I'm afraid it doesn't
list *all* file extensions. (Besides your list above isn't complete either.)
Correlating the file format extensions with a hint where they should go seems
a very good idea to me.
> Suggestion: Add a list of "packages" (like psnfss, lw35nfss, babel, tools,
> graphics) and where to put them. I for one cannot say if e.g. Babel should go
> in tex/generic/babel or tex/latex/babel.
Good question. I have installed Babel in /tex/generic/babel, because it's supposed
to be generic, but I've put a symbolic link into tex/latex/babel, because it's
distributed on CTAN below macros/latex/packages/babel. (Of course, this assumes
that you have symbolic links. If not you'll have to decide either way.)
> It is unclear to me what is to be considered source in the case of LaTeX. There
> are .DTX and .LTX files. Both can be considered source code, and the .DTX files
> are ALSO documentation, hence should go in the doc tree...? This specific
> example needs clarification.
I think it was agreed that .DTX files are considered source files even thogh
they also contain documentation. .DVI or .PS files produced from .DTX files
for viewing or printing as online doucumentation should got in the doc tree.
The .LTX are produced by stripping the documentation from the .DTX files.
Since they are used to generate the LaTeX format the .LTX files belong into
the tex tree, i.e into tex/latex/base, where TeX searches for the files.
> I suggest to NOT clutter up the texmf directory with dvi driver program
> directories, but to add a layer e.g. texmf/dvidrivers. This would lead to e.g.
> texmf/dvidrivers/dvips/ (well, "dvidrivers" is too long, obviously, so you can
> see I use a VMS system).
I think this depends on how many DVI drivers use auxilliary files that need
to be stored somewhere in the texmf tree. dvips uses quite a number of
configuration files and encoding files whereas other drivers might not.
> Why is there no indication where the format files go (e.g. latex.fmt)?? TDS
> seems to shrug it off somewhere saying it is something local. If TDS does not
> specify it, TDS should say explicitly that it is up to the TeX administrator.
Hmm, I thought it was mentioned somewhere that this is implemntation-specific,
i.e. left to the implementor of the TeX distribution for specific platform.
> Page 6, last paragraph: "... implementations ... in their own directories.".
> What is an implementation other than a set of programs including binaries?
> Should they not go in /texmf/bin/ or outside the texmf tree as specified on
> page 7?
I think "implentation" includes binaries as well as batch files or shell scripts,
pool files, configuration files for path searching, and even format and base files
that are machine-architecture dependent.
> Page 7, section 3: refers to mft files. What on earth are they? Never heard of
> them. I have checked several TeX installations but I could not find any *.mft
> files (there are *.tfm and *.fmt files, of course).
MFT is a utility program for pretty-printing METAFONT source files. *.mft files
are files that control how certatin keywords are formatted. The Unix TeX
implementation searches for them in the tex subtree, but I think it was agreed
that it would be cleaner to introduce another top-level directory texmf/mft
for these files. For more than 99% of the average TeX users this will be
totally uninteresting and irrelevant, of course.
> Page 12: "man is reserved for manual pages (Unix-style documentation)." What is
> so special about Unix that it gets mentioned specifically? TeX runs on more
> platforms than Unix. Consider adding "vmshelp is reserved for VMS help
> libraries" and similar for other OSs.
I think it's simply that the Unix TeX implentation usually comes with man pages
that focus on the description of command line options, environment variables
and the location of some important files, whereas the status of system-specific
documentation of other TeX implementations isn't that clear. Are the VMS help
libraries part of the standard distribution or are they contributed documentation
from other sources?
> Page 15, section 10: "binaries, by system type" is called "optional". I think
> that a number of other things are also optional, e.g. some sites do not need
> Metafont (just use LaTeX, no math, PS fonts), others do not need LaTeX (use
> Metafont and plain TeX). This calls for more consistency.
I think the "optional" means that implementors are free to put binaries and
other implementation-specific stuff outside the texmf tree if they wish.
And by the way, if you want to run automatic font generation with MakeTeXPK,
METAFONT is definitely needed and no longer optional.
> That's all folks!
Thanks again for your comments. I think we definitely need such detailed
feedback as yours that points out the weak points, so that we can fix them.
Cheers,
Ulrik Vieth.
================================================================================
Archive-Date: Fri, 11 Aug 1995 05:08:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 11 Aug 1995 11:01:32 +0100
Message-ID: <9508111001.AA13626@philips.nl>
From: c753330@nlzcl1.decnet.philips.nl (Alex Kok)
Reply-To: TWG-TDS@SHSU.edu
To: "twg-tds@shsu.edu"@NLZMS.decnet.philips.nl
CC: C753330@nlzcl1.decnet.philips.nl
Subject: Re: Experience with TWG-TDS
Dear all,
(whoever you are -- I don't know who's on the mailing list) On request of Ulrik
Vieth I send my reply to his mail to the twg-tds mailing list. It is included
below. He already answered some of my questions.
Regards, Alex Kok (c753330@nlzcl1.decnet.philips.nl)
====
Dear Ulrik,
You wrote:
> Good question. I have installed Babel in /tex/generic/babel, because it's supposed
> to be generic, but I've put a symbolic link into tex/latex/babel, because it's
> distributed on CTAN below macros/latex/packages/babel. (Of course, this assumes
> that you have symbolic links. If not you'll have to decide either way.)
Links are not anything to use in a platform-independent standard like
TDS is supposed to be. Unix has it, VMS has something similar that the
supplier advises not to use (and most VMS people hardly know about). The
rest I don't know.
> I think it was agreed that .DTX files are considered source files even thogh
> they also contain documentation. .DVI or .PS files produced from .DTX files
> for viewing or printing as online doucumentation should got in the doc tree.
> The .LTX are produced by stripping the documentation from the .DTX files.
> Since they are used to generate the LaTeX format the .LTX files belong into
> the tex tree, i.e into tex/latex/base, where TeX searches for the files.
Interesting. I'll check if I did it right.
> Hmm, I thought it was mentioned somewhere that this is implemntation-specific,
> i.e. left to the implementor of the TeX distribution for specific platform.
That's right. But I disagree, I think they merit specific mention. After
all, no installation can do without them. Is there a specific reason NOT
to specify it, apart from its being generated locally? I have simply
used /texmf/tex/formats/ and I can't think what's wrong with that. Would
also ensure cross-platform consistency. In future it is well possible
that multiple platforms will use the same installation, so I think it
would be best to prepare for that.
> I think it's simply that the Unix TeX implentation usually comes with man pages
> that focus on the description of command line options, environment variables
> and the location of some important files, whereas the status of system-specific
> documentation of other TeX implementations isn't that clear. Are the VMS help
> libraries part of the standard distribution or are they contributed documentation
> from other sources?
The VMS TeX help library is part of the DECUS TeX distribution
(available from CTAN) and of much help (at least to me). This is the
"standard distribution" for VMS. It includes the description of command
line options, logical names (comparable to Unix environment variables)
(the location of important files is taken care of in the installation
procedure, this is automatic. Alas, NOT TDS-compliant :-( ).
Is there no member in TWG-TDS who knows about VMS??? The remark you made
about symbolic links also gave that impression. Do you need a
volunteer?
> Thanks again for your comments. I think we definitely need such detailed
> feedback as yours that points out the weak points, so that we can fix them.
I'm happy to contribute. I'm looking forward to the next version of TDS.
Any idea when it can be expected?
Regards, Alex Kok (c753330@nlzcl1.decnet.philips.nl)
================================================================================
Archive-Date: Fri, 11 Aug 1995 13:57:58 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508111855.UAA17297@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Experience with TWG-TDS
To: c753330@nlzcl1.decnet.philips.nl
Date: Fri, 11 Aug 1995 20:55:18 +0200 (MESZ)
CC: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Content-Type: text
[As Ulrik has reacted on a few points, I react to other ones here.]
Alex wrote:
>
> Suggestion: Add a list of "packages" (like psnfss, lw35nfss, babel, tools,
> graphics)
Please note your use of `package' here, I'll come back to that below.
> and where to put them. I for one cannot say if e.g. Babel should go
> in tex/generic/babel or tex/latex/babel.
That's a nice example -- it depends on the version.
3.4 goes in tex/generic/babel,
3.5 goes partly in tex/generic/babel, partly in tex/latex/babel.
That's because 3.4 could be used with plain TeX, whereas 3.5 is
LaTeX-specific. When 3.6 can be used with plain TeX again, it will be
moved back to tex/generic/babel. :-)
> I suggest to NOT clutter up the texmf directory with dvi driver program
> directories, but to add a layer e.g. texmf/dvidrivers.
Why? What's so special about dvi drivers that doesn't hold for
MakeIndex or BibTeX? I think the general rule ``each application gets
its directory'' a very good one.
> Page 3, section 1.2: "packages": it is most unfortunate that this term is
> different from what people are used to. This is confusing! Certainly for "the
> TeX user"!
*No*. _This_ usage is the one that people are used to, as a term to
denote a couple of files that do something. A unit of distribution,
most often. That LaTeX 2e used that term for something completely
different (for a module), is something one should make them pay a
bottle of wine for each TeX user. The selection of this term caused
more confusion than any other change introduced by LaTeX.
(You pushed a button, in case you didn't notice... :-)
> Page 7: A "specification" like TDS should SPECIFY, not say things like
> "administrators may wish..." as in section 2.4.
No. It's very usual for standards that they recommend things. In
fact, that's done in _every_ standard I've ever read.
In particular for the case at hand, binaries, it's problematic. The
TDS will not specify the location of binaries, that's a topic where
many adminitrators have local policies. Binaries are on the
borderside of the TDS domain anyhow, as they are not
implementation-independent. The decision to use bin/ and the
structure below is up to an administrator.
> Page 7, section 3, bottom paragraph: doesn't plain.tex belong in the source
> tree? An explanation or change is in order here.
Can you explain where you got the impression from that TeX macro
files belong in the source/ tree? We might need to improve that.
Currently, the source/ item tells: This includes both traditional
program sources and LaTeX dtx sources. Macro files are not mentioned
here.
> Page 12: "man is reserved for manual pages (Unix-style documentation)." What is
> so special about Unix that it gets mentioned specifically? TeX runs on more
> platforms than Unix. Consider adding "vmshelp is reserved for VMS help
> libraries" and similar for other OSs.
The person who puts together a TDS-compliant VMS-TeX distribution has
to tell us the name of the directory he wants there. As long as this
does not happen, we won't fix the name... I think, an additional
sentence that outlines that new system-specific directories might be
introduced here is needed.
> Page 15, section 10: "binaries, by system type" is called "optional". I think
> that a number of other things are also optional, e.g. some sites do not need
> Metafont (just use LaTeX, no math, PS fonts), others do not need LaTeX (use
> Metafont and plain TeX). This calls for more consistency.
`Optional' is here meant in the sense of `the specification is not
definitive here'. Binaries are by definition outside the strict target
domain of TDS.
> Page 15, Section 10: I do not think DVIPS is a TeX application. It is a DVI
> driver. AMSTeX, SliTeX, and LaTeX are TeX applications.
Hmm, in all texts I know an application is something that comes with a
program. No, IMO AMSTeX, SliTeX, and LaTeX are not TeX applications,
they are TeX formats.
I think we need a glossary, in particular, as many of our readers are
not from an English background.
------------------------------------------------------------
The following points are actually mentioned in the TDS draft:
> It is unclear to me what is to be considered source in the case of LaTeX. There
> are .DTX and .LTX files. Both can be considered source code, and the .DTX files
> are ALSO documentation, hence should go in the doc tree...? This specific
> example needs clarification.
p. 7, at the introduction of source/.
LTX files are not source files, btw. They are TeX macro files.
> Why is there no indication where the format files go (e.g. latex.fmt)??
p. 6, they are stored in the directories reserved for specific TeX
implementations (i.e., TeX ports). The structure there is made up by
the person who does the port, it's not our beef to get in conflict
with developers.
tex/formats is impossible, btw. Formats are not implementation-
independent.
------------------------------------------------------------
> That's all folks!
Thanks for your detailed comments. They are very helpful.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 11 Aug 1995 14:06:49 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508111904.VAA16299@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Experience with TWG-TDS
To: TWG-TDS@SHSU.edu
Date: Fri, 11 Aug 1995 21:04:40 +0200 (MESZ)
CC: c753330@nlzcl1.decnet.philips.nl
Content-Type: text
Ulrik wrote:
>
> > Suggestion: Add a list of "packages" (like psnfss, lw35nfss, babel, tools,
> > graphics) and where to put them. I for one cannot say if e.g. Babel should go
> > in tex/generic/babel or tex/latex/babel.
[The actual answer is in my previous mail.]
> Good question. I have installed Babel in /tex/generic/babel, because it's supposed
> to be generic, but I've put a symbolic link into tex/latex/babel, because it's
> distributed on CTAN below macros/latex/packages/babel. (Of course, this assumes
> that you have symbolic links. If not you'll have to decide either way.)
For heavens sake, no.
As LaTeX will search the generic area, too, it is not necessary to put
any special symbolic link or other things in the latex/ area for
generic packages. Where they are on CTAN is irrelevant for that decision.
The problem with babel is the ``is supposed to be generic''. That's
not the parameter of decision, it must be ``is generic''. The *.sty
files are not generic and therefore must not be placed in generic/.
The *.def files are generic and are placed in generic/.
> The .LTX are produced by stripping the documentation from the .DTX files.
I know that Ulrik knows it, but I want to emphasize it: There's more
to it than stripping documentation. LTX files are not LaTeX sources
any more, they are the macro files (objects) produced by compiling
(some) DTX files.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 11 Aug 1995 14:21:42 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508111919.VAA16349@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Experience with TWG-TDS
To: TWG-TDS@SHSU.edu
Date: Fri, 11 Aug 1995 21:19:16 +0200 (MESZ)
CC: c753330@nlzcl1.decnet.philips.nl
Content-Type: text
Alex wrote:
>
> > Hmm, I thought it was mentioned somewhere that this is implemntation-specific,
> > i.e. left to the implementor of the TeX distribution for specific platform.
>
> That's right. But I disagree, I think they merit specific mention. After
> all, no installation can do without them. Is there a specific reason NOT
> to specify it, apart from its being generated locally?
It's a matter of the TeX port. The TeX port has an area in the TDS and
is asked to place the FMT/Base files there. Different TeX ports will
use different sub-structures, as they have different demands. That's
the realm of a developer, not of the TDS.
> I have simply
> used /texmf/tex/formats/ and I can't think what's wrong with that.
That does not work if you use it for mutliple platforms. You can't use
a VMS FMT-file on Unix or on DOS. And it is important that we can use
the same texmf tree on many platforms. (E.g., mounted via NFS,
Netware, etc.) The current layout allows for such cross-platform
mounts. (It works, I use it this way for both Unix and DOS systems.)
> Is there no member in TWG-TDS who knows about VMS??? The remark you made
> about symbolic links also gave that impression.
There are several VMS folks on the discussion list. We have feedback
from Christian Spieler, Phil Taylor can be mentioned as a True
Believer as well. As for the direct members, I worked for six years
under VMS, two years as a VMS system administrator for a VAX cluster;
I hope that qualifies as `knows'. :-)
Again, somebody involved in the VMS-TeX-distribution must name the
specific directory he needs.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Sun, 13 Aug 1995 15:45:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun,13 Aug 95 17:54:41 BST
From: David.Rhead@vme.ccc.nottingham.ac.uk
Reply-To: TWG-TDS@SHSU.edu
Subject: Examples files for end-users
To: twg-tds@shsu.edu
Message-ID: <13_Aug_95_17.54.41.A14BBE@VME.NOTT.AC.UK>
Version 0.98 of the directory structure draft does not seem consistent
in its treatment of example files.
* Near the bottom of page 7, it envisages that Knuth's story.tex would
live in texmf/tex/plain/story.tex
* However, on page 13, it envisages that a Martian example would live in
texmf/doc/latex/martian/example.tex.
(I'm not clear where it envisages that example files such as LaTeX's
sample2e.tex and small2e.tex would fit into the 0.98 scheme.)
Doesn't the argument used for documentation apply equally to examples?
I.e.,
a separate, but parallel, structure for examples would (1) keep the
examples together and (2) make it as straightforward as possible
for users to find the particular examples they are after.
It might be suggested that the role of texmf/doc should be expanded to
include examples. (This view seems implicit in the Martian example.) I'm
skeptical about this, since the simple .tex files to be used as examples of
a particular point would often share directories with internally
complicated .tex files that act as documentation. It would be better to
keep
stuff that the novice can study, and copy as a starting point for
his/her .tex file
separate from
stuff whose gobbledegook the novice doesn't need to understand (they
might just as well have been given a .dvi file), since the idea is
just that the novice blindly sticks it through (La)TeX, and then
prints it and reads it, ignoring whatever complications were used to
produce it.
E.g., on one of our systems, we have a LaTeX examples directory that
contains subdirectories like:
bibtex - a minimal (but complete) example that shows the .tex and .bib
files involved in the LaTeX+BibTeX procedure
diy-bibs - a minimal/complete example that shows the use of \cite and
thebibliography for both author-date and `reference by number'
CVs - curriculum vitae. The idea is the novice copies a file from
here and replaces the example details by their own details.
lamport - sample2e.tex and small2e.tex
class-test - files for use when testing .cls files
tables - illustrations of how to get details (e.g., footnotes) right
in and around tables
thesis - a `thesis kit', containing a root file and some \included
chapter files. The idea is that the novice goes, e.g.,
cp * $HOME/thesis/.
and thus gets a ready-made `skeleton thesis' in $HOME/thesis.
They can start on their own thesis by changing the text in
one of the example chapter files.
title-pages - unfortunately, it doesn't seem easy to provide a single
title-page example as part of the thesis kit, so this
directory contains examples that meet the requirements
of different departments, faculties, etc. The student
just has to copy a suitable example and change the text.
other - solutions to odd typesetting problems that don't merit
a directory of their own (e.g., celestial co-ordinates for
astronomers).
In the next draft, how about saying the following?
* Analogously to
texmf/doc/category
there should be
texmf/examples/category
* Knuth's story.tex would go in
texmf/examples/tex
* Lamport's sample2e.tex and small2e.tex would go in
texmf/examples/latex
* the Martian example.tex would go in
texmf/examples/latex/martian
* local example .tex and (perhaps) .bib files that illustrate the
subleties needed to produce LaTeX-ed documents in the house-style of
O'Reilly & Associates (page 7 of version 0.98) would go in `a separate
tree' under
oratex/examples
David Rhead
University of Nottingham
david.rhead@nottingham.ac.uk
================================================================================
Archive-Date: Sun, 13 Aug 1995 15:45:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun,13 Aug 95 20:27:35 BST
From: David.Rhead@vme.ccc.nottingham.ac.uk
Reply-To: TWG-TDS@SHSU.edu
Subject: Roles of texmf and oratex (or analogue)
To: twg-tds@shsu.edu
Message-ID: <13_Aug_95_20.27.35.A14BCA@VME.NOTT.AC.UK>
Philosophically, there seem to be some difficulties with version 0.98 of
the draft along the
unofficial, local, mortal, site-dependent, us, ... , standard,
God-given, official, site-independent, Them
spectrum.
Continuing the example on page 7 of the draft, the end-user seeing the
division into /usr/local/oratex and /usr/local/texmf might be led to
believe that:
texmf - is all official God-given stuff and is bound to be right
oratex - is `just your local TeX administrator', who is human and fallible.
In fact:
* the individual stuff under texmf is produced by fallible humans
* the collection under texmf is likely to be put together by people
who have powerful software for collecting files into directories,
but have little time to look at what is in those files. The CTAN
people don't have time to `exert editorial control', to `get
stuff refereed', or to weed out `dead wood': this is likely
to be reflected in what is found under texmf.
E.g.
* suppose that under tex/doc/latex there is something that purports to
be an introduction to LaTeX, but which overemphasises visual
formatting. No-one is likely to delete it. Will anyone have time to
`balance' it by putting a read.me file in the same directory saying
`if you want to use LaTeX, you really ought to go and buy the Lamport
and/or Goossens et al. books!'?
* Somewhere under texmf, there is likely to be a FAQ file that -- about
"how to get a double-spaced thesis" -- says "argue fiercely with the
people who draft the outdated regulations". Somewhere else under
texmf, there is likely to be a .cls file that contradicts the FAQ by
meekly aiming to produce a double-spaced thesis.
* Whether something is under the oratex or texmf tree may depend on how
shy or otherwise the O'Reilly people are about putting stuff into the
public domain. But once under texmf, it may acquire an mystique --
even though it's just the same as it was under oratex.
Version 0.98 seems to imply a rigid division into
site-dependent versus standard
whereas I think reality has elements of a gradual spectrum.
On the other hand, I appreciate that you've got to decide something, and
that directory structures require files to be in one directory rather than
another. They can't sit on the boundary.
----------
Secondly, there are practical questions about things like dvips's
config.ps. (I appreciate that you're primarily concerned with macros,
fonts and implementation-independent TeX files, but there is "the matter of
practicality". There are also other things that need local configuration
files: maybe if I thought long enough I could think of one that was more to
do with "macros, fonts and implementation-independent TeX files".)
Suppose that config.ps arrives at a site in a form that is suitable for
"Karl and Kathy's printer" with a comment saying "edit at will".
Would the local administrator (e.g., at O'Reilly) hack at it under
texmf
or would s/he leave the copy under texmf as it is and put the
"editted at will" version under
oratex
?
Similarly (and this is more to do with macros, fonts and
implementation-independent TeX files), what happens if someone at O'Reilly
wants to submit a paper to a journal whose .cls file is not available
under texmf (in web2c or on the Prime Time CD). Suppose that the
journal-publisher supplies O'Reilly with the pre-print .cls file.
Faced with this `neither local nor standard' .cls file, does the local
administrator put it under
texmf/tex/latex/misc
or under
oratex/tex/latex/misc
?
----------
I wonder whether the practicalities of CDs give a de facto answer to
questions such as the above.
With CDs, one has the option of `running it off the CD', but doesn't have
the option of hacking at the files on the CD.
Thus:
* stuff under texmf is to be regarded as a "drop-in distribution
package" (as you say on page 15). Although reputable, it was compiled
by a human who had limited time for "editorial control". It is their
personal judgement of what should go on. To give a consistent
treatment of stuff supplied on CD and stuff supplied otherwise, the
stuff under texmf is not to be altered locally. (E.g., config.ps
stays as supplied for Karl and Kathy's printer.)
Different humans (Karl Berry, the NTG, ... ) will judge differently
about what is supplied to "drop in", but whatever it is will keep to
the TDS.
* local stuff is to go under the local analogue of oratex, which goes on
the search path before texmf. (E.g., the config.ps that is actually
used is below oratex, and it gets found before the Karl/Kathy one.)
* when a new distribution comes along (e.g., new NTG CD or new web2c),
all local hacks to the previous distribution are to be found under the
local analogue of oratex. The local administrator should check whether:
- bug-fixed software under oratex can be deleted, because the
bug-fix has at last made it into the "drop-in distribution" and
hence into texmf
- local hacks at stuff in texmf (e.g., dvips's config.ps) need
re-doing, because the version in the "drop-in distribution" has
changed.
* web2c gets regarded as read-only (even if it isn't on a CD). The
local administrator doesn't put extra .cls files under
texmf/tex/latex/misc
(where they might get clobbered by some future web2c). S/he puts
extra .cls files under
oratex/tex/latex/misc
(where they won't get clobbered if the web2c distribution is replaced).
* the contents of the local tree (oratex, or whatever) will depend to
some extent on what "drop-in distribution" someone relies on, since
the contents of the texmf tree will depend to some extent on the
judgement of whoever is assembling the "drop-in distribution".
----------
Could the next draft clarify what you envisage about such matters (whether
it is along the lines of the "de facto answer" I mentioned above, or along
some other lines)?
David Rhead
================================================================================
Archive-Date: Mon, 14 Aug 1995 10:17:52 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508141515.RAA14510@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Examples files for end-users
To: TWG-TDS@SHSU.edu
Date: Mon, 14 Aug 1995 17:15:12 +0200 (MESZ)
CC: david.rhead@vme.ccc.nottingham.ac.uk (David Rhead)
Content-Type: text
Concerning the examples/ proposal of David:
I think, examples are an integral part of documentation and should
therefore go in the doc/ area. If they contain of more than one file,
a subdirectory in the respective doc/-directory might be in order. But
that decision should be made by the documentation author, not by us.
We shouldn't spread the files targeted to human readers widely.
David wrote:
>
> * Near the bottom of page 7, it envisages that Knuth's story.tex would
> live in texmf/tex/plain/story.tex
IMO, that file should go in doc/plain/. (Or doc/plain/base/?)
> (I'm not clear where it envisages that example files such as LaTeX's
> sample2e.tex and small2e.tex would fit into the 0.98 scheme.)
doc/latex/base/ (again IMO). They are no macro files and thus don't
belong in tex/.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 14 Aug 1995 10:25:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 14 Aug 1995 12:58:12 +0200
Message-ID: <9508141058.AA08643@macbeth.uni-duesseldorf.de>
To: TWG-TDS@SHSU.edu
CC: David.Rhead@vme.ccc.nottingham.ac.uk
Subject: Re: Examples files for end-users
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
> Version 0.98 of the directory structure draft does not seem consistent
> in its treatment of example files.
> * Near the bottom of page 7, it envisages that Knuth's story.tex would
> live in texmf/tex/plain/story.tex
> * However, on page 13, it envisages that a Martian example would live in
> texmf/doc/latex/martian/example.tex.
> (I'm not clear where it envisages that example files such as LaTeX's
> sample2e.tex and small2e.tex would fit into the 0.98 scheme.)
Some time ago, I've suggested to put story.tex into both texmf/doc/tex
and texmf/tex/plain. texmf/doc/tex is the place for users to look at
the source file (and other documentation such as texbook.tex), whereas
texmf/tex/plain is the place where the file is found when running it
through TeX. If it weren't in texmf/tex/somewhere, users reading
The TeXbook would be suprised that "tex story" would suddenly fail.
(Same for "mf io" and "latex sample2e".)
Your suggestion of texmf/examples looks nice, but I'm uncertain
whether it is really needed. If the files are in texmf/doc and
there is a good navigational aid for first-time users to find these
examples, e.g. some sort of WWW front-end, this might be sufficient,
I think.
Thanks for your suggestions anyway.
Cheers,
Ulrik Vieth.
(Just a personal opinion, not speaking for TWG-TDS in general.)
================================================================================
Archive-Date: Mon, 14 Aug 1995 10:49:28 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 14 Aug 95 16:47:26 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9508141547.AA07326@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
CC: david.rhead@vme.ccc.nottingham.ac.uk
Subject: Re: Examples files for end-users
> I think, examples are an integral part of documentation and should
> therefore go in the doc/ area.
Agreed, I dont think the TDS can start to categorise what kind of
documentation is supplied.
> IMO, that file [story.tex] should go in doc/plain/. (Or
> doc/plain/base/?)
Agreed again probably. I seem to recall that the idea of putting
story.tex (and possibly the latex sample2e.tex) in the TeX input tree
is that joe user can type
tex story
when following that bit of the TeXbook, without having to copy the
file first, although this seems a slightly week argument especially in
the case of story.tex where the texbok suggests editing (a copy of)
the file in anycase.
David
================================================================================
Archive-Date: Mon, 14 Aug 1995 10:58:27 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 14 Aug 1995 16:55:09 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508141555.QAA06834@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
CC: david.rhead@vme.ccc.nottingham.ac.uk
Subject: Re: Examples files for end-users
References: <199508141515.RAA14510@spice.iti.informatik.th-darmstadt.de>
Joachim Schrod writes:
> >
> > * Near the bottom of page 7, it envisages that Knuth's story.tex would
> > live in texmf/tex/plain/story.tex
>
> IMO, that file should go in doc/plain/. (Or doc/plain/base/?)
well, i bet many TeX guides say
"try typing
tex story
and view the result"
thats the problem. but i agree with Joachim, we stamp out this sort of
thing. doc/plain/knuth, IMHO
sebastian
================================================================================
Archive-Date: Mon, 14 Aug 1995 11:14:49 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508141601.SAA17427@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Examples files for end-users
To: TWG-TDS@SHSU.edu
Date: Mon, 14 Aug 1995 18:01:56 +0200 (MESZ)
Content-Type: text
Ulrik wrote:
>
> [story.tex]
> texmf/tex/plain is the place where the file is found when running it
> through TeX. If it weren't in texmf/tex/somewhere, users reading
> The TeXbook would be suprised that "tex story" would suddenly fail.
As they are told one page earlier that they shall ``Use your favorite
text editor to create a file called story.tex that contains the
following 18 lines of text'', they shouldn't be surprised if it fails
without that first step.
Nowhere in the TeXbook is it mentioned that the file story.tex is
available on-line, so I'm not willing to accept a postulate that we
are bound by the TeXbook in that matter.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 14 Aug 1995 12:03:32 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508141601.SAA17427@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Examples files for end-users
To: TWG-TDS@SHSU.edu
Date: Mon, 14 Aug 1995 18:01:56 +0200 (MESZ)
Content-Type: text
Ulrik wrote:
>
> [story.tex]
> texmf/tex/plain is the place where the file is found when running it
> through TeX. If it weren't in texmf/tex/somewhere, users reading
> The TeXbook would be suprised that "tex story" would suddenly fail.
As they are told one page earlier that they shall ``Use your favorite
text editor to create a file called story.tex that contains the
following 18 lines of text'', they shouldn't be surprised if it fails
without that first step.
Nowhere in the TeXbook is it mentioned that the file story.tex is
available on-line, so I'm not willing to accept a postulate that we
are bound by the TeXbook in that matter.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 14 Aug 1995 12:06:13 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508141601.SAA17427@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Examples files for end-users
To: TWG-TDS@SHSU.edu
Date: Mon, 14 Aug 1995 18:01:56 +0200 (MESZ)
Content-Type: text
Ulrik wrote:
>
> [story.tex]
> texmf/tex/plain is the place where the file is found when running it
> through TeX. If it weren't in texmf/tex/somewhere, users reading
> The TeXbook would be suprised that "tex story" would suddenly fail.
As they are told one page earlier that they shall ``Use your favorite
text editor to create a file called story.tex that contains the
following 18 lines of text'', they shouldn't be surprised if it fails
without that first step.
Nowhere in the TeXbook is it mentioned that the file story.tex is
available on-line, so I'm not willing to accept a postulate that we
are bound by the TeXbook in that matter.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Tue, 15 Aug 1995 11:27:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 15 Aug 1995 18:26:42 CET +0100
From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" <SPIELER@linac.ikp.physik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@shsu.edu
CC: c753330@nlzcl1.decnet.philips.nl, SPIELER@linac.ikp.physik.th-darmstadt.de
Message-ID: <00994EC5.22498DE0.2@linac.ikp.physik.th-darmstadt.de>
Subject: implementation specific part of a TDS layout for VMS TeX
In response to "Alex's" (VMS) user comment, I want to introduce my solution
of a TDS compliant directory structure for the implementation specific
part of a VMS TeX installation:
All VMS specific files (executables; command procedures;
help files, - libraries; string pools, formats, bases; various management
stuff; etc.) are collected in a subtree below a top level directory
TEX_ROOT:[VMS] (`texmf/vms/' in UNIX notation).
Note that I do NOT use a top level `bin' directory.
(NB: The directory name 'bin' is one of those misleading terms introduced
by bad UNIX habits: The UNIX bin directories do not contain `binary'
files, but `executable' files. Many of those executable files are
in fact binaries (compiled and linked programs), but in most cases,
a 'bin' directory contains shell scripts as well, and these are
ordinary text files! For VMS, I use `exe' instead of `bin'.)
My current layout in a bit more detail:
texmf/
vms/ : VMS implementation specific stuff (*1)
exe/ : `end user' commands
common/ : command procedures, command definition
files,...
axp/ : binary executables for Alpha AXP
vax/ : binary executables for VAX
formats/ : pool and dump files (formats resp. bases)
for TeX and METAFONT (see Remark *2)
help/ : VMS help library, and (currently)
miscellanous help sources;
perhaps other VMS specific docs.
mgr/ : Miscellanous files for TeX system
management purpose (command procedures,
programs, and docs), not intended for
ordinary end users.
Remarks:
*1 In case there appears another VMS implementation besides Public DECUS
TeX, the top level implementation directory name should be modified
to something more specific. (e.g.: vms/ -> vms_decus/)
*2 It is a VMS (DECUS TeX) specific tradition to keep TeX and MF dump files
in a common directory (they do not interfere), but there is no objection
to use a separate directory bases/ for METAFONT's pool and dump files.
Note that the VMS help files are NOT kept in the (top level) `doc/' area.
The VMS help files are not intended for direct reading or printing
(although this could be done, they are ASCII text files); they should
rather be used with the VMS help utility.
(An explanation for those not familiar with VMS:
The VMS help utility read the help texts from special text libraries
("help libraries") which are created and maintained with the VMS Librarian
utility. The help libraries (.HLB files) are `binary' files (not
printable/readable). In contrast, an individual module extracted from a
help library -- a .HLP file -- is an editable ASCII text file in a special
format. But, im most cases, the source for a help text is produced as
a `runoff' file (.RNH file); the .HLP module for the help library is the
result of applying the RUNOFF utility to the .RNH source file.)
The VMS help sources are partly supplied together with program sources
(in the `source/' tree). In those cases where a help source is not
associated with a distinct program, the sources are currently stored
in the `help' directory, too.
My next (CTAN) release of VMS DECUS TeX will use the shown directory
layout. With the exception of the directory structure for PK font files,
this release should then conform to the TDS draft.
I want to suggest a generalization of this approach:
a) The top level `doc/' area (as part of the implementation independent
TDS specification) is overly crowded. In my eyes, this area should
only carry (mostly) implementation independent documentation and
example files. These files should be intended for direct reading
as normal text files (.TXT, read.me, etc.), for printing (Postscript
files), or for processing with the TeX system's own utilities
(aka: TeX source files, Texinfo source files, .DVI files...).
b) Documentation files in a system specific format should be kept in
the implementation specific part of the TeX installation, somewhere
below a top level `implementation' directory.
Examples are:
- UNIX implementation (web2c): man pages
(man pages are not intended for direct reading, they should be
used through a man page formatter which is not standard on many
non-UNIX systems.)
- VMS implementation (DECUS): help library files
- OS/2 (emTeX): BOOK files, INF files for the OS/2 WPS shell.
- MAC: ???
c) The top level 'bin' directory as starting point for implementation
specific subtrees should be removed; its implication that only
"binary" files may be implementation specific is definitely wrong.
Instead, each implementation should put its specific files in a
subtree, starting with a unique top level directory specifying the
implementation. The organisation of these system specific subtrees
is up to the implementor and not target of the TDS specification.
(This does not exclude hints in the TDS text how things ``could''
be organized. In my eyes, some typical examples are welcome. These
may help different implementors to choose similar looking structures,
so that the installing/maintaining tasks of different implementations
do not differ too much.
d) In addition to those file formats mentioned above (item a)), the
doc/ area may contain ready-to-use GNU info files (.info) and
WWW (.html) browser files. Althought special utilities are needed
to effectly use/read these documentation files, they are not system
specific, since both WWW and GNU info readers are available for many
of the more popular OS systems.
Some examples of possible implementation specific trees:
i) VMS DECUS TeX: see above
ii) Unix TeX (web2c):
texmf/
web2c/ : web2c specific files
First, web2c files that do not depend on a particular
UNIX version or CPU type:
/bin : common scripts, not depending on
a particular CPU or OS version;
e.g.: MakeTeXPK
/bases : MF base dump files (and mf.pool)
/formats : TeX format dump files (and tex.pool)
/man .. : web2c man pages
Now, there are (one ore more) OSversion/CPU specific subdirs
which contain the nonportable binaries:
/sun_os : SUN computers (older OS versions)
/bin : binary program executables
/sparc_solaris : SUN sparc, running Solaris
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
/dec_mips_ultrix : Decstations based on MIPS cpu
/bin : binary program executables
/dec_axp_osf : DEC Alpha AXP under OSF (DEC Unix)
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
/hp{xxx} : HP computers
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
/ibm_aix : IBM 6000 workstations, under AIX
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
/linux_intel : IBM PC (386 up) under Linux
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
/linux_alpha : Linux on Alpha PCs
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
/linux_motorola : Linux on 68xxx computers (Amiga?)
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
/BSD386 : IBM PC (386 up) under FreeBSD...
/bin : binary program executables
{ /lib : support libraries, DLLs (??) }
Remark: Some of the UNIX systems support (in principle) shareable libraries.
If (a future version of) web2c is configured to produce and use
private shareable libraries, one may need/want a separate directory
where these "DLLs" are stored. This is expressed with those "/lib"
subdirectory lines.
(I do not really know how/where shareable libraries are stored
on these newer UNIX systems, this was just a guess.)
iii) MSDOS and OS/2 (emTeX):
texmf/
emtex/ : E. Mattes joined DOS&OS/2 implementation
/bin : binary executables (both systems),
.BAT files (DOS), .CMD files (OS/2)
/btexfmts : BigTeX (64bit) dump files and pool
/texfmts : SmallTeX (32bit) dump files and pool
/bmfbases : BigMF (64bit) dump files and pool
/mfbases : SmallMF (32bit) dump files and pool
/mfjob : control scripts for MFJOB utility
/data : misc support and config files
/dll : dynamic link libraries (OS/2)
/book : OS/2 online documentation books (.INF)
/german
/english
/doc ... : emTeX program documentation files.
/german
/english
/help : OS/2 WPS help files (.hlp)
Remark: The emTeX specific documentation files (those that describe how
to install and use the em implementations of the programs) are kept
in the system specific tree despite the fact that they are directly
readable/printable ASCII text files. But, their information is of
no use for non-emTeX users.
iv) MSDOS PubliC-TeX (DOS-TP, Copyleft Turbo Pascal implementation):
texmf/
dos_tp/ : P. Breitenlohner's TP implementation
/bin : binary executables, and (possibly)
.BAT files
/formats : TeX dump files and pool
/bases : METAFONT dump files and pool
/doc : (optional) area for installation
readme files.
================================================================================
Archive-Date: Tue, 15 Aug 1995 11:59:16 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 15 Aug 1995 18:27:57 CET +0100
From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" <SPIELER@linac.ikp.physik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
To: twg-tds@shsu.edu
CC: SPIELER@linac.ikp.physik.th-darmstadt.de
Message-ID: <00994EC5.4EF78AE0.7@linac.ikp.physik.th-darmstadt.de>
Subject: Suggestion: differenciate "package" and "program" sources
Hello again,
In addition to my suggestions concerning the implementation specific
part of the texmf tree, I would like to have an additional categorizing
level below the "source/" top level directory:
In my opinion, it would be helpful to differentiate between
sources that are to be processed (mainly) by the TeXMF system's own
programs and sources where you need system supplied compilers to process
them. For the first category, I used a subdirectory "packages/", the latter
was named "progs/" ("programs/"):
texmf/
source/ : source distributions...
packages/ : `macro' type source sets
latex/
base/
mfnfss/
graphics/
tools/
babel/
latex209/ ....
fontinst/ ....
progs/ : `program' type source sets (to be compiled)
bibtex/
dviware/
dvips/
xdvi/
makeindex/
tex_mf/
tex/
mf/
texware/
mfware/
web/
The "progs/" part of the source tree gives rise to an additional problem:
At least for some programs, the "source" is implementation specific. This
is the case for all programs written in Web. Depending on the implementation,
change files and (optional) compiling procedures are different.
(See, for example, the web2c distribution and the DOS-TP distribution of
TeX and METAFONT.)
For other programs, the canonic source distribution contains support
for many different OS environments (e.g.: Makeindex, (non-k) dvips and xdvi,
Beebe DVI drivers, Ghostscript).
Maybe, for "prog" type of source sets, there should be a recommendation
where differentiations between different implemenation adaptations could
be introduced.
One might consider to introduce the same differentiation between "progs"
and "packages" in the doc area. On a large TeX system with many installed
pachages and programs, the top level doc/ directory list gets rather long,
making it difficult to find documentation for a particular program/package.
(On the other hand, do we get short of directory levels when this
additional hierarchy level is introduced?)
Best regards
Christian Spieler
================================================================================
Archive-Date: Wed, 16 Aug 1995 12:27:51 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508161727.TAA14530@spice.iti.informatik.th-darmstadt.de>
Subject: Re: implementation specific part of a TDS layout for VMS TeX
To: TWG-TDS@SHSU.edu
Date: Wed, 16 Aug 1995 19:27:26 +0200 (MESZ)
CC: c753330@nlzcl1.decnet.philips.nl
Content-Type: text
Christian wrote:
>
> In response to "Alex's" (VMS) user comment, I want to introduce my solution
> of a TDS compliant directory structure for the implementation specific
> part of a VMS TeX installation:
I like that summary a lot. I would agree to his proposal that bin/
should be dropped from the TDS draft.
And I would like to see (yet another ;-) appendix that presents the
outlines from Christian as example(s) of structures below the <TeX
implementation dir>. We had quite some question about that area and
that might clarify the point.
Of course, we do it only if Karl agrees to look over the web2c
example. :-) (E.g., the distinction of bases/ and formats/ is bogus,
web2c uses ini/ traditionally and will hopefully use something with a
version number in the future.)
Concerning the additional points raised by Christian: I don't care
where the man pages are. They may go under web2c/ -- I think most
system administrators will copy them to some local man page tree
anyhow. (At least, all admins I know do.)
Cheers,
Joachim
PS: Christian, still reluctant to put your name on the TDS paper, as
a group member? You provided lots of feedback about the VMS stuff, we
should acknowledge your contribution.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 16 Aug 1995 13:24:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 16 Aug 1995 20:22:35 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: implementation specific part of a TDS layout for VMS TeX
To: TWG-TDS@SHSU.edu
Message-ID: <01HU5JD7UO1U0003RO@VzdmzA.ZDV.Uni-Mainz.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Joachim Schrod wrote:
> Of course, we do it only if Karl agrees to look over the web2c
>example. :-) (E.g., the distinction of bases/ and formats/ is bogus,
>web2c uses ini/ traditionally and will hopefully use something with a
>version number in the future.)
I don't think, that the distinction formats vs. bases is bogus. I use to
store the log files from format/base generation together with the formats/
bases, and there is a conflict concerning the file plain.lis (oops, that
was VMSish, it should read plain.log), which could stem from plain.fmt or
plain.base. Okay, on a system with long filenames it could be named in a
unique way, like plain.log_bas and plain.log_fmt, however there are well
known computers where this possibility is not present.
--J"org Knappen
================================================================================
Archive-Date: Wed, 16 Aug 1995 15:06:22 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508162002.WAA14358@spice.iti.informatik.th-darmstadt.de>
Subject: Re: implementation specific part of a TDS layout for VMS TeX
To: TWG-TDS@SHSU.edu
Date: Wed, 16 Aug 1995 22:02:35 +0200 (MESZ)
Content-Type: text
You wrote:
>
> Joachim Schrod wrote:
>
> > Of course, we do it only if Karl agrees to look over the web2c
> >example. :-) (E.g., the distinction of bases/ and formats/ is bogus,
> >web2c uses ini/ traditionally and will hopefully use something with a
> >version number in the future.)
>
> I don't think, that the distinction formats vs. bases is bogus.
That statement was meant strictly in the realm of Unix & web2c.
I don't want to imply any implications for any other TeX ports.
(Cautious enough? :-)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 18 Aug 1995 10:55:08 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 18 Aug 1995 11:54:21 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508181554.AA00781@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: implementation specific part of a TDS layout for VMS TeX
I would agree to his proposal that bin/
should be dropped from the TDS draft.
I agree, too. bin/ and man/ can go under web2c/ or be dropped altogether.
info/, I'm not sure about moving to doc/. Doesn't seem quite right to me.
Of course, we do it only if Karl agrees to look over the web2c
I dunno, is it necessary to provide the complete substructure for any of
the implementation dirs? I mean, sure, I'll do it, but not sure it's
right for the draft.
web2c uses ini/ traditionally and will hopefully use something with a
version number in the future.)
As we discussed, I think dealing with different versions is beyond the
scope of TDS and web2c, and the way to do it is to make texmf/web2c a
link to web2c-7.0 or whatever.
================================================================================
Archive-Date: Fri, 18 Aug 1995 10:55:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 18 Aug 1995 11:54:21 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508181554.AA00789@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: David.Rhead@vme.ccc.nottingham.ac.uk
Subject: Re: Roles of texmf and oratex (or analogue)
unofficial, local, mortal, site-dependent, us, ... , standard,
God-given, official, site-independent, Them
This is an important question; we don't want the TDS to give this
impression (at least *I* don't want it to). I agree with everything
(more or less :-) David says. We can and should do *something* about
local files. /usr/local/oratexmf isn't enough. The stuff David says at
the end about what to do seems reasonable to me.
Sorry, but I can't dream up any real wording changes right now.
P.S. From what I read of David's implementations, they're better
maintained than anyone else's ... maybe we should just declare those
standard and forget the TDS :-) :-) ?
================================================================================
Archive-Date: Mon, 21 Aug 1995 04:06:53 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508141601.SAA17427@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Examples files for end-users
To: TWG-TDS@SHSU.edu
Date: Mon, 14 Aug 1995 18:01:56 +0200 (MESZ)
Content-Type: text
Ulrik wrote:
>
> [story.tex]
> texmf/tex/plain is the place where the file is found when running it
> through TeX. If it weren't in texmf/tex/somewhere, users reading
> The TeXbook would be suprised that "tex story" would suddenly fail.
As they are told one page earlier that they shall ``Use your favorite
text editor to create a file called story.tex that contains the
following 18 lines of text'', they shouldn't be surprised if it fails
without that first step.
Nowhere in the TeXbook is it mentioned that the file story.tex is
available on-line, so I'm not willing to accept a postulate that we
are bound by the TeXbook in that matter.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 23 Aug 1995 02:58:12 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <199508230757.RAA09913@asgard.mlb.dmt.csiro.au>
To: twg-tds@shsu.edu
Subject: TDS-0.98 and multiple format/pool files
Date: Wed, 23 Aug 1995 17:57:49 +1000
From: Robin Kirkham <rjk@mlb.dmt.csiro.au>
Reply-To: TWG-TDS@SHSU.edu
Hello
I'm assembling a TeX system at our site at present, and I am attempting to
follow the draft TDS standard 0.98. We will soon have a hetrogeneous NFS
filesystem, with several different workstations/operating systems accessing the
TeX tree.
The TDS document suggests sub-directories texmf/bin/<system> for binaries
(executables) for different systems (CPU/operating system combinations). For
instance, I would probably have
texmf/bin/sparc-sunos4
texmf/bin/sparc-solaris
texmf/bin/i486-linux
(ignoring filename-length for the time being). This is a reasonable approach,
and one used elsewhere. The problem is, where do the format and pool files go?
Different systems cannot in general share format and pool files, so they need
to be segregated and named in a consistent fashion.
The TDS document gives no advice on this subject, as far as I can tell, and the
sample TDS tree on the CTAN archive suggests that these file go in (I think)
texmf/web2c/ini, or something like that.
My preference would be for these system-dependent files to go in with the
executables, i.e. texmf/bin/<system>.
Any comments?
Robin Kirkham CSIRO Division of Manufacturing Technology
Project Engineer Locked Bag 9, Preston 3072, Australia
robin.kirkham@mlb.dmt.csiro.au Phone: +61 3 9662-7756 Fax: +61 3 9662-7853
================================================================================
Archive-Date: Wed, 23 Aug 1995 05:39:02 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508231037.MAA20763@spice.iti.informatik.th-darmstadt.de>
Subject: Re: TDS-0.98 and multiple format/pool files
To: TWG-TDS@SHSU.edu
Date: Wed, 23 Aug 1995 12:37:00 +0200 (MESZ)
CC: rjk@mlb.dmt.csiro.au
Content-Type: text
Robin Kirkham wrote:
>
> The TDS document suggests sub-directories texmf/bin/<system> for binaries
> (executables) for different systems (CPU/operating system combinations). For
> instance, I would probably have
>
> texmf/bin/sparc-sunos4
> texmf/bin/sparc-solaris
> texmf/bin/i486-linux
>
> (ignoring filename-length for the time being). This is a reasonable approach,
> and one used elsewhere. The problem is, where do the format and pool files go?
> Different systems cannot in general share format and pool files, so they need
> to be segregated and named in a consistent fashion.
Please note that all web2c-based TeX implementations may use the
_same_ format and pool files, independent of hardware architecture and
operating system.
This is one of the reasons why we recommend putting such files in a
subdirectory that's specific for the TeX implementation, i.e.,
somewhere below web2c/. Where it is put there is not decided by the
TDS effort, this is up to the system's author.
Actually, there is a discussion about discarding the bin/ directory
in the TDS draft, and moving executables to the
TeX-implementation-directory (here: web2c/) as well, most probably in
subdirectories thereof. (The name `bin/' is a Unix-centric notion,
and folks from other OS backgrounds have mentioned their discomfort.)
Bottom line: How about
texmf/web2c/
bin/<platform>/ for executables
ini/ for formats, bases, and pool files
Btw, _I_ wouldn't restrict myself to 8 characters in <platform>. The
TDS does not restrict the file name length. It merely acknowledges
the problem connected to the length issue in particular in the realm
of CD-ROM distributions, names the constraints we found, and makes
sure that the directory names fixed in the draft adhere to this
restriction.
If one makes an installation that is only stored on real operating
systems, one can use long names. Even if that installation is
accessed by DOS (e.g, via PC-NFS), there is no problem -- the DOS TeX
should never look into texmf/web2c/. One should just not assume that
one can transport such an installation file-wise via DOS floppies
afterwards without loss of information.
Hope this helps,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 23 Aug 1995 09:17:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 23 Aug 1995 10:17:20 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508231417.AA21376@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: rjk@mlb.dmt.csiro.au
Subject: Re: TDS-0.98 and multiple format/pool files
Please note that all web2c-based TeX implementations may use the
_same_ format and pool files, independent of hardware architecture and
operating system.
I believe pool files are even sharable across implementations ... modulo
the pesky CRLF stuff.
Also, it's possible to turn off the creation of sharable (read:
BigEndian) format files. This speeds up execution on LittleEndian
machines. If you do this, some kind of distinction needs to be made,
clearly ... but I don't think the TDS could recommend anything. It would
cause more harm than good.
================================================================================
Archive-Date: Wed, 23 Aug 1995 11:30:46 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 23 Aug 1995 10:17:20 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508231417.AA21376@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: rjk@mlb.dmt.csiro.au
Subject: Re: TDS-0.98 and multiple format/pool files
Please note that all web2c-based TeX implementations may use the
_same_ format and pool files, independent of hardware architecture and
operating system.
I believe pool files are even sharable across implementations ... modulo
the pesky CRLF stuff.
Also, it's possible to turn off the creation of sharable (read:
BigEndian) format files. This speeds up execution on LittleEndian
machines. If you do this, some kind of distinction needs to be made,
clearly ... but I don't think the TDS could recommend anything. It would
cause more harm than good.
================================================================================
Archive-Date: Wed, 23 Aug 1995 22:39:21 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <199508240255.MAA01015@asgard.mlb.dmt.csiro.au>
To: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
CC: TWG-TDS@shsu.edu
Subject: Re: TDS-0.98 and multiple format/pool files
Date: Thu, 24 Aug 1995 12:55:15 +1000
From: Robin Kirkham <rjk@mlb.dmt.csiro.au>
Reply-To: TWG-TDS@SHSU.edu
Joachim/Karl,
Thank you for your quick replies. Pool/format files seem less of a problem
to me now, and texmf/web2c/ini looks reasonable.
Joachim Schrod writes:
> Actually, there is a discussion about discarding the bin/ directory
> in the TDS draft, and moving executables to the
> TeX-implementation-directory (here: web2c/) as well, most probably in
> subdirectories thereof. (The name `bin/' is a Unix-centric notion,
> and folks from other OS backgrounds have mentioned their discomfort.)
>
> Bottom line: How about
>
> texmf/web2c/
> bin/<platform>/ for executables
> ini/ for formats, bases, and pool files
This has some sense to it, but I see some problems. Firstly, the logical
extension to this is that you would have
texmf/web2c/bin/<platform>/
texmf/dvips/bin/<platform>/
texmf/xdvi/bin/<platform>/
texmf/makeindex/bin/<platform>/
...
that is, one bin/ (or exe/ or exec/ or whatever) for each TeX-related program.
I don't think this is a good idea at all, because users would have to have all
these directories in their PATH (or equivalent). It certainly isn't standard
UNIX or MSDOS practice.
You could side-step this be retaining texmf/bin/, and placing in it symbolic
links, shell scripts, batch files (or whatever) which pointed to/executed the
appropriate binary. If scripts were used, they could be clever enough to
determine <platform> as well (at least within a shared UNIX tree), which is
handy for the users. (I am considering doing this at my site, no matter where
the binaries actually end up).
Another snag is for systems that use shared transparent file systems or
automounters. With these (among other things) you can have a file tree which is
part shared and part platform-specific. In other words, different platforms
would share most of the texmf/ tree, but the automounter/file-system would
transparently substitute the appropriate bin/ directory for the user's
platform, and they don't have to worry about what platform they are on.
If there are a lot of texmf/*/bin/ directories then this starts to get messy,
as the file-system configuration has to change whenever a new TeX-related
program is installed. The maintainer of texmf/ (as the TWG-TDS 0.98 correctly
points out) is not always the system administrator.
So, given that pool/format files can in fact be shared, at least across
platforms for a given TeX implementation, (Norman Walsh's Making_TeX_Work
pp48-49 notwithstanding), I would suggest retaining the texmf/bin/, with
optional texmf/bin/<platform>/, as in the TDS 0.98.
As far as "bin/" goes, it is true that it is UNIX-centric, but MSDOS and
Windows packages in my experience use either nothing extra at all (i.e., they
use a directory named after the name of the package). Frequently, all the
package's files---executable or otherwise---are tossed in the same directory,
which is exactly what the TDS is trying to avoid. I don't know enough about
other operating systems to comment further on that issue.
Robin Kirkham CSIRO Division of Manufacturing Technology
Project Engineer Locked Bag 9, Preston 3072, Australia
robin.kirkham@mlb.dmt.csiro.au Phone: +61 3 9662-7756 Fax: +61 3 9662-7853
================================================================================
Archive-Date: Thu, 24 Aug 1995 04:34:29 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508240903.LAA11184@spock.iti.informatik.th-darmstadt.de>
Subject: Re: TDS-0.98 and multiple format/pool files
To: rjk@mlb.dmt.csiro.au (Robin Kirkham)
Date: Thu, 24 Aug 1995 11:03:34 +0200 (MESZ)
CC: schrod@iti.informatik.th-darmstadt.de, TWG-TDS@shsu.edu
Content-Type: text
You wrote:
>
> > Actually, there is a discussion about discarding the bin/ directory
>
> This has some sense to it, but I see some problems. Firstly, the logical
> extension to this is that you would have
>
> texmf/web2c/bin/<platform>/
> texmf/dvips/bin/<platform>/
> texmf/xdvi/bin/<platform>/
> texmf/makeindex/bin/<platform>/
> ...
>
> that is, one bin/ (or exe/ or exec/ or whatever) for each TeX-related program.
Yes, we need to go into more detail. Probably, it's best to describe a
set of possibilities except of _the_ one. Placement of executables
cannot be standardized yet, IMO; we just may give hints to existing
practice.
Cheers, and thanks a lot for your valuable feedback,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 28 Aug 1995 16:27:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon,28 Aug 95 16:25:14 BST
From: David.Rhead@vme.ccc.nottingham.ac.uk
Reply-To: TWG-TDS@SHSU.edu
Subject: Examples files for end-users
To: twg-tds@shsu.edu
Message-ID: <28_Aug_95_16.25.14.A16A9C@VME.NOTT.AC.UK>
I saw several messages in response to my mail of 13th August about
`examples files for end-users',
The consensus seemed to be that you're not convinced that there needs
to be a
texmf/examples
as well as the
texmf/doc
On the other hand, you agree that things like story.tex, small2e.tex and
sample2e.tex shouldn't be hidden away where people can't find them.
Generally, you're inclined to put such examples files into the same
directory as documentation.
Version 0.98 of the draft argues for texmf as the name for the root of
the tree on the grounds that it contains files for `not just TeX itself'.
If examples files go in the same directory as documentation, does a similar
argument apply? Should one say that, since the directory is not just for
documentation but also for examples, its name should signify both roles?
This might lead to a name such as
texmf/doc_ex
which hints at documentation, and examples, and `documentation containing
examples'.
Given such a hint, the user might be better able to cope with a directory
that may contain a mixture of:
examples - simple .tex files whose TeX commands the novice can
understand and imitate
documentation - (possibly) extremely complicated .tex files whose
TeX commands might frighten the novice. But the novice doesn't
actually need to be frightened, because these .tex files exist
purely so that the end-user can get instructions by [La]TeXing
the .tex file, and reading the resulting typeset document.
David Rhead
================================================================================
Archive-Date: Tue, 29 Aug 1995 06:07:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199508291107.NAA17256@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Examples files for end-users
To: TWG-TDS@SHSU.edu
Date: Tue, 29 Aug 1995 13:07:02 +0200 (MESZ)
CC: david.rhead@vme.ccc.nottingham.ac.uk (David Rhead)
Content-Type: text
You wrote:
>
> I saw several messages in response to my mail of 13th August about
> `examples files for end-users',
>
> The consensus seemed to be that you're not convinced that there needs
> to be a
> texmf/examples
> as well as the
> texmf/doc
> On the other hand, you agree that things like story.tex, small2e.tex and
> sample2e.tex shouldn't be hidden away where people can't find them.
For the record: That can't be the `consensus' as at least one person
does not agree with that. (Guess whom. ;-)
As my viewpoint obviously wasn't expressed clear enough: Examples
_are_ documentation. They are not even a special part of
documentation, they are an integral part of it.
Documents like small2e.tex and sample2e.tex are neither less nor
more important than usrguide.tex or the Local Guide. Neither them nor
the user manual should be hidden away and both should be found. I
cannot see why we should force users to search for such basic
documents at two different locations.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
Archive-Date: Thu, 07 Sep 1995 11:23:22 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0sqjhH-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Thu, 7 Sep 95 17:21 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Installing TDS at Sussex
I've just spent a merry few days installing a TDS compliant TeX using
web2c TeX. Oh what fun it was. The main customization I had to do
was produce a new MakeTeXPK, which I'll attatch for those interested.
It's not exactly a work of art, and it's site-specific, but it may be
of some use for others...
There's no TDS directory specified for images, which is odd, since
they have to be on the TEXINPUTS path in order for graphics.sty to
pick them up. I ended up using texmf/images/<type>/<group>/<file>, eg
texmf/images/epsf/sussex/ssxcrest.eps for our crest.
The main point where I disagreed with TDS was the specification that
local files should be put outside the heirachy. There's no way on
earth I'm going to duplicate all of the TDS structure, so I used files
like texmf/tex/latex/sussex/ssxlet.cls for our letter class.
This makes our TEXINPUTS .:$TEXMF/tex//:$TEXMF/images//
Anyway, it all worked, the punters haven't complained too much so
far...
Alan.
--- that MakeTeXPK script in full ---
#!/bin/sh
#
# Filename: MakeTeXPK
# Author: Alan Jeffrey
# Date: 1995/09/05
#
VERSION=1.0
#
# This is the COGS script to generate missing PK files.
# It's based very loosely on Karl Berry's, but is almost entirely new.
#
# This script must echo the name of the generated PK file (and nothing
# else) to standard output.
#
# Parameters:
# name dpi bdpi magnification [mode]
#
# `name' is the base name of the font, such as `cmr10'.
# `dpi' is the resolution the font is needed at.
# `bdpi' is the base resolution, used to intuit the mode to use.
# `magnification' is a string to pass to MF as the value of `mag'.
# `mode', if supplied, is the mode to use. Unless it's `default', in
# which case we guess. (This is so people can specify a destdir
# without a mode.)
#
# Any other parameters are ignored (in particular, other MakeTeXPKs
# accept an optional destination directory argument, which we ignore).
# Where to find fonts
: ${TYPEONEDIR=/local/texmf/fonts/type1}
: ${MFDIR=/local/texmf/fonts/source}
: ${AFMDIR=/local/texmf/fonts/afm}
# Where to put fonts
: ${PKDIR=/local/texmf/fonts/pk}
# Where to find helper applications
: ${METAFONT=/local/texmf/bin/solaris/mf}
: ${GFTOPK=/local/texmf/bin/solaris/gftopk}
: ${GSFTOPK=/local/texmf/bin/solaris/gsftopk}
: ${FIND=/usr/bin/find}
# Where the psfonts.map file is
: ${PSFONTSMAP=/local/texmf/dvips/psfonts.map}
# TEMPDIR needs to be unique for each process because of the possibility
# of processes simultaneously running this script.
TEMPDIR=${TMPDIR-/tmp}/mtpk.$$
# Check we've got enough arguments.
if test $# -lt 4; then
echo "Usage: $0 name dpi bdpi mag [mode]." >&2
exit 1
fi
NAME=$1
DPI=$2
BDPI=$3
MAG=$4
MODE=$5
# Print out a `friendly' banner.
echo "" >&2
echo "This is MakeTeXPK, COGS Version $VERSION." >&2
echo "" >&2
echo "This script is called because you are the first person at COGS" >&2
echo "to use the bitmapped font $NAME.$DPI""pk." >&2
echo "It will take a few moments to make the bitmap." >&2
echo "The bitmap will be filed, so it will not be created by this script again." >&2
echo "" >&2
# If MODE is empty or "default", then make it cx.
if test -z "$MODE" || test "$MODE" = default; then
MODE=cx
fi
# OK, now we try to find the font, first looking for a MF font.
FONTHOME=`$FIND $MFDIR -name $NAME.mf -print`
if test -z "$FONTHOME" ; then
#
# If we can't find an MF font, then we look in the psfonts.map
# file to see if we can find an entry with a downloaded .pfa or .pfb
#
TYPEONEFILE=`egrep "^$NAME .*\.pfa" $PSFONTSMAP | sed 's/.*\([a-zA-Z0-9]*\.pf.\).*/\1/'`
if test -z "$TYPEONEFILE" ; then
#
# Otherwise, the font is a resident font, and we search for
# an AFM file that is the same, possibly with the encoding
# 8r replaced by 8a.
#
AFMFILE=`echo $NAME | sed -e 's/8r/8a/'`
FONTHOME=`$FIND $AFMDIR -name $AFMFILE.afm -print`
else
#
# If we can, we use find to find the file.
#
FONTHOME=`$FIND $TYPEONEDIR -name $TYPEONEFILE -print`
fi
fi
# If we've still got an empty FONTHOME, then we give up.
if test -z "$FONTHOME"; then
echo "$0: Failed to find $NAME." >&2
echo "$0: This shouldn't happen!" >&2
echo "$0: Please send a bug report to texpert@cogs." >&2
exit 1
fi
# We now tear FONTHOME apart to get the location of the font.
echo "Font source: $FONTHOME" >&2
set `echo $FONTHOME | sed -e 's/^.*\([^/.]*\)\/\([^/.]*\)\/\([^/.]*\)\/\([^/.]*\)\.\([^/.]*\)$/\2 \3 \5/'`
SOURCE=$1
FAMILY=$2
TYPE=$3
if test "$TYPE" != "mf"; then
MODE=gsftopk
fi
DESTDIR=$PKDIR/$MODE/$SOURCE/$FAMILY/dpi$DPI
PKNAME=$NAME"."$DPI"pk"
GFNAME=$NAME"."$DPI"gf"
echo "Font target: $DESTDIR/$PKNAME" >&2
echo "" >&2
# Allow fonts to be read and written (especially in case we make
# directories) by everyone.
umask 0
# Make sure the destination directory exists.
test -d $PKDIR/$MODE/$SOURCE || mkdir $PKDIR/$MODE/$SOURCE
test -d $PKDIR/$MODE/$SOURCE/$FAMILY || mkdir $PKDIR/$MODE/$SOURCE/$FAMILY
test -d $PKDIR/$MODE/$SOURCE/$FAMILY/dpi$DPI || mkdir $PKDIR/$MODE/$SOURCE/$FAMILY/dpi$DPI
# Clean up on normal or abnormal exit.
trap "cd /; rm -rf $TEMPDIR $DESTDIR/pktmp.$$" 0 1 2 15
# Go to the unique working directory.
test -d $TEMPDIR || mkdir $TEMPDIR
cd $TEMPDIR || exit 1
# Make that bitmap!
if test "$TYPE" = "mf" ; then
# Got a Metafont source, so run Metafont.
echo $METAFONT "\mode:=$MODE; mag:=$DPI/300; scrollmode; input $NAME;" >&2
$METAFONT "\mode:=$MODE; mag:=$DPI/300; scrollmode; input $NAME;" >&2 || exit 1
echo $GFTOPK $GFNAME >&2
$GFTOPK $GFNAME >&2 || exit 1
else
# Got a Type 1 source, so run gsftopk.
echo $GSFTOPK $NAME $DPI >&2
$GSFTOPK $NAME $DPI >&2 || exit 1
fi
# Look to see if another MakeTeXPK job has already made the bitmap
if test -r $DESTDIR/$PKNAME; then
echo "$0: $DESTDIR/$PKNAME already exists." >&2
echo $DESTDIR/$PKNAME
exit 0
fi
# Install the PK file carefully, since others may be working simultaneously.
mv $PKNAME $DESTDIR/pktmp.$$ \
|| { echo "$0: Could not mv $PKNAME $DESTDIR/pktmp.$$." >&2; exit 1; }
cd $DESTDIR || exit 1
mv pktmp.$$ $PKNAME
echo "" >&2
echo "Installation successful" >&2
# If this line (or an equivalent) is not present, dvipsk/xdvik/dviljk
# will think MakeTeXPK failed. Any other output to stdout will also lose.
echo $DESTDIR/$PKNAME
# That's it!
================================================================================
Archive-Date: Fri, 08 Sep 1995 10:36:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 8 Sep 1995 16:34:09 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509081534.QAA16377@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
CC: alanje@cogs.susx.ac.uk
Subject: Re: Installing TDS at Sussex
References: <m0sqjhH-0001iBC@csrj.crn.cogs.susx.ac.uk>
> was produce a new MakeTeXPK, which I'll attatch for those interested.
oh dear another one....
> There's no TDS directory specified for images, which is odd, since
> they have to be on the TEXINPUTS path in order for graphics.sty to
> pick them up. I ended up using texmf/images/<type>/<group>/<file>, eg
> texmf/images/epsf/sussex/ssxcrest.eps for our crest.
i personally
dont like this much. why not with your departmental style file? but
its an interesting point
> earth I'm going to duplicate all of the TDS structure, so I used files
why not? whats the problem
> like texmf/tex/latex/sussex/ssxlet.cls for our letter class.
i think there is a difference between "local", as in "university of
sussex" and "local" as in "Alans hacks". BUT if you choose "sussex"
rather than "local" you should REGISTER the name sussex so that its
unambiguous all over the world. "sussex" is a fair choice, "cs" or
"mathsdept" is not....
> : ${MFDIR=/local/texmf/fonts/source}
with a trailing /mf//, surely?
> : ${AFMDIR=/local/texmf/fonts/afm}
trailing // please!
> : ${PSFONTSMAP=/local/texmf/dvips/psfonts.map}
hmm. i have about 70 map files....
> # Got a Type 1 source, so run gsftopk.
> echo $GSFTOPK $NAME $DPI >&2
> $GSFTOPK $NAME $DPI >&2 || exit 1
you lose the choice of using ps2pk?
and, Alan, you of all people to forget to allow for 8r re-encoding????
sebastian
================================================================================
Archive-Date: Fri, 08 Sep 1995 11:30:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 8 Sep 1995 12:01:01 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509081601.AA28401@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
rather than "local" you should REGISTER the name sussex so that its
Is there anywhere to register it? We're not maintaining such a list in
the TDS doc, are we? Maybe let the local organization names fall where
they may?
================================================================================
Archive-Date: Fri, 08 Sep 1995 11:57:34 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 8 Sep 1995 18:55:54 +0200
Message-ID: <9509081655.AA05569@macbeth.uni-duesseldorf.de>
To: twg-tds@shsu.edu
Subject: Input from EuroTeX (for the record)
From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth)
Reply-To: TWG-TDS@SHSU.edu
Before I forget it, let me summarize some input I got from the 4allTeX
people during the EuroTeX meeting. During the coffee-break on Wednesday
morning I was approached by one of them (can't remember who it was),
asking me about TDS. As far as I remember their main points were the
following:
1.) They think, as a CD producer, they should be represented somehow
in the TWG-TDS group.
2.) They think the TDS standard shouldn't leave open important questions
about the location of the format files. Instead it should specify
everything, perhaps as a set of separate specifications for different
platforms, but, in their view, the only way to achieve standardization
was a concrete specification rather than just a recommendation.
3.) They weren't happy about the layout of the font tree, but I didn't find
out what they actually wanted. So far, they are centered on emTeX only,
and maybe this has to do with the fact that subdirectory searching in
emTeX isn't as fast as Eberhard Mattes would like it to be and therefore
doesn't follow the TDS draft in his distribution so far.
Personal comments about this:
1.) If they are interested, they are of course free to join our discussions,
but I forgot to point this out to them specifically. Perhaps it might
be a good idea to ask them directly unless we get some input from them
in the next time.
2.) I told them that the next version of the TDS draft might include
appendices addressing the structure of the implementation-dependent
stuff for various platforms (VMS, web2c, possibly others).
3.) I have no idea what they wanted concerning the font tree, but as
mentioned above I guess it might be related to what emTeX does or
does not.
After Joachim's presentation of the TDS draft and during the subsequent
panel session there weren't actually many questions and I was a bit
surprised that the 4allTeX people didn't raise their questions there.
Perhaps this was because the panel session was overshadowed by the
topics e-TeX, Omega and LaTeX3 so that the TDS fell in the background.
As far as I remember there weren't any serious objections, so I guess
the best way to proceed is to see that we finalize the current draft
in the near future taking into account the recent input. Taking into
account the experience how long it took to produce the last draft,
I guess shortly before Christmas might be a good target date.
That's all. I hope I haven't mis-represented the position of the
4allTeX people.
Cheers,
Ulrik.
================================================================================
Archive-Date: Fri, 08 Sep 1995 13:02:21 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0sr71L-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 8 Sep 95 18:15 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
>oh dear another one....
Indeed. Such is life in the wacky world of distributed software
development... The problem I had with Karl's (I think it was
Karl's...) was that it found the <supplier> and <source> by parsing
the filename. It seems to me much simpler to find the pfa/pfb/afm
file using find, and use that to get the supplier and source.
> > There's no TDS directory specified for images, which is odd, since
> > they have to be on the TEXINPUTS path in order for graphics.sty to
> > pick them up. I ended up using texmf/images/<type>/<group>/<file>, eg
> > texmf/images/epsf/sussex/ssxcrest.eps for our crest.
> i personally
>dont like this much. why not with your departmental style file? but
>its an interesting point
If the epsf files are put somewhere else, it saves dvips and friends
searching all of $TEXINPUTS trying to find them.
>i think there is a difference between "local", as in "university of
>sussex" and "local" as in "Alans hacks". BUT if you choose "sussex"
>rather than "local" you should REGISTER the name sussex so that its
>unambiguous all over the world. "sussex" is a fair choice, "cs" or
>"mathsdept" is not....
This registration seems bizarre to me. Register with who? Every
institution with it's own notepaper/techreports/newsletter/etc is
going to need a texmf/tex/latex/<oursite> directory, all we can do is
encourage sensible naming conventions.
> > : ${MFDIR=/local/texmf/fonts/source}
>with a trailing /mf//, surely?
That directory is passed to find, not to a kpathsea program. If there
were a kpathfind or similar, I'd use that...
> > : ${PSFONTSMAP=/local/texmf/dvips/psfonts.map}
>hmm. i have about 70 map files....
Well, I did say it was site-specific!
>you lose the choice of using ps2pk?
Ditto.
>and, Alan, you of all people to forget to allow for 8r re-encoding????
Nope, gsftopk copes with ReEncodeFont lines in the psfonts.map file.
Alan.
================================================================================
Archive-Date: Fri, 08 Sep 1995 13:18:29 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 8 Sep 1995 20:16:13 +0200
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9509081816.AA10870@regulus.dbis.uh>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
> > : ${MFDIR=/local/texmf/fonts/source}
> with a trailing /mf//, surely?
You mean 'trailing //', as source was chosen instead of mf in the TDS.
> > : ${PSFONTSMAP=/local/texmf/dvips/psfonts.map}
> hmm. i have about 70 map files....
Ai... All MakeTeXPK versions I know of (including my one) only look at
one psfonts.map file.ee if a font is a postscript one...
> > $GSFTOPK $NAME $DPI >&2 || exit 1
> you lose the choice of using ps2pk?
> and, Alan, you of all people to forget to allow for 8r re-encoding????
What do you want to imply here? gsftopk can handle 8r re-encoding.
Thomas
================================================================================
Archive-Date: Fri, 08 Sep 1995 18:00:50 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509082301.BAA17680@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Installing TDS at Sussex
To: TWG-TDS@SHSU.edu
Date: Sat, 9 Sep 1995 01:01:01 +0200 (MESZ)
Content-Type: text
Alan wrote:
>
> Indeed. Such is life in the wacky world of distributed software
> development... The problem I had with Karl's (I think it was
> Karl's...) was that it found the <supplier> and <source> by parsing
> the filename. It seems to me much simpler to find the pfa/pfb/afm
> file using find, and use that to get the supplier and source.
Why don't you use that new command included in 2.6 that uses kpathsea
to locate a file? (Can't remember it's name right now.) Then you'll
find exactly the same file as MF found.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Sat, 09 Sep 1995 03:16:25 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 9 Sep 1995 09:14:34 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509090814.JAA17646@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <199509081601.AA28401@ra.cs.umb.edu>
K. Berry writes:
> rather than "local" you should REGISTER the name sussex so that its
>
> Is there anywhere to register it? We're not maintaining such a list in
> the TDS doc, are we? Maybe let the local organization names fall where
> they may?
we dont have a register right now, but i dont think we (the TeX
community) can last much longer without one. Rich is the man who
volunteered, i think... (with Tobi Oetiker)
sebastian
================================================================================
Archive-Date: Sat, 09 Sep 1995 03:22:24 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 9 Sep 1995 09:20:38 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509090820.JAA17658@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <9509081816.AA10870@regulus.dbis.uh>
> Ai... All MakeTeXPK versions I know of (including my one) only look at
> one psfonts.map file.ee if a font is a postscript one...
mine doesnt! it searches all of them :-}
> > > $GSFTOPK $NAME $DPI >&2 || exit 1
> > you lose the choice of using ps2pk?
> > and, Alan, you of all people to forget to allow for 8r re-encoding????
>
> What do you want to imply here? gsftopk can handle 8r re-encoding.
>
my mistake. sorry!
sebastian
================================================================================
Archive-Date: Sat, 09 Sep 1995 11:32:33 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 9 Sep 1995 10:01:22 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509091401.AA08318@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Input from EuroTeX (for the record)
2.) They think the TDS standard shouldn't leave open important questions
about the location of the format files. Instead it should specify
What are these open important questions?
================================================================================
Archive-Date: Sat, 09 Sep 1995 15:40:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 9 Sep 1995 16:38:02 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509092038.AA11188@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
There's no TDS directory specified for images, which is odd, since
they have to be on the TEXINPUTS path in order for graphics.sty to
pick them up. I ended up using texmf/images/<type>/<group>/<file>, eg
texmf/images/epsf/sussex/ssxcrest.eps for our crest.
Because, as you say, images have to be found by TEXINPUTS for the TeX
macros to find the bounding boxes, I think they belong under texmf/tex//,
in whatever directory is appropriate (with package, localism, or
whatever), instead of in a new top-level directory. That just
complicates the TEXINPUTS path.
The main point where I disagreed with TDS was the specification that
local files should be put outside the heirachy. There's no way on
What about if we reserved the name ``local'' at every level for people
to put stuff into if they want? (Similar to `misc' now.) I'm not sure if
this is better or worse than the proliferation of ``sussex'', ``umb'',
``elsevier'', etc.
I guess we had this discussion before, but I'm not sure why we settled
on a separate tree. I think we must bow to reality -- texadmins are not
going to create separate texmf trees and double the size of their paths
just for the sake of a couple of files. (They might with a
reasonably-fully-populated tree, but I suspect that case is rare to
nonexistent.)
Thus, perhaps we should support/recommend both.
Thoughts?
================================================================================
Archive-Date: Mon, 11 Sep 1995 05:06:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 11 Sep 1995 11:02:37 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509111002.LAA19795@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <199509092038.AA11188@terminus.cs.umb.edu>
> What about if we reserved the name ``local'' at every level for people
> to put stuff into if they want? (Similar to `misc' now.) I'm not sure if
> this is better or worse than the proliferation of ``sussex'', ``umb'',
> ``elsevier'', etc.
my memory is that we had done this, i was obviously wrong. but i think
it should go in - "local" is reserved, and its contents undefined.
that doesnt mean that "elsevier" and "umb" shouldnt register their
names, tho, imho
sebastian
================================================================================
Archive-Date: Mon, 11 Sep 1995 06:39:51 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0ss75s-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 11 Sep 95 12:32 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
>my memory is that we had done this, i was obviously wrong. but i think
>it should go in - "local" is reserved, and its contents undefined.
Using "sussex", etc. is simpler IMHO since it means that admins can
have more than one local directory, eg on my Mac I have a "sussex"
folder and an "asaj" folder.
>that doesnt mean that "elsevier" and "umb" shouldnt register their
>names, tho, imho
Do you really want me to register "asaj" as the name of the directory
that occurs only on my machine?
Alan
================================================================================
Archive-Date: Mon, 11 Sep 1995 06:53:22 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 11 Sep 95 12:31:47 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9509111131.AA25488@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
my memory is that we had done this, i was obviously wrong. but i think
it should go in - "local" is reserved, and its contents undefined.
that doesnt mean that "elsevier" and "umb" shouldnt register their
names, tho, imho
I dont really mind mind `local' but last time this came up (now where
is that archive of this list:-) I thought the idea was to recommend
named direcories `elsevier' etc (or totally separate tds tree) so that
tds trees from different sites may be more easily merged.
I think the idea of `registering' every such name is a non-starter.
Every installation of TeX that has *any* local files would need to
register a unique name. So here (probably typical?) we would need to
register tds names for virtually every science department + the
medical school + the central computer centre + quite a few arts
departments. These are all `autonomous' TeX installations administered
by individuals in each department. Some of these installations
probably just copy the central computer centre set up, but I'd guess
Manchester would need a dozen or so names. And that is just one of
three universities in one town in a small European island. A global
register would get big very quickly for no obvious gain?
David
================================================================================
Archive-Date: Mon, 11 Sep 1995 07:36:42 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 11 Sep 1995 13:32:49 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509111232.NAA20666@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <9509111131.AA25488@r8h.cs.man.ac.uk>
> Manchester would need a dozen or so names. And that is just one of
> three universities in one town in a small European island. A global
> register would get big very quickly for no obvious gain?
>
spoilsport....
we obviously have to canonize "local" anyway, and make sure it is
omitted from merges
sebastian
================================================================================
Archive-Date: Mon, 11 Sep 1995 07:39:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 11 Sep 1995 13:35:02 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509111235.NAA20689@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <m0ss75s-0001iBC@csrj.crn.cogs.susx.ac.uk>
> Do you really want me to register "asaj" as the name of the directory
> that occurs only on my machine?
>
if you insist it be in the main TDS tree, rather than your local tree,
yes.
one solution is for implementors to make it easy to say that
$TEXMF/tex/latex//
means
{/usr/local/tex,/usr/home/alan/tex}/tex/latex/latex
as it were, so that maintaining a local tree is not too much trouble
maybe someone can see how to express this in kpathsea? can it be done?
sebastian
================================================================================
Archive-Date: Mon, 11 Sep 1995 07:42:30 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0ss87x-0001iRC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 11 Sep 95 13:38 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
>Because, as you say, images have to be found by TEXINPUTS for the TeX
>macros to find the bounding boxes, I think they belong under texmf/tex//,
>in whatever directory is appropriate (with package, localism, or
>whatever), instead of in a new top-level directory. That just
>complicates the TEXINPUTS path.
But that requires having the dvi drivers search all of TEXINPUTS for
figures, rather than a (much smaller) images directory.
Alan.
================================================================================
Archive-Date: Tue, 12 Sep 1995 08:17:13 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0ssV7J-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 12 Sep 95 14:11 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
>if you insist it be in the main TDS tree, rather than your local tree,
>yes.
What does `my local tree' mean on my Mac? I don't see why macros I've
written should belong on completely different places on my Mac
depending on whether or not I happened to distribute them to CTAN.
Alan.
================================================================================
Archive-Date: Tue, 12 Sep 1995 08:24:22 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0ssVFQ-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 12 Sep 95 14:19 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
>Why don't you use that new command included in 2.6 that uses kpathsea
>to locate a file? (Can't remember it's name right now.) Then you'll
>find exactly the same file as MF found.
Karl pointed out kpsewhich to me, which makes life much easier. The
algorithm I now use is (in pidgin sh):
FONTHOME = `kpsewhich $NAME.mf || kpsewhich $NAME.tfm`
... tear $FONTHOME apart to get the appropriate bits and pieces ...
This will die horribly if anyone installs their own mf or type1 fonts,
but it's not obvious what to do in that situation. But I doubt this
is very likely here...
Alan.
================================================================================
Archive-Date: Tue, 12 Sep 1995 11:33:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 12 Sep 1995 11:19:59 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509121519.AA19818@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
alan> But that requires having the dvi drivers search all of
TEXINPUTS for figures, rather than a (much smaller) images directory.
The whole thesis of the TDS is that searches are cheap. If this is not
true, things are hopeless anyway. What good does it do for the DVI
driver to search a small directory if TeX has to search a big one anyway?
Since TeX has to find the image files to get the bounding boxes, I
think they should be under tex//. I don't see the advantage to breaking
them out.
one solution is for implementors to make it easy to say that
$TEXMF/tex/latex//
means
{/usr/local/tex,/usr/home/alan/tex}/tex/latex/latex
as it were, so that maintaining a local tree is not too much trouble
maybe someone can see how to express this in kpathsea? can it be done?
You'd have to duplicate all the paths with two different TEXMF's.
There've been some discussions of directly supporting multiple trees,
but I have yet to be convinced it's worthwhile.
Anyway, regardless of whatever I do or do not implement, it seems a moot
point, since certainly the many other implementors out there will be
uninterested in something so hairy -- after all, simple caching
strategies were voted down, and significant compromises made because of
that, as we all know. Multiple TEXMF's is a lot more painful than
caching, believe me.
Are there any real local installations out there with two complete texmf
trees?
carlisle> I think the idea of `registering' every such name is a
non-starter.
I agree. I don't see the win here, Sebastian. Explain?
================================================================================
Archive-Date: Tue, 12 Sep 1995 11:55:43 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0ssYXZ-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Tue, 12 Sep 95 17:50 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
>The whole thesis of the TDS is that searches are cheap. If this is not
>true, things are hopeless anyway. What good does it do for the DVI
>driver to search a small directory if TeX has to search a big one anyway?
OK, so the pragmatic argument doesn't work... I guess I just find it
odd classifying images as TeX sources, just because TeX happens to be
one of the programs which reads them.
But I guess I don't particularly care whether the files are
texmf/images/<type>/<bundle> or texmf/tex/images/<type>/<bundle> or
even texmf/tex/generic/images/<type>. But I think we should say
something about where they should go.
>There've been some discussions of directly supporting multiple trees,
>but I have yet to be convinced it's worthwhile.
I definitely agree with this!
Alan.
================================================================================
Archive-Date: Tue, 12 Sep 1995 19:12:45 CDT
Sender: owner-twg-tds@SHSU.edu
Return-Path: <mackay>
Date: Tue, 12 Sep 1995 17:10:27 -0700
From: mackay@cs.washington.edu (Pierre MacKay)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509130010.RAA24690@june.cs.washington.edu>
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
Karl pointed out kpsewhich to me, which makes life much easier. The
algorithm I now use is (in pidgin sh):
FONTHOME = `kpsewhich $NAME.mf || kpsewhich $NAME.tfm`
... tear $FONTHOME apart to get the appropriate bits and pieces ...
This will die horribly if anyone installs their own mf or type1 fonts,
but it's not obvious what to do in that situation. But I doubt this
is very likely here...
What's wrong with:
% Ditto for MF.
MFINPUTS = .:$TEXMF/mf//:$PRIVATE/fonts//src//:$TEXMF/fonts//src//
% Device-independent font metric files.
VFFONTS = .:$PRIVATE/fonts//vf:$TEXMF/fonts//vf
TFMFONTS = .:$PRIVATE/fonts//tfm:$TEXMF/fonts//tfm
% Just an abbreviation.
pkdir = $TEXMF/fonts//pk
privatepkdir = $TEXMF/private/fonts//pk
and so on? It works, and neatly separates the publishable
glyphs from the commercial ones.
(This is a nasty old supplier-first organization, but it's
my own system.)
%=======================================================================%
| N O T I C E |
| Please note the changes in address and telephone number below. |
| There is no Northwest Computing Support Center any longer. |
| Until further notice, I shall be continuing to provide tape |
| distributions and whatever other services I can. |
| |
%=======================================================================%
Email concerned with UnixTeX distribution software may be sent
To: mackay@cs.washington.edu Pierre A. MacKay
Smail: Department of Classics Emeritus Druid for
Denny Hall, Mail Stop DH-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-2268 (Message recorder)
================================================================================
Archive-Date: Wed, 13 Sep 1995 06:02:14 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 13 Sep 1995 11:58:11 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509131058.LAA03986@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <199509121519.AA19818@terminus.cs.umb.edu>
> Since TeX has to find the image files to get the bounding boxes, I
> think they should be under tex//. I don't see the advantage to breaking
> them out.
i'm with Karl on this. though i think Alan has a point. we should
mention it in the TDS, as he says
>
> You'd have to duplicate all the paths with two different TEXMF's.
>
> There've been some discussions of directly supporting multiple trees,
> but I have yet to be convinced it's worthwhile.
what do i do when i get a Unix plug-n-play CD out? (which is another
matter to bring up here). I copy it all to some single untouchable
read-only server for a whole group of projects, to provide a base. each
project then has its own packages, fonts, needs etc, and should/could
run a parallel tree of their private stuff, no?
> that, as we all know. Multiple TEXMF's is a lot more painful than
> caching, believe me.
if its not obvious, then i have no problem with complicated texmf.cnf
files in practice
> Are there any real local installations out there with two complete texmf
> trees?
i could imagine starting one
> carlisle> I think the idea of `registering' every such name is a
> non-starter.
>
> I agree. I don't see the win here, Sebastian. Explain?
i just want to ensure that if you see tex/latex/umb, it means the same
thing to you and me both.
sebastian
================================================================================
Archive-Date: Wed, 13 Sep 1995 12:23:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 13 Sep 1995 11:06:44 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509131506.AA09595@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
odd classifying images as TeX sources, just because TeX happens to be
one of the programs which reads them.
It is weird, I agree. But I don't see any practical value in
complicating the TEXINPUTS path.
But I guess I don't particularly care whether the files are
texmf/images/<type>/<bundle> or texmf/tex/images/<type>/<bundle> or
even texmf/tex/generic/images/<type>.
I think I like that last, for images that aren't part of any package.
(I don't know if there are any packages that include .eps's, for that matter.)
But what are <type> and <bundle>?
But I think we should say
something about where they should go.
I agree.
> Are there any real local installations out there with two complete texmf
> trees?
i could imagine starting one
I can imagine lots of things :-). Even with a readonly tree off a CD, I
suspect some people will prefer to make individual local directories
with additional stuff, rather than a complete separate tree. No one will
prefer any one thing. I don't know. Let's work on getting the CD out :-).
i just want to ensure that if you see tex/latex/umb, it means the same
thing to you and me both.
At the moment I export a `umb' package to the world, that's the moment
at which it should be registered, using whatever mechanisms we have for
registering packages in general. (At the moment, that mechanism being
``existence on CTAN'' :-). How's that?
================================================================================
Archive-Date: Wed, 13 Sep 1995 16:59:10 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0ssvcR-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Wed, 13 Sep 95 18:29 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
>I think I like that last, for images that aren't part of any package.
>(I don't know if there are any packages that include .eps's, for that matter.)
The `canonical example' is probably local images such as university
crests. I guess these could live in (eg)
texmf/tex/latex/sussex/ssxcrest.eps, but this does mean that if I ever
wrote plain macros for sussex letters (OK, pretty unlikely!) then I'd
be in trouble.
Alan
================================================================================
Archive-Date: Thu, 14 Sep 1995 01:02:15 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 13 Sep 95 23:00:34 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9509140600.AA11363@cfcl.com>
To: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: I'm back (I think :-)...
I am still quite interested in the idea of a Registry for TDS names, but
I never got much (read, ANY) reaction to my specific proposals from the
TeX wizards out there. SPQR has asked me to jump back into the fray,
however, so I will.
As I see it, there are two problems a Registry can and should solve:
1. It should document TeX-related packages in sufficient detail
that a prospective user can find out (a) what the package is
good for, (b) where it can be obtained, (c) who maintains it,
et copious cetera.
This problem has been addressed in at least three organized ways:
a. The PTF "0.doc" files and HTML pages. (The latter may be
seen on www.ptf.com, and will appear on the next issue of
"Prime Time TeXcetera".)
This format is not optimized for machine-readability, but
we might be able to translate it into another which is...
b. The DRAFT specification of the IETF IAFA working group,
which defines a format for indexing information found on
Internet FTP archives. This is used by the ALIWEB server.
c. The "LSM" files used by the Linux community.
The latter two are essentially equivalent, for our purposes.
The IAFA may be more tightly specified; the LSM is certainly
more widely used. I have no strong preference in the matter.
2. It should unambiguously define the portion of the TDS name
space occupied by the package.
My initial notions (see my earlier postings) started with the
idea of specifying an explicit set of directory paths. I also
suggested that some form of wild-carding (regular expressions)
could be used to shorten the description. Finally, I said that
it might be possible to give (a) a name and (b) a package "type"
and let default rules establish which directories would be used.
In retrospect, I think I prefer a merger of these three ideas.
The package author defines the type (and paths) by listing the
top-level directories across which the name is claimed. (The
doc directories corresponding to the mainline directories would
also be reserved.)
I think this has the advantages of safety, simplicity, and
generality. If I lay claim to fonts/morin/martian/, I
should reserve any directories my font could reasonably use.
Here is a simplistic set of examples:
path example
==== =======
/ dvips, web2c
bibtex/bib/ ?
bibtex/bst/ ?
fonts/ public/cm
metafont/ plain
metapost/ plain
tex/format/ plain
tex/generic/hyphen/ ?
tex/generic/misc/ texnames
tex/generic/package/ babel
I suspect that a TeXnician could boil these down further. It might
be, for instance, that "plain" should be unique within "/". Let me
know about stuff like this, please... Also, would someone who has
built a reasonable-size TDS tree be willing to look into it and tell
us how much chaos this scheme would cause?
Yours, Rich
rdm@cfcl.com
================================================================================
Archive-Date: Thu, 14 Sep 1995 03:04:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Sep 1995 09:00:50 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509140800.JAA18625@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <199509131506.AA09595@ra.cs.umb.edu>
> I think I like that last, for images that aren't part of any package.
> (I don't know if there are any packages that include .eps's, for that matter.)
any "local" one will, for eg a letter head. my local elsevier setup
has 3 or 4 logos as EPS files
> But what are <type> and <bundle>?
other image types? tiff?
> But I think we should say
> registering packages in general. (At the moment, that mechanism being
> ``existence on CTAN'' :-). How's that?
a fair practical criterion, i agree
s
================================================================================
Archive-Date: Thu, 14 Sep 1995 09:41:39 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Sep 1995 10:40:11 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509141440.AA09363@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: rdm@cfcl.com
Subject: Re: I'm back (I think :-)...
generality. If I lay claim to fonts/morin/martian/, I
Except supplier-first lost the battle, so it has to be fonts/*/morin/martian
:-(. Also, if you're the first Martian font designer, I think it'd
reasonable to put it in fonts/*/public/martian. If it was public, of course.
be, for instance, that "plain" should be unique within "/". Let me
I don't understand. There is no texmf/plain, just
texmf/{tex,metafont,metapost}/plain. The everything-in-a-package name
proposal was rejected, tooo ...
I doubt anyone has strong feelings for any particular format for the
header info. I sure don't. Any automatic generation from what we've got
now will sure be a win ...
================================================================================
Archive-Date: Thu, 14 Sep 1995 10:57:56 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Sep 95 08:51:59 PDT
From: rdm@cfcl.com (Rich Morin)
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9509141551.AA11884@cfcl.com>
To: TWG-TDS@SHSU.edu, rdm@cfcl.com
Subject: TDS Registry
Karl notes that fonts/morin/martian/ is incorrect, suggesting
fonts/*/morin/martian/ instead. Because there are two intervening
directories, this should really be fonts/*/*/morin/martian/, but I
imagine that I would be better served to claim fonts/*/*/morin/ as
a whole, then create subsidiary entries as desired. (There is no
purpose served by allowing two font developers to share the same
"supplier" name, and a supplier *should* be able to keep its own
name space clean.)
My Martian fonts could certainly go in as fonts/*/*/public/martian/,
unless I thought I was likely to have competition down the canal (:-).
My suggestion that "plain" be unique within "/" derives from the
observation that "plain" shows up in several sub-trees. I don't
think, for instance, that it would be a Good Thing for anyone other
than Dr. Knuth to develop a new package (font, etc.) named "plain".
On the other hand, if a developer has several independent packages
named "foo", it *might* be appropriate for each one to have its own
registration, if only to make it clear that they are unrelated items.
My only reservations on the header info stem from wanting to balance
the need for information with keeping the effort (and fascism) to a
minimum. We should probably make a template available, with flags to
show which fields are required, etc.
Getting on to mechanization, my current notion is that we need
a multi-stage procedure:
1. submission
2. sanity check
3. public comment
4. acceptance
After looking in CTAN/tex-archive/tds/registry (or an equivalent WWW
server), I would submit a filled-in template. This would be checked
for obvious errors and conflicts, then installed as a "prospective"
registration. If no conflict arose within (say) 90 days, it would be
accepted as a full registration.
PTF would certainly be willing to assist in any effort to generate
registration information from our (or others') documentation files.
It may be, however, that the public comment period should be longer
for this sort of "mass registration", as it could take longer for any
problems to be spotted.
-r
================================================================================
Archive-Date: Thu, 14 Sep 1995 11:32:17 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 14 Sep 1995 10:47:10 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509141447.AA09381@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
texmf/tex/latex/sussex/ssxcrest.eps, but this does mean that if I ever
As you suggested, texmf/tex/generic/images/sussex/ssxcrest.eps?
(or `local' instead of `sussex', but that's another discussion :-)
================================================================================
Archive-Date: Thu, 14 Sep 1995 12:03:23 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509141701.TAA17738@spice.iti.informatik.th-darmstadt.de>
Subject: Re: I'm back (I think :-)...
To: TWG-TDS@SHSU.edu
Date: Thu, 14 Sep 1995 19:01:26 +0200 (MESZ)
Content-Type: text
Rich wrote:
>
> I am still quite interested in the idea of a Registry for TDS names, but
> I never got much (read, ANY) reaction to my specific proposals from the
> TeX wizards out there.
Oops, I have forgotten to forward to this list a discussion I had on
comp.text.tex. It started with the question of easier TeX
installation, and I presented the TDSR idea as a means to get
automatic installation. I append my old article below, FYI.
For the record: 5 people reacted. 3 thought that the whole hassle is
unnecessary anyhow, and 2 agreed to my proposal. Neither the amount
nor the tendency of this reaction encouraged my to follow this path
further.
Executive summary: Compared to Rich's proposal, I would prefer a more
high-level description, where the directory information may be deduced
from automatically and where the information doesn't need updates more
often.
Cheers
Joachim
---------------- included article follows:
From: schrod@iti.informatik.th-darmstadt.de (Joachim Schrod)
Subject: Re: Installing LaTeX2e: A Suggestion
Newsgroups: comp.text.tex
Distribution: world
Followup-To:
References: <jhh.804928700@news.cwi.nl> <3tdn05$kl2@hippo.shef.ac.uk> <3te83q$dcm@news.rwth-aachen.de>
Organization: TH Darmstadt, FG Systemprogrammierung
Keywords:
In article <3te83q$dcm@news.rwth-aachen.de>, dak@tabaqui.informatik.rwth-aachen.de (David Kastrup) writes:
>
> Now, the TDS standard committee is cooking a file structure up for
> all of us, suggesting what should go where. It would probably be not
> the worst of ideas to include a file
> tdsinfo
> in every distribution which specifies where this distribution wants
> to have all its files distributed to.
Very good idea. (A set of such files makes up the yet-nebulous idea
of a TDS registry that is mentioned in appendix A.2.)
> Somewhat along:
> *.ins: &latex
> *.drv: &latex
> wusel.dtx: &latex
> *.cls: tex/latex2e/packages/fulcro
> [...]
Hmm, you could just name the directories relativ to the TDS root
texmf. [footnotes *1 *2]
But let me bring up a similar, but different possibility: a more
high-level description. I.e.:
----------------
Bundle: foo % `Bundle' is an alias for field name `Package'
Category: latex % from a predefined set of categories
Run-Files: *.sty *.fd *.fmt % files needed at run time, to use it
Doc-Files: *.dvi foouser.tex README % files with _user_ documentation
Font-Supplier: public % see TDS, section 4
Font-Typeface: drake % logo of Sir Francis Drake Society :-)
----------------
This information is enough to install a distribution automatically in
a TDS tree. Of course, if some field is not appropriate, it should not
be mentioned. One can establish known abbreviations, too. E.g., the
`Run-Files' field could only mention $latex (or @latex) and this will
automagically expand to a list of known-extensions-from-the-LaTeX-world.
IMO this description is better as the file based one, as it not only
carries information for the installation program, but also information
for the human that wants to have an overview about the contents of that
distribution.
Of course, support for the interpretation of such a description is up
to the respective TeX sub-communities (the Unix, DOS, VMS, etc.,
camps).
I would like to get feedback for that idea, please post or send
comments. There has been discussions about a proposed minimum standard
for supported LaTeX bundles. The current result of this discussion is
available as ftp://ftp.th-darmstadt.de/pub/tex/latex/bundle-dist.tex.gz .
I'm currently working on Perl scripts that will help to check incoming
CTAN submissions for compliance with these guidelines and to ask
authors for improvements in their next release... (They have been
written already, I'm in the test phase.)
These guidelines already demand a CATALOG file with information about
the bundle. We could add easily fields like those outlined above.
Even make them mandatory?!
The CATALOG file can be an input for the planned TeX Package Registry,
discussed recently on this newsgroup.
So -- if any authors of packages are still reading: Would you be
willing to add such a file? Please send me mail or post. If enough of
you authors -- yes, We Want You :-) -- are willing to add such a file,
I would fix a proposal for a format.
A Perl script for the installation job can be written very quickly.
As an aside note for the non-Unix user community: Perl is
available for many other platforms. If you don't have it, please
don't complain about Unix-centrism. Add _your_ volunteer contribution
to the TeX community and write an installation system that interprets
a file like above. Use a system that is well known and wide spread in
_your_ user community, be it REXX or Visual Basic or whatever.
OK, one last remark:
> Note that this looks suspiciously similar
> to make file syntax [...]
> So one could probably even use plain old makefiles, and not many
> people suffer harm from that.
I don't think that's possible. To write portable Makefiles is a pain
in the a**, even if you generate them with sed (aka GNU autoconf) or
cpp (aka Imake). You won't use the up-to-date-check feature of make
anyhow. And in the actions you'll need commands that are the same on
every platform: on Unix, DOS, VMS, etc. That some make is available
there as well doesn't make the Makefile portable. I'll would enjoy to
get proved wrong -- but I fear that's a bite too big to swallow.
Cheers, -- and send in your comments to these remarks
Joachim
----------------------------------------
Footnotes:
[*1] As there has been already the reproach of Unix centrism in this
thread, let me please note that the notion of `a/b/c' for a file in a
directory hierarchy is not a Unix-only notion. (It certainly has its
roots there.) It's the notion used in the ISO/IEEE standards for
Portable Applications. Of particular relevance is the standard ISO
9945-1 `System Application Program Interfaces' (aka IEEE 1003.1).
That standard is nowadays available on many platforms, including DOS
& VMS. (It's even there on MVS.)
[*2] Some more comments on the content of the proposal, maybe I
didn't understand it completely:
> *.ins: &latex
> *.drv: &latex
> wusel.dtx: &latex
Hmm, what does `&latex' mean here?
These files should be available in
source/latex/<bundle>/
where <bundle> is the name of the distribution unit. (I.e., the
subdirectory from contrib/{supported,other}/) and the files should
just stay there.)
> %what syntax for makeindex files?
*.ist: makeindex
> *.cls: tex/latex2e/packages/fulcro
*.cls: tex/latex/fulcro % no packages/ subdir :-)
> *.dvi:
*.dvi: doc/latex/<bundle>/ % maybe doc/latex/misc/
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 15 Sep 1995 05:56:19 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0stYNE-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Fri, 15 Sep 95 11:52 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
>As you suggested, texmf/tex/generic/images/sussex/ssxcrest.eps?
Or texmf/tex/generic/images/epsf/ssxcrest.eps?
Alan.
================================================================================
Archive-Date: Fri, 15 Sep 1995 06:11:24 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509151109.NAA19333@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Installing TDS at Sussex
To: TWG-TDS@SHSU.edu
Date: Fri, 15 Sep 1995 13:09:44 +0200 (MESZ)
Content-Type: text
You wrote:
>
> >As you suggested, texmf/tex/generic/images/sussex/ssxcrest.eps?
>
> Or texmf/tex/generic/images/epsf/ssxcrest.eps?
For the record: I'm against both.
TDS says:
texmf/tex/<format>/<package>/<file>
I'd like to stick with that. We have already enough open problems, we
shouldn't add another one.
I.e., I've nothing against storing EPS files in <format>==generic.
But I'm against the introduction of yet another directory level.
What's the problem with
texmf/tex/generic/{sussex,local,misc}/ssxcrest.eps
Choose the name of the <package> level as you like, that's not really
the problem. IMHO it's more important to warn people against the usage
of names like thesis.sty. File names like ssxcrest.eps are OK, the
probability to appear in several places is minimal.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Fri, 15 Sep 1995 06:13:55 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 15 Sep 1995 12:09:22 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509151109.MAA26263@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <m0stYNE-0001iBC@csrj.crn.cogs.susx.ac.uk>
Alan Jeffrey writes:
> >As you suggested, texmf/tex/generic/images/sussex/ssxcrest.eps?
>
> Or texmf/tex/generic/images/epsf/ssxcrest.eps?
>
> Alan.
>
no, texmf/tex/generic/images/epsf/sussex/ssxcrest.eps, or else you
can't identify it easily. or images/epsf/misc.
but you are screwing the convention of tex/<format>/<package>/<files>
which has come up before. dont we agree that we dont permit multiple
levels there?
s
================================================================================
Archive-Date: Fri, 15 Sep 1995 09:46:49 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 15 Sep 1995 10:45:32 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509151445.AA20386@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
> Or texmf/tex/generic/images/epsf/ssxcrest.eps?
For the record: I'm against both.
TDS says:
texmf/tex/<format>/<package>/<file>
Alan's point (as I understand it :-) was that a .epsf file could be used
by either tex or latex or whatever format, so it's a bit ugly to just
pick one arbitrarily.
How about
texmf/tex/epsf/sussex/ssxcrest.eps
???
(Where's the win in merging all conceivable image formats under images/?)
================================================================================
Archive-Date: Fri, 15 Sep 1995 10:18:47 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 15 Sep 95 16:16:44 BST
From: David Carlisle <carlisle@cs.man.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <9509151516.AA08852@r8h.cs.man.ac.uk>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
Karl> texmf/tex/epsf/sussex/ssxcrest.eps
This looks the best of the bunch so far.
Of course here the local eps logo is shared between letter templates
for LaTeX and Framemaker. I doubt whether Framemaker users would
manage that path (they all think TeX is some kind of plague:-)
but I expect a few symbolic links will come to the rescue.
David
================================================================================
Archive-Date: Fri, 15 Sep 1995 16:10:19 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Fri, 15 Sep 1995 16:23:16 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509151523.QAA08028@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: Installing TDS at Sussex
References: <9509151516.AA08852@r8h.cs.man.ac.uk>
David Carlisle writes:
>
>
> Karl> texmf/tex/epsf/sussex/ssxcrest.eps
>
> This looks the best of the bunch so far.
not
texmf/tex/images/sussex/ssxcrest.eps
?
> Of course here the local eps logo is shared between letter templates
> for LaTeX and Framemaker. I doubt whether Framemaker users would
> manage that path (they all think TeX is some kind of plague:-)
you work with Framemaker? you need care in the tex community
s
================================================================================
Archive-Date: Sun, 17 Sep 1995 00:55:25 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0stxQH-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Sat, 16 Sep 95 14:36 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu, TWG-TDS@SHSU.edu, TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
>What's wrong with:
>% Ditto for MF.
>MFINPUTS = .:$TEXMF/mf//:$PRIVATE/fonts//src//:$TEXMF/fonts//src//
This works if the users are well behaved and put their fonts where I
tell them to. As it happens, at this site, I doubt if anyone will
ever install a font other than me, so I don't think it's a worry.
This isn't necessarily true the world over though...
Alan.
================================================================================
Archive-Date: Sun, 17 Sep 1995 07:32:52 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 16 Sep 1995 12:07:14 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509161607.AA05290@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Installing TDS at Sussex
not
texmf/tex/images/sussex/ssxcrest.eps
Since drivers are likely to support multiple image file types, this
seems cleaner to me. The file extension should serve sufficiently to
distinguish so a .eps file doesn't get read when the driver is looking
for a .pict. Or whatever.
================================================================================
Archive-Date: Sun, 17 Sep 1995 14:00:50 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509171859.UAA14984@spock.iti.informatik.th-darmstadt.de>
Subject: Open Problems
To: twg-tds@shsu.edu (TUG WG TeX Directory Structures)
Date: Sun, 17 Sep 1995 20:59:13 +0200 (MESZ)
Content-Type: text
At EuroTeX I made an error -- I agreed to collect the open problems
that have been mentioned on this list since we distributed the draft.
IMO, many of the stuff are not really problems, it's just that
somebody must sit down and must write it up. ;-)
I'm loosing my job in two weeks (and have no new one yet), so don't
expect much engagement from me in formulation issues.
Cheers,
Joachim
---------------- included: open-problems.txt:
-- One must not use texmf/tex// as search path, due to duplicate
files. TEXINPUTS must be set for each format anew. (There may be
reasonable defaults, but eventually that's the bottom line.)
[Paul Vojta]
-- PK files not generated by MF go in
fonts/pk/modeless/<utility>/dpi<dpi>/<font>.pk
[Joachim & Karl]
-- Where are binaries placed?
o Non-Unix folks don't like bin/<platform>/.
o Distribution of binaries over all kind of directories is not
sensible. Placing binaries in TeX distribution dirs (as
proposed by Christian Spieler) covers only a small part of the
problem, that of the distributor -- where shall a TeX admin
place the binaries [s]he has made locally?
IMO, we should discard that issue and mention explicitely that
we could not reach a consensus on that topic. We should
mention that one needs platform-specific directories very
often.
[Christian, Pierre, Karl, sebastian, Joachim]
-- It must be made more explicit that format, base, & pool files are
placed in the <TeX implementation> tree. It's in the draft, but
this is the most FAQ, the wording must therefore be improved.
Perhaps one might also need to add a rationale (a) why it's
there and (b) why we don't specify _where_ it is placed
there. [(a) since these files are inherently implementation-
dependend; (b) since we cannot enforce it on developers, we
would structure _their_ area.] We should made explicit that
we encourage developers/distributors to tell us where their
FMT files will be placed, and should add that information in
an appendix.
[tons of people]
-- An appendix should be added that outlines known structures of <TeX
implementation> trees. It must be made explicit that this
structure is for a specific version, is not fixed, and may change
in the next version; it's just for informational purposes (to see
what `others' have done).
Most questions concerned the implementation-dependent area.
People want to know something about this.
[Christian, Pierre, Karl, Thomas]
-- TDS Registry -- what do we do with it?
I have to admit I didn't understood Rich's last proposal (item
2 of his mail from 13 Sep 95). I don't know how software shall
process it to check the tree automatically for conformance, or
do installation. And for me, that's the bottom line -- a
registry that does not provide informations to handle these
tasks is not my beef.
[Rich, Joachim, sebastian; -- Tobi Oetger [sp?]?!]
-- Reserve package name local/, FWIW.
I'm not convinced that it will really help, but it won't
introduce problems either; so we should just add it.
[Alan, Karl, sebastian]
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 18 Sep 1995 03:10:20 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0sugqg-0003DSC@gauss>
Date: Mon, 18 Sep 95 10:07 EDT
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: Open Problems
> -- One must not use texmf/tex// as search path, due to duplicate
> files. TEXINPUTS must be set for each format anew. (There may be
> reasonable defaults, but eventually that's the bottom line.)
> [Paul Vojta]
I do not understand what the problem is. Or, are there systems where
setting up different search paths are difficult? Or, is the problem
that this is not yet properly explained in the current draft?
> -- PK files not generated by MF go in
> fonts/pk/modeless/<utility>/dpi<dpi>/<font>.pk
> [Joachim & Karl]
Hm... No supplier/typeface part? Another thing: I do not like that
the files of the same type (e.g. .pk files) are stored at different
directory levels. If you compare
fonts/pk/cx/public/cm/dpi300/cmr10.pk # 6 dir. levels
with
fonts/pk/modeless/gsftopk/dpi300/ptmr8r.pk # 5 dir. levels
fonts/pk/modeless/gsftopk/adobe/times/dpi300/ptmr8r.pk # 7 dir. levels
then the modeless are always off by one...
I do not like the extra modeless directory...
> -- Where are binaries placed?
> o Non-Unix folks don't like bin/<platform>/.
And UNIX folks do not like fonts/type ... :-) In my opinion, binaries
info pages and manpages should be keep out of the draft. Maybe a
recommendation where to put them, but it should be clear that these
could be outside the texmf tree, too.
> -- It must be made more explicit that format, base, & pool files are
> placed in the <TeX implementation> tree. It's in the draft, but
> this is the most FAQ, the wording must therefore be improved.
I absolutely agree..
> -- An appendix should be added that outlines known structures of <TeX
> implementation> trees. It must be made explicit that this
> structure is for a specific version, is not fixed, and may change
> in the next version; it's just for informational purposes (to see
> what `others' have done).
Yes, I like that, too.
Thomas
================================================================================
Archive-Date: Mon, 18 Sep 1995 03:52:09 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 18 Sep 1995 10:50:56 +0100
From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE
Reply-To: TWG-TDS@SHSU.edu
Subject: Feeling uncomfortable with designation `public'
To: TWG-TDS@SHSU.edu
Message-ID: <01HVF2TFTXDE9PLVJB@MZDMZA.ZDV.UNI-MAINZ.DE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
I feel more and more uncomfortable with the designation `public' in the
font tree. I think, all ``supported'' fonts should be sorted under their
supporter.
The reasons are:
a) `public' is easily mistaken for `public domain' by the general public,
allthough almost all font currently sorted under `public' aren't.
b) There is ongoing talk (e.g. on comp.fonts) which wants to equate
public with low quality. Of course, the originators of that talk have
commercial interest in this perception, however the contributors of
free font probably don't want to find their work in a directory named `low
quality' in public perception.
c) For supported fonts, the authors accept bug reports (even if they may
wait 3 years before taking them from their stack). So why not giving the
athors credit in the directory tree?
d) Even the font donated by their founderies to the X consortium (and are
therefore more public than many `public' METAFONTs) are listed in the
sample tree under the name of the foundery. So there's unequal treatment
of `public' fonts.
For me (as a font author), b) is most serious.
--J"org Knappen
================================================================================
Archive-Date: Mon, 18 Sep 1995 06:57:18 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0suelF-0001iSC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 18 Sep 95 12:53 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Feeling uncomfortable with designation `public'
>I feel more and more uncomfortable with the designation `public' in the
>font tree. I think, all ``supported'' fonts should be sorted under their
>supporter.
Agreed. I don't see why B&H should be treated differently from DEK,
just because they make a profit from Lucida.
Perhaps Damian, Jeremy and I should form our own font foundry so we
can be included in TDS...
Alan.
================================================================================
Archive-Date: Mon, 18 Sep 1995 07:04:05 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509181201.OAA18248@spock.iti.informatik.th-darmstadt.de>
Subject: Re: Open Problems
To: TWG-TDS@SHSU.edu
Date: Mon, 18 Sep 1995 14:01:41 +0200 (MESZ)
Content-Type: text
Thomas wrote:
>
> > -- One must not use texmf/tex// as search path, due to duplicate
> > files. TEXINPUTS must be set for each format anew. (There may be
> > reasonable defaults, but eventually that's the bottom line.)
> > [Paul Vojta]
>
> I do not understand what the problem is. Or, are there systems where
> setting up different search paths are difficult? Or, is the problem
> that this is not yet properly explained in the current draft?
The latter. The draft gives the impression as if texmf/tex// might be
a good (i.e., valid) TEXINPUTS path. That's not true, filenames are
only unique over the trees tex/{<format>,generic}/. Come to think of
it, perhaps this should be added as an explicit requirement.
> > -- PK files not generated by MF go in
> > fonts/pk/modeless/<utility>/dpi<dpi>/<font>.pk
> > [Joachim & Karl]
>
> Hm... No supplier/typeface part? Another thing: I do not like that
> the files of the same type (e.g. .pk files) are stored at different
> directory levels. If you compare
> fonts/pk/cx/public/cm/dpi300/cmr10.pk # 6 dir. levels
> with
> fonts/pk/modeless/gsftopk/dpi300/ptmr8r.pk # 5 dir. levels
> fonts/pk/modeless/gsftopk/adobe/times/dpi300/ptmr8r.pk # 7 dir. levels
> then the modeless are always off by one...
Yep, I got that wrong.
`fonts/pk/<utility>/<supplier>/<typeface>/dpi<dpi>/<font>.pk'
(or, alternatively, `.../<font>.<dpi>pk') was the last state of
discussion.
Basic point: The draft doesn't cover PK fonts not created by MF that
don't have a concept of modes.
> > -- Where are binaries placed?
> > o Non-Unix folks don't like bin/<platform>/.
>
> And UNIX folks do not like fonts/type ... :-) In my opinion, binaries
> info pages and manpages should be keep out of the draft. Maybe a
> recommendation where to put them, but it should be clear that these
> could be outside the texmf tree, too.
In case I wasn't clear enough: That's (almost) exactly my point. Move
the whole stuff to an appendix where we express our disagreement and
announce that we have to wait for further experiences.
To mention another (new) point: It isn't clear to me if the sentence
`emtex/texmf/ is wrong' is good. In contrary, I think it doesn't
capture the CD situation at all. E.g., _I_ would organize a
Unix-centric CD this way:
<mount point>/{bin,lib,texmf}/
(perhaps with a $PLATFORM somewhere in between), and I'd bet that
most people would use a directory name as the mount point that has
the `product' in it. I.e., they yield something like
/opt/unixtex/texmf/. (That may even lead to a directory
/opt/unixtex/texmf/unixtex/.) Your mileage may vary.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Mon, 18 Sep 1995 08:14:13 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0sufxL-0001iBC@csrj.crn.cogs.susx.ac.uk>
Date: Mon, 18 Sep 95 14:09 BST
From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: TWG-TDS@SHSU.edu
Subject: Re: Open Problems
>I'm loosing my job in two weeks (and have no new one yet), so don't
>expect much engagement from me in formulation issues.
Good luck finding a new job!
> -- PK files not generated by MF go in
> fonts/pk/modeless/<utility>/dpi<dpi>/<font>.pk
> [Joachim & Karl]
Please no! Please either:
fonts/pk/modeless/<supplier>/<typeface>/dpi<dpi>/<font>.[dpi]pk
or (preferably):
fonts/pk/<utility>/<supplier>/<typeface>/dpi<dpi>/<font>.[dpi]pk
It's easy to get the <supplier> and <typeface> by looking to see where
the .tfm file is kept.
> -- Where are binaries placed?
> o Non-Unix folks don't like bin/<platform>/.
It's worth noting that sometimes non-Unix people have good reasons for
this! Eg on the Mac it's usual for an application to keep all of it's
associated files in the same folder as it, or in subfolders. Eg OzTeX
expects something like:
Applications
OzTeX
OzTeX
OzTools
Configs
texmf
ie texmf has to be under OzTeX, not the other way round. (It's
possible to fool it using symbolic links, sorry I mean aliases, but
this gets you into hot water when installations are copied off CD-ROM,
etc. because you end up copying the pointer rather than the
directory.)
> I'm not convinced that it will really help, but it won't
> introduce problems either; so we should just add it.
Or encourage people to use `sensible' names (eg sussex).
Alan.
================================================================================
Archive-Date: Mon, 18 Sep 1995 19:09:49 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Mon, 18 Sep 1995 17:08:36 -0700
Message-ID: <199509190008.RAA21386@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Open Problems
On Mon Sep 18 07:46:08 1995,
Joachim Schrod <schrod@iti.informatik.th-darmstadt.de> wrote:
> Thomas wrote:
> >
> > > -- One must not use texmf/tex// as search path, due to duplicate
> > > files. TEXINPUTS must be set for each format anew. (There may be
> > > reasonable defaults, but eventually that's the bottom line.)
> > > [Paul Vojta]
> >
> > I do not understand what the problem is. Or, are there systems where
> > setting up different search paths are difficult? Or, is the problem
> > that this is not yet properly explained in the current draft?
>
> The latter. The draft gives the impression as if texmf/tex// might be
> a good (i.e., valid) TEXINPUTS path. That's not true, filenames are
> only unique over the trees tex/{<format>,generic}/. Come to think of
> it, perhaps this should be added as an explicit requirement.
On page 8 it says, ``a recursive search beginning at \path|texmf/tex|
is a correct path for {\TeX} inputs in a \abbr{TDS} tree.'' Are you saying
that this is incorrect? Or, are you saying that this is correct but that
texmf/tex// is an incorrect path for {\AmSTeX} and {\LaTeX} inputs?
If the latter, then this leads to a problem for authors of dvi drivers.
PostScript figures are also stored under texmf/tex, and the dvi driver has
to access them without knowing whether the dvi file came from plain TeX,
LaTeX, AmSTeX, or other. So non-uniqueness of file names will be a problem
at least for picture files.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
Archive-Date: Tue, 19 Sep 1995 05:43:55 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509191032.MAA21162@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Open Problems
To: TWG-TDS@SHSU.edu
Date: Tue, 19 Sep 1995 12:32:56 +0200 (MESZ)
Content-Type: text
Paul wrote:
>
> > The latter. The draft gives the impression as if texmf/tex// might be
> > a good (i.e., valid) TEXINPUTS path. That's not true, filenames are
> > only unique over the trees tex/{<format>,generic}/. Come to think of
> > it, perhaps this should be added as an explicit requirement.
>
> On page 8 it says, ``a recursive search beginning at \path|texmf/tex|
> is a correct path for {\TeX} inputs in a \abbr{TDS} tree.''
Ooh, even worse.
> Are you saying
> that this is incorrect?
Yes. And that's independent of TDS. There have been cases in the
past, where two different files with the same name are part of two
different macro packages. The most prominent example is LaTeX 2.09
vs. LaTeX, but there are other ones, too. (E.g., there were *.sty
files for Vanilla TeX in PC-TeX distribution that were in conflict
with the LaTeX files.)
I.e., *for TeX*, it is not valid to search all possible locations of
macro files for any format, as there may be (will be) name conflicts.
If one assumes sensible names for EPS files, there should not be any
name conflicts -- except if two lusers introduce a logo.eps. ;-)
Therefore I would assume that texmf/tex// is a valid (and good)
search path for DVI drivers if they need access to such files. (Of
course, slow without caching.) If programs need to locate macro
files, they must now the format for it.
Joachim
PS: More and more I come to the point that the discussion of `there
are no unique macro file names' should be part of the rationale.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Tue, 19 Sep 1995 05:50:44 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Sep 1995 06:48:54 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509191048.AA23745@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Open Problems
the open problems
that have been mentioned on this list since we distributed the draft.
Thanks for putting this together.
My first question is, Norm, are you still out there? Will you have time
to edit and prepare the next version? I wouldn't mind doing it, but I
don't have any SGML facilities, so I'd have to go back to straight
(some-flavor-of) TeX.
We need to settle this before getting to the nitty-gritty of text changes.
================================================================================
Archive-Date: Tue, 19 Sep 1995 05:50:45 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Sep 1995 06:48:54 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509191048.AA23753@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: texmf/tex//
-- One must not use texmf/tex// as search path, due to duplicate
files. TEXINPUTS must be set for each format anew. (There may be
[speaking as stds-type person]
I do not think the standard should require users to have a different
TEXINPUTS path for each format, or implementors to support this
feature. In practice, is there a problem for anything besides latex 2.09
vs. latex2e?
I think we already recognize that there is a potential problem; we
should probably recommend more strongly that implemntors support it.
[speaking as implementor]
On the other hand, if no other implementor objects, I certainly don't.
My programs already support this feature, and have for ages.
That's not true, filenames are
only unique over the trees tex/{<format>,generic}/.
Say what? As far as I know, we've always been assuming filenames are
unique over the entire tree. Or, more precisely, if filenames are not
unique, results are unspecified without a more precise path. What's
wrong with this?
================================================================================
Archive-Date: Tue, 19 Sep 1995 05:51:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Sep 1995 06:49:14 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509191049.AA23770@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: bin/, info/, man/, ...
-- Where are binaries placed?
Like Joachim and Thomas, I am entirely in favor of dropping the bin/
stuff out of the main part of the document (if not just removing it
entirely). I'm not sure it's a viable proposal for more than a handful
of sites, so probably doesn't deserve such prominent positioning.
info pages and manpages should be keep out of the draft. Maybe a
I seem to recall some recent discussions about this, but I don't
remember the conclusion. Isn't $TEXMF/man a natural place to put man
pages? (Etc.) Shouldn't we recognize that fact? That's not to say
everyone has to have it.
In fact, I seem to remember being opposed to $TEXMF/man because of its
platform-centrism, but then other people pointed out other platforms
have man pages, and so on and so on. Sounded right to me.
recommendation where to put them, but it should be clear that these
could be outside the texmf tree, too.
That is clear anyway. We already say that any of the directories we give
in the std need not exist at any particular site, unless they are useful
there ..
`emtex/texmf/ is wrong' is good. In contrary, I think it doesn't
Hmm, seems reasonable. I think there are lurking implications here, though.
================================================================================
Archive-Date: Tue, 19 Sep 1995 05:51:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Sep 1995 06:49:15 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509191049.AA23778@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: hopefully non-controversial miscellany
-- It must be made more explicit that format, base, & pool files are
placed in the <TeX implementation> tree. It's in the draft, but
Fine.
-- An appendix should be added that outlines known structures of <TeX
implementation> trees. It must be made explicit that this
Fine. I doubt much of a tree will be needed under emtex/ or web2c/
whatever. Certainly I'm not planning on any tree, just a couple of files.
-- TDS Registry -- what do we do with it?
I dunno. Suggest that does not need to be settled for the next draft to
happen.
-- Reserve package name local/, FWIW.
I'm not convinced that it will really help, but it won't
introduce problems either; so we should just add it.
It will help some people, it won't help others. As you say, it doesn't hurt.
================================================================================
Archive-Date: Tue, 19 Sep 1995 05:51:06 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Sep 1995 06:49:16 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509191049.AA23786@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: Feeling uncomfortable with designation `public'
I feel more and more uncomfortable with the designation `public' in the
Fine. public/ seems to be misunderstood/misused by everyone, so let's
drop it.
b) There is ongoing talk (e.g. on comp.fonts) which wants to equate
public with low quality. Of course, the originators of that talk have
I sincerely doubt a directory name will make any difference as to
people's opinions of font quality. Good fonts will become well-known,
bad fonts will be forgotten, by their very nature. But this is a side issue.
================================================================================
Archive-Date: Tue, 19 Sep 1995 05:51:07 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Sep 1995 06:48:55 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509191048.AA23761@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
CC: dak@pool.informatik.rwth-aachen.de
Subject: modeless fonts
-- PK files not generated by MF go in
fonts/pk/modeless/<utility>/dpi<dpi>/<font>.pk
[Joachim & Karl]
te> I do not like that
the files of the same type (e.g. .pk files) are stored at different
alan> or (preferably):
fonts/pk/<utility>/<supplier>/<typeface>/dpi<dpi>/<font>.[dpi]pk
The reason for the modeless/ directory, as I recall, is that searches
should generally take place over (1) the mode-specific directory (if any),
and (2) *all* mode-nonspecific directories (gsftopk, ps2pk, ...).
For example, for xdvi, one explicitly has to put the gsftopk// and ps2pk//
into the path, along with the usual $MODE//. Otherwise the PostScript
fonts aren't found.
That said, I'm not sure it's worth making the tree inconsistent just to
be able to say modeless//. Having the utility name serve as a mode name
seems natural.
Basic point: The draft doesn't cover PK fonts not created by MF that
don't have a concept of modes.
Yes, we do mention this. We say to use the utility name as the mode name.
================================================================================
Archive-Date: Tue, 19 Sep 1995 13:17:23 CDT
Sender: owner-twg-tds@SHSU.edu
Date: 19 Sep 1995 14:15:52 -0400 (EDT)
From: bbeeton <BNB@MATH.AMS.ORG>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: texmf/tex//
To: TWG-TDS@SHSU.edu
Message-ID: <811534552.729600.BNB@MATH.AMS.ORG>
Content-Transfer-Encoding: 7BIT
karl:
-- One must not use texmf/tex// as search path, due to duplicate
files. TEXINPUTS must be set for each format anew. (There may be
[speaking as stds-type person]
I do not think the standard should require users to have a different
TEXINPUTS path for each format, or implementors to support this
feature. In practice, is there a problem for anything besides latex 2.09
vs. latex2e?
although at the moment, i think we're down to a reasonable number of
versions of (la)tex, there have been times when we had as many as 5
live at once. and indeed this *does* require redefinition of the
texinputs path, because while one is migrating a production system
from one version to a new one, it's not always practical to rename
every single macro file or to rebuild for robustness under all
conditions.
another reason for specifying a variant texinputs path is for testing.
so, even though it may not be essential for the texinputs path actually
to be changed under any random circumstances, it is very necessary
that the *ability* to change the path be supported. (or have i
misunderstood something?)
-- bb
================================================================================
Archive-Date: Tue, 19 Sep 1995 14:00:13 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 19 Sep 1995 16:59:23 +0100 (BST)
From: Philip Taylor (RHBNC) <CHAA006@vms.rhbnc.ac.uk>
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
CC: CHAA006@vms.rhbnc.ac.uk
Message-ID: <950919165923.22a3c70e@vms.rhbnc.ac.uk>
Subject: Re: Open Problems
Joachim wrote:
>> PS: More and more I come to the point that the discussion of `there
>> are no unique macro file names' should be part of the rationale.
Joy, joy: now if only the discussion had _started_ from that
perspective, the outcome might have been very different. ** Phil.
================================================================================
Archive-Date: Wed, 20 Sep 1995 03:29:31 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0svPyE-0003HUC@gauss>
Date: Wed, 20 Sep 95 10:17 EDT
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: bin/, info/, man/, ...
> info pages and manpages should be keep out of the draft. Maybe a
>
> I seem to recall some recent discussions about this, but I don't
> remember the conclusion. Isn't $TEXMF/man a natural place to put man
> pages? (Etc.) Shouldn't we recognize that fact? That's not to say
> everyone has to have it.
>
> In fact, I seem to remember being opposed to $TEXMF/man because of its
> platform-centrism, but then other people pointed out other platforms
> have man pages, and so on and so on. Sounded right to me.
Yes, now I remember, too. But I still suggest to handle bin, man and
info the same way. If the bin will be taken out of the draft, then
man and info should be, too.
man and info pages change with new versions of the binaries in general
and are distributed together with the sources of the binaries. Putting
just a part of this into the texmf tree seems like a looser to me.
Thomas
================================================================================
Archive-Date: Wed, 20 Sep 1995 03:30:14 CDT
Sender: owner-twg-tds@SHSU.edu
Message-ID: <m0svPyE-0003HUC@gauss>
Date: Wed, 20 Sep 95 10:17 EDT
From: te@informatik.uni-hannover.de (Thomas Esser)
Reply-To: TWG-TDS@SHSU.edu
To: TWG-TDS@SHSU.edu
Subject: Re: bin/, info/, man/, ...
> info pages and manpages should be keep out of the draft. Maybe a
>
> I seem to recall some recent discussions about this, but I don't
> remember the conclusion. Isn't $TEXMF/man a natural place to put man
> pages? (Etc.) Shouldn't we recognize that fact? That's not to say
> everyone has to have it.
>
> In fact, I seem to remember being opposed to $TEXMF/man because of its
> platform-centrism, but then other people pointed out other platforms
> have man pages, and so on and so on. Sounded right to me.
Yes, now I remember, too. But I still suggest to handle bin, man and
info the same way. If the bin will be taken out of the draft, then
man and info should be, too.
man and info pages change with new versions of the binaries in general
and are distributed together with the sources of the binaries. Putting
just a part of this into the texmf tree seems like a looser to me.
Thomas
================================================================================
Archive-Date: Wed, 20 Sep 1995 07:00:51 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509201158.NAA19712@spice.iti.informatik.th-darmstadt.de>
Subject: Re: Open Problems
To: TWG-TDS@SHSU.edu
Date: Wed, 20 Sep 1995 13:58:53 +0200 (MESZ)
Content-Type: text
You wrote:
>
> Joachim wrote:
>
> >> PS: More and more I come to the point that the discussion of `there
> >> are no unique macro file names' should be part of the rationale.
>
> Joy, joy: now if only the discussion had _started_ from that
> perspective, the outcome might have been very different. ** Phil.
For the record: I mentioned the point that one needs different macro
file search paths for different formats very early. (Partly, because
I use them since years in my installation setups, utilizing shell
scripts.) The reason above was implied. I don't think that
explicating the reason would have changed the outcome -- no
experience exists for more radical approaches, and developers won't
support them anyhow.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 20 Sep 1995 07:04:22 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509201203.OAA21778@spice.iti.informatik.th-darmstadt.de>
Subject: Re: texmf/tex//
To: TWG-TDS@SHSU.edu
Date: Wed, 20 Sep 1995 14:02:59 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> That's not true, filenames are
> only unique over the trees tex/{<format>,generic}/.
>
> Say what? As far as I know, we've always been assuming filenames are
> unique over the entire tree.
???? Over which tree? texmf/? That's not true, to start with font
names. But it's also not true for macro files. We can assume that
macro files for one format have unique file names. But not in a wider
area. Well, above I also added the restriction that they should not
conflict with generic/. (Since generic is used for every format, by
definition.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Wed, 20 Sep 1995 09:52:21 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 20 Sep 1995 10:50:31 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509201450.AA14553@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: bin/, info/, man/, ...
man and info pages change with new versions of the binaries in general
and are distributed together with the sources of the binaries. Putting
just a part of this into the texmf tree seems like a looser to me.
Mm, good point.
I'm not opposed to removing them from the main part of the draft.
The urgent question is, who's going to do the editing?
If Norm no longer has time to do it, and no one else has SGML & time
enough either, I will grab the distributed draft and start making the
changes we've agreed as best as I can.
================================================================================
Archive-Date: Wed, 20 Sep 1995 09:58:54 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 20 Sep 1995 10:57:03 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509201457.AA14676@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/tex//
that the *ability* to change the path be supported. (or have i
Yes, certainly, people should be able to set whatever path they want.
The question, as far as I know, is whether the TDS should require
implementors to provide a way to simultaneously define one path for one
program (latex-foo) and another path for another program (latex-bar).
I doubt we will get very far with such a requirement.
I'm also not convinced this is necessary or desirable.
================================================================================
Archive-Date: Wed, 20 Sep 1995 10:31:33 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509201529.RAA17262@spice.iti.informatik.th-darmstadt.de>
Subject: Re: texmf/tex//
To: TWG-TDS@SHSU.edu
Date: Wed, 20 Sep 1995 17:29:05 +0200 (MESZ)
Content-Type: text
You wrote:
>
> that the *ability* to change the path be supported. (or have i
>
> The question, as far as I know, is whether the TDS should require
> implementors to provide a way to simultaneously define one path for one
> program (latex-foo) and another path for another program (latex-bar).
Yes, we should. And it's no problem as every TeX implementation I
know of supports that requirement already. (By means of scripts or
resource files.)
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Thu, 21 Sep 1995 10:40:11 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Thu, 21 Sep 1995 11:38:52 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509211538.AA13656@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: texmf/tex//
> The question, as far as I know, is whether the TDS should require
> implementors to provide a way to simultaneously define one path for one
> program (latex-foo) and another path for another program (latex-bar).
Yes, we should.
Joachim, I'm afraid don't understand. What is the proposed change here?
Is the idea that we're just clarifying that this is the case? That
filenames need not be unique across different formats? There's no
``real'' change to the directory structure going on here, just better
explanations of the ramifications?
It's certainly true that *if* you have non-unique filenames, then you
must more precisely specify the path.
================================================================================
Archive-Date: Fri, 22 Sep 1995 06:52:38 CDT
Sender: owner-twg-tds@SHSU.edu
From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509221150.NAA19690@spock.iti.informatik.th-darmstadt.de>
Subject: Re: texmf/tex//
To: TWG-TDS@SHSU.edu
Date: Fri, 22 Sep 1995 13:50:54 +0200 (MESZ)
Content-Type: text
Karl wrote:
>
> > The question, as far as I know, is whether the TDS should require
> > implementors to provide a way to simultaneously define one path for one
> > program (latex-foo) and another path for another program (latex-bar).
>
> Yes, we should.
>
> Joachim, I'm afraid don't understand. What is the proposed change here?
>
> Is the idea that we're just clarifying that this is the case? That
> filenames need not be unique across different formats? There's no
> ``real'' change to the directory structure going on here, just better
> explanations of the ramifications?
Yes, that's my point. Describe the fact leading to a requirement, not
a technical solution.
\begin{digression}
As I've said in previous mails, the TDS document should not describe
implementation strategies, but should just describe layouts and add
the implications for requirements if we detect from our feedback that
the implications are not clear for our readers. To get the proposal
accepted by the TeX community, we have to make sure that the
requirements are implementable with the systems today. If the
implementation is not obvious, we should record that check in an
appendix, for our reader's information.
\end{digression}
There is an obvious implementation of the requirement for different
TeX input files search paths, namely wrapper scripts that set that
path. Most TeX implementations use some script (or configuration
file, in the case of GUI-based systems) anyhow to call TeX, since
they need to record the format somewhere.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
================================================================================
Archive-Date: Sat, 23 Sep 1995 08:43:41 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sat, 23 Sep 1995 14:05:23 +0200
From: David Kastrup <dak@pool.informatik.rwth-aachen.de>
Reply-To: TWG-TDS@SHSU.edu
Subject: Re: modeless fonts
To: kb@cs.umb.edu
CC: TWG-TDS@SHSU.edu
Message-ID: <199509231205.OAA07266@stan.goethe.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Date: Tue, 19 Sep 1995 06:48:55 -0400
From: "K. Berry" <kb@cs.umb.edu>
Cc: dak@Pool.Informatik.RWTH-Aachen.DE
Content-Type: text
Content-Length: 1049
-- PK files not generated by MF go in
fonts/pk/modeless/<utility>/dpi<dpi>/<font>.pk
[Joachim & Karl]
The reason for the modeless/ directory, as I recall, is that searches
should generally take place over (1) the mode-specific directory (if any),
and (2) *all* mode-nonspecific directories (gsftopk, ps2pk, ...).
For example, for xdvi, one explicitly has to put the gsftopk// and ps2pk//
into the path, along with the usual $MODE//. Otherwise the PostScript
fonts aren't found.
That said, I'm not sure it's worth making the tree inconsistent just to
be able to say modeless//. Having the utility name serve as a mode name
seems natural.
The problem was that the idea of mode directories in the first place
was to separate fonts with equal resolutions designed for different
printers, not to separate Metafont from non-Metafont fonts. The
modeless subdirectory is *not* for non-Metafont files in particular,
but for those fonts where no other design characteristics than the
resolution are of any influence.
The modeless/<utility> naming scheme would, for instance, allow a
directory modeless/metafont as well, if someone used a generic
parameter set (for example, no fillin etc) for generation of the font.
For the font selection mechanism there is no particular reason even to
make a <utility> subdirectory tree under modeless: all fonts are
designed for that size, and that's that. In order to facilitate
searches over this "generic" branch of fonts with equal design
characteristics, it would be useful to have them in one tree. For
purposes of organization, however, one might contrive that sometimes it
might be of interest to separate this into separate trees
again. Specifically if one knows that a certain utility might generate
awful looking fonts which are of use only in emergencies, when no
other utility can generate them.
On the other hand, in the typical setup one will want to search one
mode-dependent font pool, and *all* mode-independent ones. The
"modeless" subdirectory tree warrants that.
Basic point: The draft doesn't cover PK fonts not created by MF that
don't have a concept of modes.
Yes, we do mention this. We say to use the utility name as the mode name.
Yes, but that does not take into account that *all* modeless fonts
have the common property of being usable at the resolution they are
specified for.
Now strictly speaking, as metafont-generatedness and modeness are not
related (one can contrive mode-dependent font-generating utilities
apart from metafont, and vice versa) a general layout of
mode/<utility>/...
would be the logical choice, leading to names like
fonts/pk/CanonDX/metafont/dpi300/cmr10.pk
as opposed to fonts like
fonts/pk/CanonDX/fetamont/dpi300/cmr10.pk for a differently named
utility generating mode-dependent files.
However, for a TeX-oriented tree, the extra mention of metafont
generaated files might seem a bit exaggerated.
So the <utility> subdivision might be of use mainly in the modeless
hierarchie. At least the distinction CanonDX/modeless is much more
useful than the distinction CanonDX/pstopk, which would imply that no
program other than metafont could ever produce printer specific fonts.
Another possible scheme would be the full <mode>/<utility> scheme
(where <mode> can be modeless as well) where /metafont would always be
left out.
This would have fonts/pk/CanonDX/dpi300/cmr10.pk (from metafont) as
opposed to fonts/pk/CanonDX/fetamont/dpi300/cmr10.pk. Perhaps a tadbit
ugly, but "upwards compatible" to metafont only outfits. And it is
still rather possible to search with appropriate patterns for
metafont-only fonts even in the mode-dependent directories (well,
something like fonts/pk/CanonDX/dpi*/*.pk -- oops, I believe web2c
will *not* currently allow patterns like that, perhaps it should?).
So for a consistent scheme I see two possibilities: either require
that current search strategies are extended to cover wishes like the
above mentioned one, or include metafont as utility name always, or
*never* include the utility name, or not allow any utility except
metafont to generate mode-dependent files.
Not much clarification I offer here, do I? Still found this worth
mentioning, and still think that the modeless directory should be the
alternative to the mode-dependent directories, and that I think it not
unwise to have a separation on name of utility, just in case one might
need it for any purpose, or just to prefer one utility over the other,
if deemed appropriate.
--
David Kastrup, Goethestr. 20, D-52064 Aachen Tel: +49-241-72419
Email: dak@pool.informatik.rwth-aachen.de Fax: +49-241-79502
================================================================================
Archive-Date: Sun, 24 Sep 1995 16:16:04 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Sun, 24 Sep 1995 17:14:23 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509242114.AA09801@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: modeless fonts
For the font selection mechanism there is no particular reason even to
make a <utility> subdirectory tree under modeless: all fonts are
designed for that size, and that's that. In order to facilitate
Since gsftopk and ps2pk don't produce the same output, we must
distinguish them. Therefore, we need a <utility> directory.
On the other hand, in the typical setup one will want to search one
mode-dependent font pool, and *all* mode-independent ones. The
"modeless" subdirectory tree warrants that.
Yes, that's the argument. To search all the mode-independent fonts, you
would currently have to specify all the utility names:
$TEXMF/fonts/pk/{$MODE,gsftopk,ps2pk}//
[no, TDS doesn't allow/propose {foo,bar} syntax, but for purposes of
discussion...]
With modeless, the path spec simplifies and generalizes to:
$TEXMF/fonts/pk/{$MODE,modeless}//
But the counter-argument is that with the introduction of modeless/, PK
files are at different levels in the tree, we've used up one more (the
last) directory level, and things are generally non-orthogonal.
fonts/pk/CanonDX/metafont/dpi300/cmr10.pk
as opposed to fonts like
fonts/pk/CanonDX/fetamont/dpi300/cmr10.pk for a differently named
Hmm, that's certainly the most general solution. But, as you say,
specifying `metafont' for the common case seems a bit painful.
something like fonts/pk/CanonDX/dpi*/*.pk -- oops, I believe web2c
will *not* currently allow patterns like that, perhaps it should?).
No, it doesn't, and no, I don't want to implement complete filename
globbing :-). (And even if I did, the TDS could never promulgate a
solution that requires such a thing.)
================================================================================
Archive-Date: Sun, 24 Sep 1995 22:32:37 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Sun, 24 Sep 1995 20:31:48 -0700
Message-ID: <199509250331.UAA01516@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: modeless fonts
> Date: Sun, 24 Sep 1995 17:14:23 -0400
> From: "K. Berry" <kb@cs.umb.edu>
> To: TWG-TDS@SHSU.edu
> Subject: Re: modeless fonts
>
> For the font selection mechanism there is no particular reason even to
> make a <utility> subdirectory tree under modeless: all fonts are
> designed for that size, and that's that. In order to facilitate
>
> Since gsftopk and ps2pk don't produce the same output, we must
> distinguish them. Therefore, we need a <utility> directory.
Why? They are used in the same way, aren't they?
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
Archive-Date: Mon, 25 Sep 1995 11:08:05 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Mon, 25 Sep 1995 17:04:21 +0100
From: Sebastian Rahtz <s.rahtz@elsevier.co.uk>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509251604.RAA15667@cadair.elsevier.co.uk>
To: TWG-TDS@shsu.edu
Subject: Re: bin/, info/, man/, ...
References: <199509201450.AA14553@terminus.cs.umb.edu>
>
> The urgent question is, who's going to do the editing?
>
> If Norm no longer has time to do it, and no one else has SGML & time
> enough either, I will grab the distributed draft and start making the
> changes we've agreed as best as I can.
i am sorry for being "absent" for a week, sometimes i have to do work
for my employers.
Karl, since i am in some sense an authority for this group (as the
Technical Council liaison), I *do* ask that you take over from Norm
until he can get back on the job. I don't think there is any inherent
necessity to have the source in SGML, so editing the last TeX file
seems fine. If you can do this, i think we'd all be very happy.
sebastian
================================================================================
Archive-Date: Tue, 26 Sep 1995 09:45:18 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Tue, 26 Sep 1995 10:44:20 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509261444.AA27419@ra.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: modeless fonts
Why? They are used in the same way, aren't they?
Yes. But the point is that a site might well have both installed.
I don't think it would be desirable for output from utility A to
overwrite output from utility B!
Although there is no quality difference (to my knowledge) bteween ps2pk
and gsftopk, both being derived from the Type 1 renderer IBm donated to
the X Consortium, one can easily imagine that changing, or someone else
writing/donating a different renderer.
================================================================================
Archive-Date: Tue, 26 Sep 1995 15:24:13 CDT
Sender: owner-twg-tds@SHSU.edu
From: vojta@math.berkeley.edu (Paul Vojta)
Reply-To: TWG-TDS@SHSU.edu
Date: Tue, 26 Sep 1995 13:21:13 -0700
Message-ID: <199509262021.NAA04348@tashkent.berkeley.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: modeless fonts
On Tue Sep 26 09:35:51 1995, Karl Berry wrote:
> Why? They are used in the same way, aren't they?
>
> Yes. But the point is that a site might well have both installed.
> I don't think it would be desirable for output from utility A to
> overwrite output from utility B!
MakeTeXPK checks for that.
--Paul Vojta, vojta@math.berkeley.edu
================================================================================
Archive-Date: Wed, 27 Sep 1995 17:46:03 CDT
Sender: owner-twg-tds@SHSU.edu
Date: Wed, 27 Sep 1995 18:44:14 -0400
From: "K. Berry" <kb@cs.umb.edu>
Reply-To: TWG-TDS@SHSU.edu
Message-ID: <199509272244.AA07693@terminus.cs.umb.edu>
To: TWG-TDS@SHSU.edu
Subject: Re: modeless fonts
> I don't think it would be desirable for output from utility A to
> overwrite output from utility B
MakeTeXPK checks for that.
Certainly. But the point is that there's no reason to assume all
renderers are of equal quality. If we have only one `modeless' directory
for the output of gsftopk, ps2pk, and other-programs-as-yet-unwritten,
that's what we're assuming. I think it's preferable, and certainly more
cautious, to admit up front that there are multiple programs to make PK
files from PostScript fonts, and people might want to have the output
from all (more than one) of them around, instead of making the standard
be to lump them all together.