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
Show All Mail Headers

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

Print Reply
Subject:
From:
Joseph Wright <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Sun, 8 Nov 2009 17:07:24 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (94 lines)
Hello everyone,

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 
moment).

 =======================================================================

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 
"stories":

  - 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 
template).

The collections idea is currently probably not quite right. A while ago, 
Frank said:

'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!
--
Joseph Wright

ATOM RSS1 RSS2