Frank Mittelbach skrev:
> Lars Hellström writes:
> continuing where I left off last night
> > An argument for separating these functions is that doing something
> > innovative in one of the three areas is not making you more likely to
> > do something innovative in the two others.
> > E.g. a designer might need
> > to commision a new template for headings because the design does
> > something that cannot be achieved simply by setting parameters in the
> > standard template, but it's only the "heading on page" that needs this.
> I was wondering about this. Is it true? In case of the toc I would say no:
> all a heading object does is passing data into a toc sub-system and the
> formatting of that data is then controlled by templates for that part
> And the same is true for the running head.
Right. I was thinking that it is the heading object that formats text
for TOC and head, but if it just passes data along to be formatted
elsewhere, then a single object is fine. The tripartite model would
anyway have problems with the fact that the whatsits corresponding to
data going elsewhere should anyway be positioned somewhere, and that
would have to be controlled by the on-page component.
> > Creating the new template then becomes much more complicated if it also
> > has to deal with the technicalities of running heads and TOCs. One
> > might also want to combine one package's nice "heading on page"
> > features with another package's feature to include author names in the TOC.
> actually I think we have to drop the believe that such packages will exist -
> they don't in that form exist in 2e which has a simpler model, and will not
> work in the l3 model either.
> What I mean is that there will be no packages that enhance existing templates
> by adding something to the templates. What you will have is packages that
> offer new templates for the same object type with different features.
Precisely! The setting I imagined was that of two packages providing
one new template each: one for on-page headings and one for TOC item
formatting. If (as I previously understood it) both these functions
were supposed to be carried out by objects of the main heading type,
then it would have been impossible to combine these features. But since
TOC item formatting also in your model is supposed to be carried out by
a separate object, they can be used together.
> > > > > what else is missing or which of the above aren't sensible in the
> > > > > first place?
> > > >
> > > > One might consider making one argument a keyval dictionary and collect
> > > > many of the above in that instead.
> > >
> > >
> > > that would be a document level syntax decision, ie how to write a heading
> > > command in your document.
> > No, I meant it as an *implementation level* syntax.
> oh, I see what you're getting at
> well, it may be something to think about. but a few comments here
> - an open-ended interface is also meaning that you will likely end with a
> babel like confusion (and I don't mean 2e babel but just the biblical
> problem) i.e., everybody is dreaming up new values that are then not
> supported anywhere else etc etc ... and out of the window goes and
> transparency in terms of replacing one design by the next
In my experience, it works quite well to just silently ignore
unsupported options (probably because it's equivalent to knowing that
it is there but never caring about its value).
> - let's first see if we ever end up with huge object types. I don't get
> believe it. the heading might be the most complex thing we ever see in this
> respect and even here I guess what we end up with is less than 6
Already title, toctitle, headtitle, number-flag, toc-flag, and
head-flag makes 6, and that's without author, subtitle, xref-id,
abstract, and other stuff that's been discussed.
> - one of the reasons to limit ourselves to mandatory args initially was
> speed, but another one (and we reflected on that one) was that it would
> force us to keep the semantics simple.
> I still think that this is basically the right decision, but we'll see. if we
> do turn up with object types that we have to limit but don't really want to
> than yes that needs revisiting. As it stands now, the object types that I came
> across require a small number of input supplies the biggest ones are those for
> headings and toc entries. Of course, abstractly it is easy to envision an
> object that requires 20 different input supplies and that formats them
> somehow, especially in database query -> format type of situations (such as
> your example with bibtex). but the question is: would/should that still be
> formatted then with a template model? or should there be some preprocessing
> through some different method.
You mean, since one can't get the various pieces of text simply as #1
or #2 or #3 etc., one would want something different than templates?
(Retrieving "toctitle from #3" could in fact be considered a natural
extension of some of the preprocessing ideas I tossed up for xparse.)
But I see templates+instances more as a method of separating design
parameters from macro bodies, so I'd say those are orthogonal concerns.
The purpose of using a dictionary would be to allow the data being
passed around to have more structure. I also think passing a dictionary
to the TOC entry formatter would be great, as that will allow *it* to
decide whether to include an author name, subtitle, short description,
etc. or not.