LATEX-L Archives

Mailing list for the LaTeX3 project


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
Mailing list for the LaTeX3 project <[log in to unmask]>
Mon, 1 Feb 2010 22:43:46 +0100
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=us-ascii
Frank Mittelbach <[log in to unmask]>
text/plain (48 lines)
Joseph writes:

 > Currently, we have "length" (for a fixed length) and "skip" (for a 
 > rubber length), but nothing which will map to an underlying muskip. I'm 
 > not actually sure we should at the design level 
 > (\DeclareTemplateInterface) but at the code level (\DeclareTemplateCode) 
 > there needs to be some thought. Possibilities:
 >   - Introduce a new key type (mathskip ?)
 >   - Use a keyword in the code section, as we already do for "global":
 >      keyname1 = math \l_my_muskip       ,
 >      keyname2 = global math \g_my_muskip,
 >      keyname3 = global \g_some_other_var,
 >      ...
 >   - Assume that this is rare enough to use a token list to store in
 >     input, and sort out the conversion in the code.
 > Thoughts? At present, (3) is all that is on offer, but perhaps that is 
 > all we need (do designers care about muskips at all?).

your last question perhaps depends on whether or not there is going to be a
lot of "templates" for math objects which I somehow doubt, mainly because most
such objects will not need a "designer interface" supporting a number of
possible layouts for some object. But I might be wrong.

For non-math objects I don't think that muskips play any role or should play
any role.

From your three options above I don't like option (2) at all --- such a
keyword looks like it can be applied to or combined with others and that isn't
really the case and it isn't the right kind of syntax/semantics. After all the
type is defined on the interface side not on the code side (even though the
code side actually uses a matching storage bin

(1) is my favorite as it is clean and fits the rest of the types.

As you say to implement that it would probably need an underlying support for
muskips as code level types, but you can start by simply having this type
accepting a tokenlist and you deal with it internally for the moment. That
could then later be changed to use whatever the kernel then offers as type

just some initial thoughts