Re: add general_alignment (issue 2613) (issue 6308093)

[Janek Warchoł]

On Fri, Jun 22, 2012 at 7:41 AM,  <address@hidden> wrote:
> This fails an assertion in scm_or_str2symbol, so I had to recompile with
> NDEBUG

I'm sorry, but i don't recognize what failing an assertion in
scm_or_str2symbol could mean here.  Was this related to bad
docstrings?  (they are fixed now)

>> Nevertheless, it's possible to override X-offset property on the
>>  ly code to use this:
>> \override LyricText #'X-offset =
>>  #(ly:make-simple-closure (ly:make-simple-closure
>>    (list ly:self-alignment-interface::general-x-alignment)))
>
>  .. = #ly:self-alignment-interface::general-x-alignment
> I don t know Scheme, but I see no need to wrap in closures.

Indeed!  Thank you.

> The new property X-alignment will be awkward to use, because it is a
> complex structure of unnamed conceptually-distinct objects.

Unnamed?  What do you mean?  How can i name them?
Concerning user-friendliness: i was going to suggest defining
"aliases" for most commonly used values - just like we can use LEFT
instead of -1.

> As you have built it, a list of pairs, I can do things like
>  \override LyricText #'X-alignment #'X-extent = #RIGHT
> but I don't think that was intended.

I don't understand - does that override work for you?  When i tried it, i got

  ERROR: In procedure ly:self-alignment-interface::general-x-alignment:
  ERROR: Wrong type (expecting real number): (X-extent . 1)

> The objects in X-alignment could be individually-named properties:
>  self-alignment-X-extent-symbol
>  self-alignment-X (the existing property)
>  parent-alignment-X
>  parent-self-alignment-X-extent-symbol
>  extra-X-offset
>
> Will all of these be independently useful ?

I don't think so, and they would horribly "clutter the view" (for
example, Frescobaldi hints what properties of a particular object can
be overridden - i use this sometimes).

> I would like to see how this solves some engraving challenges, without
> hand-calculation of the key numbers, before you push the C code.

Here you are:
- issue 2451: punctuation can be detected automatically, setting
X-core-extent accordingly,
- issue 2452: a special character could be used by the user to tell
the "prefix" apart from the core of the syllable (e.g. z&nim instead
of "z nim"), and with this information it'll be easy to automatically
calculate core-extent,
- issue 2245: it would be possible to easily choose whether objects
like dynamics should be aligned only to the "main" note column (i.e.
w/o suspended notes), or should the suspended notes be included - just
include the suspended heads in outer-extent, and not in core-extent
(easy to do automatically) and choose which extent you align to.
- alignment of bass clef ottavation:
http://lilypond-stuff.1065243.n5.nabble.com/file/n5705593/clef-ottavation.png
- alignment of music glyphs and text in markup:
http://lilypond-stuff.1065243.n5.nabble.com/file/n5705593/text-and-music-glyphs-in-markup.png
- alignment of markups containing scores:
http://lilypond-stuff.1065243.n5.nabble.com/file/n5705593/align-score-markups.png
- we had some problems with spanner bounds (issue 620, issue 2532): i
think my approach might help here (i haven't investigated it closely,
though).

I hope these examples are explained clear enough.

> There will be a difficult convert-ly rule to write, if you have
> general_alignment() in the 2.16 source, but then need to change the
> interface.

Ok, let's not push this until i actually use new alignment
possibilities in my lyrics issues and/or change existing code to use
it.

cheers,
Janek