Re: slurs anchored at bar lines

Hi all,

First of all, I don't want to steer the discussion away from Werner's=20
original question. I'd just like to share a few thoughts in the hope=20
that they might inspire a broader discussion.

Werner's question made me wonder whether there might be a more general=20
architectural topic behind this particular engraving issue.

As far as I understand, formats such as MEI (and perhaps Finale=20
internally) are able to preserve not only the musical semantics but also=
=20
layout information. This made me wonder whether it would be useful for=20
LilyPond to expose the final layout of each Grob after the layout=20
process through a stable rendering cache or API.

Such a representation could, for example, provide the final position,=20
bounding box, color, and other layout properties of every Grob. If these=
=20
properties could also be overridden before the final output is=20
generated, it might solve not only special engraving problems like slurs=
=20
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=20
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=20
representation,
* educational material where corresponding musical objects are=20
intentionally kept vertically aligned across several systems or=20
examples, even if LilyPond would normally space them differently.

Perhaps Point-and-Click already computes or stores much of this=20
information internally. If so, would it make sense to expose it through=20
a stable interface?

I realize that this is a much broader topic than the current discussion.=
=20
I am not proposing a particular implementation. I am simply wondering=20
whether a general layout layer could address several seemingly unrelated=
=20
requirements instead of introducing individual solutions for each of them.

I would be very interested to hear whether something along these lines=20
has been discussed before, or whether there are fundamental reasons why=20
such an approach would not fit LilyPond's architecture.

Best regards,

Christian