On 05/01/2011 18:42, Frank Mittelbach wrote:
> What I have in mind are primarily rules, specified not by giving absolute
> length but rather specifying the end points in relation to the coffin handles.
> A more or less natural extension of this would be something like "leaders" the
> way TeX defines them, or a variation of that. But perhaps that is already too
> much and rules are enough. 
> I don't think that it is right to try to turn the concept of coffins into some
> sort of general purpose graphics language, ie. really complicated things are
> probably better done differently but it would be nice if the more common
> layouts could be easily decribed in this way and right now at least the rules
> seems to me something that is clearly necessary.
> But is there anything else you feel would be essential? And if so what?
> Also, what kind of paramerization would be suitable for such objects (again
> thinking about what is commonly needed and not so much what would be
> theoretically possible in some arcane setup)?

I'd been thinking about this, and it lead me back to some comments on
the more general point about optional arguments.

Currently, we're using positional optional arguments for the coffin
functions, for example

  \JoinCoffins *
    \<coffin1> [ <coffin1-pole1> , <coffin1-pole2> ]
    \<coffin2> [ <coffin2-pole1> , <coffin2-pole2> ]
    ( <x-offset> , <y-offset> )

A good case can be made for reducing the use of arguments in this way
and moving to key-value syntax. I quite like the requirement for the
mandatory items to be separate arguments, but can see that something like:

  \JoinCoffins *
      coffin1-pole1 = <value> ,
      coffin1-pole1 = <value> ,
      coffin2-pole2 = <value> ,
      coffin2-pole2 = <value> ,
      x-offset      = <value> ,
      y-offset      = <value> ,
    \<coffin1> \<coffin2>

might be a better long-term approach. I've assumed that we'd keep the
optional stuff as optional overall but in one argument, and that the '*'
still makes sense here (an alternative would be 'expand-bounding-box' or
similar as a Boolean). I'm also assuming that two arguments for each
handle is better than

    coffin1-handle = { <pole1> , <pole2> } ,

as at this stage I want to highlight the general point. (I'm not overly
keen on requiring braces in the key-value list if there is an
alternative which is also clear.)

The reason this is relevant to rules is that there are a number of
parameters that come to mind. A rule needs to be placed relative to a
coffin, which as with other alignments may need a handle on the coffin
and an offset. At the rule end, we may need the colour of the rule and a
handle on the rule for the alignment. We also need dimensions for the
rule, but these might want to be relative or absolute. The bounding box
for the coffin may need to expand or may be conserved. Out of this list,
the only absolute requirement is the coffin name. So a key-value list
would seem much more reasonable than optional arguments

  \AddRuleToCoffin *
      absolute-width  = <value> ,
      absolute-height = <value> ,
      coffin-pole1    = <value> ,
      coffin-pole2    = <value> ,
      color           = <value> ,
      color-model     = <value> ,
      relative-width  = <value> ,
      relative-height = <value> ,
      rule-pole1      = <value> ,
      rule-pole2      = <value> ,
      x-offset        = <value> ,
      y-offset        = <value> ,

Obviously, there may need to be some adjustment to the keys. For
example, my model above assumes that absolute and relative dimensions
are given separately, whereas you could have just 'height' and 'width'
with a 'absolute-dimensions' Boolean (I think this might be less clear).
The same arguments about '*' and poles versus handles apply here as with
\JoinCoffins, etc.

The general point for me is that if you want this flexibility for rules
then I think you need a similar interface for the rest of the coffins
module. I also note that it would be possible to extend this approach to
leaders by making rules a special case of a more general
\AddLeadersToCoffin function. (Function names may of course need some
work too!)
Joseph Wright