Hi all,
First of all, I don't want to steer the discussion away from Werner's
original question. I'd just like to share a few thoughts in the hope
that they might inspire a broader discussion.
Werner's question made me wonder whether there might be a more general
architectural topic behind this particular engraving issue.
As far as I understand, formats such as MEI (and perhaps Finale
internally) are able to preserve not only the musical semantics but also
layout information. This made me wonder whether it would be useful for
LilyPond to expose the final layout of each Grob after the layout
process through a stable rendering cache or API.
Such a representation could, for example, provide the final position,
bounding box, color, and other layout properties of every Grob. If these
properties could also be overridden before the final output is
generated, it might solve not only special engraving problems like slurs
ending at a bar line, but also support a number of other use cases.
For example:
* musicological editions that align LilyPond output with scans of
historical manuscripts,
* preserving layout information when importing formats such as MEI,
* future importers from projects such as Robert Patterson's Finale DOM,
* interactive editors that need access to the final graphical
representation,
* educational material where corresponding musical objects are
intentionally kept vertically aligned across several systems or
examples, even if LilyPond would normally space them differently.
Perhaps Point-and-Click already computes or stores much of this
information internally. If so, would it make sense to expose it through
a stable interface?
I realize that this is a much broader topic than the current discussion.
I am not proposing a particular implementation. I am simply wondering
whether a general layout layer could address several seemingly unrelated
requirements instead of introducing individual solutions for each of them.
I would be very interested to hear whether something along these lines
has been discussed before, or whether there are fundamental reasons why
such an approach would not fit LilyPond's architecture.
Best regards,
Christian
