There has been some work going on within the team to get ideas (and
code) into better shape with template. The result of the work is the
xtemplate package. There are still open questions that we are working
on, and also some where more input would be very helpful. I'll try to
outline what we have done and what remains to be decided.
The ideas are laid out in the dtx: Will has done a good job of setting
them out there, and I'm not going to repeat it! For people familiar with
template, you'll see that we've renamed \DeclareTemplateType to
\DeclareObjectType, as the old name was downright misleading.
The keyval system has been completely revised in xtemplate. This is
because it became clear we wanted some "self-documentation" in the keys.
The idea now is to divide things into two:
- \DeclareTemplateInterface. This sets up the names of keys in a
template and the type of argument they expect (skips, functions, etc.).
It also includes default values.
- \DeclareTemplateCode. Sets up the implementation of the keys.
The reason for this is that the interface should be understandable
without needing to know about the code. So the aim is that you can look
at the arguments to \DeclareTemplateInterface and know what you might
want to change, without looking at \DeclareTemplateCode at all.
Most of the ideas for instances and collections have not changed (at the
There are a number of things that still need sorting out. In no
particular order, I'll list the ones I remember.
The key types are in the main pretty easy to follow. One that I'm not
sure about is "tokenlist". In the context of designing templates, "text"
would seem to make sense here, as this is really what is intended. If
the interface is supposed to help designers, the TeX token concept is
not necessarily helping much.
\MultiSelection has not been moved to xtemplate from template. That is
because it'd not clear quite what to do yet. The general question is how
to make one key depend in some way on another. Frank suggested some
- set the vertical space between items of a list depending on the list
context (i.e., the list depth) -> that is an index like spec
- set the vertical space before a heading to X except when the heading
is immediately preceded by another heading (in which case use Y) but
use Z if the heading falls on the top of a new page -> that is not an
index like spec
- set some length to the max of X and the current value of variable V
taken from the context of the instance
So something that uses an index is one possibility, but only covers some
scenarios. The question is therefore what situations need support at the
level of xtemplate (as opposed to being handled in the code part of a
The collections idea is currently probably not quite right. A while ago,
'What exactly should collection instances be used for? I'm starting to
question how much use they actually provide as they offer exactly one
level of variance and often you would have several layers, e.g., would
"frontmatter", "mainmatter", "backmatter" be good candidates for
collections? So that, for example, pagestyles behave differently in
those places? But then this should also influence the way headings are
set (would be possible) and in the way page numbers are displayed (more
difficult perhaps). And what happens if somebody else come up with a
different type of collection, e.g., making "minipage" a collection to
change behaviour or stuff inside. Then who wins? And why?'
and that still applies. As collections are about design, I can't myself
see how more than one can be in force at any time, but can see the
problem of keeping things in sync. The code currently sticks close to
the original template concept, but this probably needs to change.
The argument order of some of the functions probably needs rethinking.
This will probably have to be decided after other stuff is sorted out!
Thoughts on any part of (x)template very welcome. It's clear that some
problems will have to be revisited as more use is made of templates: we
can't hope to know everything now!