Re: convert-ly rule

[address@hidden]

On 13 mars 2013, at 11:56, David Kastrup <address@hidden> wrote:

> "address@hidden" <address@hidden> writes:
> 
>> On 13 mars 2013, at 11:00, David Kastrup <address@hidden> wrote:
>> 
>>> It might also be possible to let a callback check for the existing
>>> grob interfaces in possible cases of contention and only use the
>>> respective value if the grob had the proper interface.
>>> 
>>> So you'd have a callback that only looked at staff-padding in the
>>> tuplet-bracking-interface manner if the grob had that interface, and
>>> would look at it in the side-position-interface manner only if the
>>> grob had _that_ interface.
>>> 
>>> That would require giving grobs a set of interfaces that interpret
>>> any given property only in one manner.
>> 
>> Then that would mean that the tuplet bracket could never use side
>> position interface and vice versa.
> 
> Yes.  The set of interfaces is not user-changeable as far as I know.  So
> this would hamper the system programmers regarding the possible
> interface choices rather than the users.
> 
> Not fabulous, but I have a hard time at the current point of time coming
> up with something that does not either have significant naming
> redundancy and awkwardness, or is lacking flexibility.  At least when it
> is supposed to fit more or less with the current scheme of things.

Makes sense.

In my work with eliminating the translate_axis call, then, I'd need to create 
an:

outside-staff-interface

For all grobs that can be positioned outside the staff.  That way TupletBracket 
could be part of this without having bleedover from the 
side-position-interface's use of staff-padding.  It'd require adding a new 
interface to a lot of grobs, but it actually adds a lot of clarity, as in the 
documentation we can indicate that the internals reference shows all grobs that 
can be outside-staff positioned via this interface.

Cheers,
MS