LATEX-L Archives

Mailing list for the LaTeX3 project


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
Joseph Wright <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Wed, 23 Mar 2011 21:23:01 +0000
text/plain (51 lines)
Hello all,

A while ago, we updated the coffins module to move toward something
generally useful. At the time, one of the open questions was the correct
design-level interface. The most obvious question is how to handle
\JoinCoffins, which currently has syntax

  \JoinCoffins *
    \<CoffinA> [ <coffinA-pole1> , <coffinA-pole2> ]
    \<CoffinB> [ <coffinB-pole1> , <coffinB-pole2> ]
    ( <xoffset> , <yoffset> )

where only the two coffin names are mandatory arguments. That works
quite well, but relies on the concept of position-dependent optional
arguments that is used a lot by LaTeX2e, and which is not really ideal
for complex cases. An alternative which was suggested was some form of
key-value approach.

I've now implemented a key-value interface for \JoinCoffins:

  \JoinCoffins [
    % Key names with default values
    coffin1-hpole     = H    ,
    coffin1-vpole     = l    ,
    coffin2-hpole     = H    ,
    coffin2-vpole     = l    ,
    grow-bounding-box = true , % Optional alone equal to "true" version
    hoffset           = 0 pt ,
    voffset           = 0 pt ,
  ] \<CoffinA> \<CoffinB>

where I hope most of the key names are obvious (grow-bounding-box takes
the place of the * argument). At the moment, this is implemented in
xcoffins such that you can use either input syntax, with the keyval
method being checked first (so if the first argument starts "[" then any
other optional arguments are ignored). I've not altered the
documentation as this is very much experimental; for the same reason,
I've only done this for \JoinCoffins and not for any of the other coffin
functions which have optional arguments. If you want to see the keyval
approach in action, I've added a modified version of Frank's test
(xcoffins-tschichold-example-keyval.tex) to the SVN.

So the question is "Does this look any good?". It's clearly more wordy
than the 'multiple optional argument' interface which we've already got.
On the other hand, named arguments are in general considered to be 'a
good thing'. The syntax here is intended for _design_ material, not for
typing out every other line in a document, so I can see an argument for
something 'self documenting'.
Joseph Wright