LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 9 Nov 2009 23:55:31 +0100
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
In-Reply-To:
Content-Type:
text/plain; charset=us-ascii
From:
Frank Mittelbach <[log in to unmask]>
Parts/Attachments:
text/plain (179 lines)
Lars,

 > >  > That one feels a bit wobbly. But is your thinking that this kind of 
 > >  > information is frequently appearing in page heads, and page head 
 > >  > contents are being set by this kind of command, so there needs to be a 
 > >  > way to pass the information?
 > > 
 > > you mean the subtitle?
 > 
 > Yes.
 > 
 > > I think this is only of interest to some kind of headings and then only
 > > to A-heads probably, so i'm not sure about that one really, I just tossed
 > > it out for discussion. On the other hand, it seems to me that for A-heads
 > > that is in theory common enough (for example in proceedings) that I think
 > > it should be included even if for most documents it is not necessarily
 > > made available on document.
 > 
 > I was mostly thinking that the description seemed very vague -- sort of 
 > "here we can put *one* piece of information that won't fit anywhere 
 > else", which IMHO would be poor API design: meaning of data is 
 > unspecified, and it's not sufficiently flexible. E.g. author name and 
 > copyright information might well be independent.

you are right, that was somewhat sloppy, and perhaps it shows how unsure I am
right now where to draw the line. Yes you are right, that author name and
copyright could well be something different. so lets see if we can get more
precise and accept at the same timethat we don't solve all possible
applications (and that for those different/extended object types would be
needed).


 > As for A-heads: I read a book recently that had a separate author for each
 > chapter, and a division into parts above that. (It also has copyright
 > information in every page footer, although only a constant "(C) The authors
 > and <name of publisher>".)
 > 
 > >  > >   - motto/quote text to display alongside the heading title
 > > 
 > > having said the above, one probably doesn't need both "sub-title" and
 > > "motto" as the latter is just another type of sub-title application
 > > really.
 > 
 > Depends on whether you look at it graphically or semantically. For 
 > designing a general API, I think you really need to look at it 
 > semantically.

yes agreed, but we can only go semantically up to a certain level, otherwise
you need to specify 100+ arguments and still haven't covered all
possibilities.

what i'm currently thinking might be reasonable is

 - subtitle (which is text that is semantically related to main title)
 - motto/quote text (text which is semantically unrelated to main title)

and support both. 

 - text credits (which is author copyright or similar info but not
                 semantically specified further)

if more control is needed then that type is not specialized enough to support
it.

 > 
 > >  > >   - flag to number heading
 > >  > 
 > >  > Or should numbered and unnumbered headings be generated by separate 
 > >  > instances? Needs to be thought about.
 > > 
 > > both is possible of course, but in my opinion a certain design for a
 > > heading with and without numbers shares so much on the design-level that
 > > it seems reasonable to provide a single template with a flag to say
 > > whether or not to generate a number for the heading.
 > 
 > OK, just remember to write down the rationale for these decisions.

right. but look at this this way: is the design for numbered compared to
unnumbered heading be similar for the majority of cases in real life? I guess
the answer will be yes.

An in cases where this is not true I offer the following  heading template:

 \DeclareTemplateInterface {heading} {complex}
     {
         numbered-design-setup : instance {heading} ,
       unnumbered-design-setup : instance {heading} ,
     }

and you are good to go to combine any two designs

 > 
 > >  > > do we need a way to specify that something is send to the TOC or to the
 > >  > > running header and if so how do we do that?
 > >  > 
 > >  > Isn't that explicit in the above? Or did you rather think about the 
 > >  > document-level commands here?
 > > 
 > > I don't think it is explicit unless you overload things. From a document
 > > level perspective a writer might want to say
 > > 
 > >  - do not put a title line into the toc
 > >  - do not put a title line into the running header
 > >  - not not number this heading
 > 
 > Ah, so "specify that something is send to the TOC" means whether to put 
 > anything at all there, not what exact text to put there. My bad.

well yes, as I said I don't want to overload the interface, but perhaps that
is the wrong idea and some overloading is fine, dunno (I mean <empty>  value is
something one can't really imagine sending to a toc, but one can imagine
sending it to a running header so it doesn't really  work as a flag.

 > 
 > > in 2e that was alway bundled together with the * so it was all or nothing
 > > but typically the last one was independent of the other two resulting in
 > > the gymnastics with \addcontentsline near things like a bibliography etc
 > > 
 > > on the other hand I must confess that I don't see much application for
 > > not putting somehting into the toc (on an individual basis but in the
 > > running header or vice versa). Perhaps others have some experience /
 > > examples that indiciate otherwise?
 > > 
 > > anyway, starting from a need to be able to specify that on
 > > document-level, that then needs to be conveyed to the template and
 > > without some explicit flags that isn't there.
 > 
 > My first gut reaction is that decisions of whether to put a heading in 
 > the TOC or not should be controlled by the choice of instance (or are 
 > they named "objects" now?).

that is fine for the general setup, eg this instance will send its title text
to the running header but the instance that implements \subsubsection will
not.

However that doesn't take away the need for more control from the document
level, as suggested by the examples Ulrich gave.


 > Then I see that you may indeed want to control this from the document 
 > level command, and doing that via selection of instances, like e.g.
 > 
 >    \DeclareDocumentCommand{\section}{t* t+ t- ...}{
 >       \UseInstance{heading}{section%
 >          \IfBooleanT{#1}{-nonumber}%
 >          \IfBooleanT{#2}{-notintoc}%
 >          \IfBooleanT{#3}{-norunning}%
 >       }...
 >    }
 > 
 > is probably not very practical.

not it is not as you don't want to write 10 instances for each heading just
because Ulrich has special formatting needs :-)

 > 
 > On the other hand, it is starting to look like a template for handling 
 > all those flags will become rather complicated. Perhaps one should 
 > rather have separate instances for the three functions of "heading on 
 > page", "heading in TOC", and "heading in running head"? In that case, 
 > it is probably the common syntaxes of these that should be discussed 
 > first.

I don't think it gets complicated, as the management and interpretation of
these flags could be handled by a single function that is common in all
templates (after all passing or not passing data to the toc, is not differing
in design, you either do it or you don't). So roughly such a common function
would need to interpret what comes down the mandatory arguments of the
template plus some overwrites on the template level that potentially restrict
that interpretation, eg this template instance will never write to the running
head.

 ... I see that you have a good number of more thoughts on the topic, but I'm
 getting tired tonight, so rather than trying to comment on them (they might
 well make some of the above obsolete, who knows) I'll stop now

'night
frank

ATOM RSS1 RSS2