comments on v0.102

David Carlisle TWG-TDS@SHSU.edu
Mon, 30 Oct 95 11:14:38 GMT


Only really `editorial' comments for Karl this time, 

Compliments to Joachim on the class file, looks much nicer than
article class:-) I did wonder whether it would be more consistent to
use sans serif rather than bold in the table of contents lines, and
similarly the title, but I'm ony a TeX hacker: don't take my word on
document design... Anyway I assume the tugboat version will reset
everything in normal tugboat style?


Section 2.4, Page 6

> \item A completely separate tree, following a \abbr{TDS} structure
> itself; for example, \path|/usr/local/oratex| and
> \path|/usr/local/texmf|.

I think the the traditional unix `local' is rather a distraction here,
and may really confuse non-unix readers. Is it clear that
/usr/local/texmf is given as an example of the *non*-local tree...
Also, especially now Norm's O'Reilly address is not on the document
people may be confused as to what `oratex' is supposed to mean.

How about

\item A completely separate tree, following a \abbr{TDS} structure
itself; for example, an installation at O'Reilly and Associates may
install a `local' TDS tree under \path|/opt/oratex| and a `standard'
TDS tree under \path|/opt/texmf|.


> \item their standard location in the main \abbr{TDS} tree (if it can be
> made globally read/write); or
> 
> \item ... in their main \abbr{TDS} tree ...
> 
> \item or ....

The use of `or' is inconsistant, at the end of the first item, and the
start of all the rest, also `in their' should be `in the' or `in its'

Something like


\begin{itemize-squeeze}

\item their standard location in the main \abbr{TDS} tree (if it can be
made globally read/write);

\item or in an alternative location in the main \abbr{TDS} tree (for
example, under \path|texmf/fonts/tmp|);

\item or in a second complete \abbr{TDS} tree (as outlined above); 

\item or in any other convenient directory (perhaps somewhere under
\path|/var|, for example \path|/var/spool/fonts|).

\end{itemize-squeeze}


Section 4 page 14

> . . <package>/    name of a package (e.g., \path|graphics|, \path|nfss|)
  . . <package>/    name of a package (e.g., \path|graphics|, \path|psnfss|)
                                                                    ^^

Section B.2 page 17

> Different implementations have elected to use different syntaxes for

syntaxes ? or syntax ?  not sure, I'd probably have said syntax.

> \item[\application{em\TeX{}}:]
> \path|t:\directory!!|; \path|t:\directory!| for a single level of searching.
> \item[\application{Kpathsea}:]
> \path|texmf/subdir//|

...

Half the examples here use `subdir' and half use `directory' As I think
the same concept is meant in both cases, probably best to use the same
word for all the \item's  perhaps `subdir' as that would fit the dvips
environment variable name.

Section B.3.2 page 18

> (Email \path|tex-k@cs.umb.edu| ....
Useful info but I'm not really sure it belongs here, we don't give
contact addresses for any other implementation.

> See \path|prep.ai.mit.edu:/pub/gnu/standards.*|
Perhaps rephrase that without an explicit filename at that point, and
add prep to the list of reference sites at the end?

Section C.2.3 page 20

> Although we are making an implicit assumption that \MF{} is the only
> program producing mode-dependent bitmaps, if this becomes false we can
> add an abbreviation for the program to mode names, as in \path|mfcx|
> vs.\ \path|xyzcx| for a hypothetical program \application{Xyz}. Or we
> can at that time add an additional program name level uniformly to the
> tree; for our present purposes, it seems more important to concisely
> represent the current situation than to take account of hypothetical
> possibilities that may never be realized.

Seem to have a sentence starting with Or, perhaps:

We are making an implicit assumption that \MF{} is the only
program producing mode-dependent bitmaps. If this becomes false we can
add an abbreviation for the program to mode names, as in \path|mfcx|
vs.\ \path|xyzcx| for a hypothetical program \application{Xyz} or we
can at that time add an additional program name level uniformly to the
tree. For our present purposes, it seems more important to concisely
represent the current situation than to take account of hypothetical
possibilities that may never be realized.