LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
From: Lars Hellström <[log in to unmask]>
Date: Wed, 3 Nov 1999 17:16:18 +0100
In-Reply-To: <[log in to unmask]>
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments: text/plain (80 lines)
On the matter of relativizing the section headings, I think doing that
would be creating a much greater mess than it could ever be worth. People
often compiling large documents from several small might possibly benefit
from it, but they would be better served by a package with this as the
feature than by additional functionality in the kernel or the standard
classes. I suspect the normal user would get less trouble from explicitly
changing the section heading commands using search and replace than from a
document where the section headings don't produce what their names

Section heading environments like the "head" FMi described would be sound,
but it is questionable whether they are useful enough to be a new standard
feature. I would say no.

FMi wrote:
>i would call two latex classes (the term class is actually bad in 2e) "source
>compatible" if they can successfully process the same documents, ie provide
>the same user commands and functionality. in other words a document that can
>be processed by article.cls would be processable (with sensible results) by
>any other class that is source compatible to article.cls --- one could say the
>two LaTeX2e classes belong to the same class, urg (this is when i meant the
>term was badly chosen).

How about saying that the two classes belong to the same family?

>now i wonder if i would claim that article.cls and myarticle.cls differing
>only in the setting of the secnumdepth counter should be considered
>incompatible in the above sense.
>there are arguments for it and arguments against it:
> - since the availibility of numbering or generally the availability of
>   refering to  a heading via \ref differs one can argue the classes are not
>   source compatible

A solution here could be that if \label is applied to an unnumbered heading
then (optionally) a warning could be issued and the reference text would
become the heading text itself (plus some formatting), e.g. after

   \subparagraph{Gnus} \label{Spar:Gnus} % I don't think these get numbers

the code

   ... see also Subparagraph~\ref{Spar:Gnus].

would typeset as

   ... see also Subparagraph `Gnus'.

or even

   ... see also Subparagraph `Gnus' of Paragraph

It's certainly not ideal (and it would benefit a lot from some kind of
relativity in the referencing), but it does make sense.

As for how to implement it, I would make it so that the heading template
puts together the reference string and sets a flag to mark that something
unnumbered is being referenced. Then the \label (if there is one) prints
the warning (if the class or whatever thinks it is needed).

> - on the other hand this is making the granularity very small and it might
>   mean that coming up with sufficient additional issues of that type nearly
>   no class can be considered compatible to another one.


BTW, it would be nice if there could be clearer documentation regarding
which features are available assuming that the document class belongs to
the same family as (one of) the standard LaTeX classes, and which features
should exist for all LaTeX classes. This has often assoyed me when I have
been writing classes. The ("How to write a LaTeX document") manuals I've
read make no distinctions here, so users generally expect very much.

Lars Hellström

PS: On the matter of silence, perhaps this will help cheer Frank up: I
think I can agree to everything you have written recently on section