Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[Marc Hohl]

Am 06.10.2012 11:23, schrieb Janek Warchoł:
> On Fri, Oct 5, 2012 at 9:42 PM, Thomas Morley
> <address@hidden> wrote:
> > 2012/10/5  <address@hidden>:
> > > It just occured to me: is there any way to specify different span bar
> > > lines (at the end of the line and at the beginning of the line)?
> > Marc and me, we discussed this some time ago and decided not to
> > provide that functionality.
> > It would make things more complicated for the user and I think it is a
> > rarely needed feature.
> Sorry for missing that part of the discussion.
> If it's not too late to speak my mind, i think that it would be a
> shame to have such an awesome and powerful barline interface without
> giving users simple way to choose span barline behaviour.
Thinking *a lot* more about that and trying to recode my work to
fit your needs I stumbled upon quite a lot of problems:

The internal structure of the properties and its names does not
allow for this extension in a clean way. We have BarLine #'glyph
(that's the string given by the user) and BarLine #'glyph-name
(which is the string for the bar line to be drawn, i.e. after line
breaking decisions).
We have SpanBar #'glyph-name which is computed by
ly:span-bar::calc-glyph-name and the glyph-name we use here
will be that of the corresponding bar line, because we need both
informations about the bar line and the span bar line to get
the spacing correctly.

If I store a span bar triple '(span-bar-glyph end-of-line begin-next-line),
I'll have to carry the whole direction computation stuff in almost
every callback, and moreover, ly:span-bar::calc-glyph-name would
either return a list or the BarLine #'glyph, not the #'glyph-name,
so to be 100% clean, one would have to rename the property into
SpanBar#'glyph-list or SpanBar #'glyph.

Just a side remark: have a look at scm/define-grob-properties.scm.
(glyph-name ,string? "The glyph name within the font.") Huh?
(At least there is some clarification on this issue included in my patch ;-)

Being realistic, there are two possibilities:
a) I just leave the span bar stuff as it is. If it turns out that one 
wants to
change the appearance of span bars depending on the line breaking,
he has to write a custom callback similar to Harm's proposal or has to
rewrite parts of the interface again.
b) I try to get this done in a concise and clean way. This will probably 
take
half a year (just an assumption based on the time I spent on the patch
upto now and the estimated time available for lilypond) – probably I will
fail, but even if not: is it worth the effort? Who needs such span bars?

If no-one convinces me to do otherwise, I'll take (a).

Regards,

Marc