LilyIssues / Issues / #4022 Patch: Allow specifying different alignment for grob and its parent

Google Importer - 2014-07-20

Originally posted by: janek.li...@gmail.com

(No comment was entered for this change.)

Owner: janek.li...@gmail.com

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-20

Originally posted by: pkx1...@gmail.com

Patchy the autobot says: passes tests. Includes a full make doc

Labels: -Patch-new Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-20

Originally posted by: janek.li...@gmail.com

address Werner's comments

http://codereview.appspot.com/118950043

Labels: -Patch-review Patch-new

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-20

Originally posted by: janek.li...@gmail.com

(No comment was entered for this change.)

Blocking: lilypond:3186

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-21

Originally posted by: pkx1...@gmail.com

Patchy the autobot says: passes tests.

Labels: -Patch-new Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-21

Originally posted by: pkx1...@gmail.com

Patchy the autobot says: passes tests. Includes a full make doc

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-24

Originally posted by: janek.li...@gmail.com

(No comment was entered for this change.)

Labels: -Patch-review Patch-needs_work

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-26

Originally posted by: janek.li...@gmail.com

add regtest

http://codereview.appspot.com/118950043

Labels: -Patch-needs_work Patch-new

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-26

Originally posted by: janek.li...@gmail.com

fix comment

http://codereview.appspot.com/118950043

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-26

Originally posted by: pkx1...@gmail.com

OK something broke since your last two updates to the patch.

fails make check so I am guessing it's your reg test addition?

--snip--
Please check the logfile collated-files.texilog.log for errors

...

james@james-OptiPlex-990 /tmp/show-4022$ more ./input/regression/collated-files.texilog.log
*** '{' without macro. Before: '(-1 . 1)} should result in object's left edge (in out-test/separate-al
ignment-factors-for-object-and-parent.texidoc l. 3)
Max error number exceeded

Labels: -Patch-new Patch-needs_work

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-26

Originally posted by: janek.li...@gmail.com

add missing @

http://codereview.appspot.com/118950043

Labels: -Patch-needs_work Patch-new

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-26

Originally posted by: janek.li...@gmail.com

I think i found the problem - thanks for info!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-27

Originally posted by: pkx1...@gmail.com

Patchy the autobot says: passes tests. Includes a full make doc

Labels: -Patch-new Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-27

Originally posted by: janek.li...@gmail.com

Thanks, James!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-27

Originally posted by: dak@gnu.org

Patchy the autobot says: passes tests.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-27

Originally posted by: janek.li...@gmail.com

Thanks, David :)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-30

Originally posted by: pkx1...@gmail.com

Patch on countdown for August 2nd

Labels: -Patch-review Patch-countdown

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-30

Originally posted by: dak@gnu.org

See the proposal/discussion in <URL:https://code.google.com/p/lilypond/issues/detail?id=4036#c10>, proposing separate properties parent-alignment-X and parent-alignment-Y.

After thinking about this, I am pretty convinced that we'll fare better with separate properties. The additional cost of looking up a separate property is acceptable, and it allows us to get rid of a number of different aligned/centered-on-whatever callbacks. In contrast to a number-pair, it also painlessly allows to set either of the properties to #f, reverting to coordinate 0 (the default reference point) for alignment. Having an override of self-alignment-X change only the self alignment while not touching the parent's will also retain the documented functionality of using self-alignment-X for shifting material in position, including material in different sizes. It is important to note that shifting inside of a markup using, say, \translate-scaled will _not_ have any effect (or at least no well-predictable effect) as long as self-alignment-X is not set to ##f.

So all-in-all, I think we want separate properties and independent overridability for self-alignment-X and parent-alignment-X.

The discussion on that is currently postponed for a few days to get into calmer waters. Since it would not make sense for this issue to go ahead while we have not had a chance to discuss a more suitable general approach or solution, I am putting this issue back on review for now.

Labels: -Patch-countdown Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-30

Originally posted by: janek.li...@gmail.com

Having separate properties indeed makes sense. Let me just say why I have favored one property: I wanted to make it simple to change both alignments to the same number, and I wanted to maintain backward compatibility in case of Lyrics. For example, if we have

{ d'1 }
\addlyrics { laaaa }

both default alignments are CENTER. If the user writes \override LyricText.self-alignment-X = #LEFT, he gets a left-aligned syllable (like in melismas). If we have two separate properties, \override LyricText.self-alignment-X = #LEFT will have different (and probably quite surprising) output than now.

Do you have some idea on how we could mitigate these problems?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-30

Originally posted by: janek.li...@gmail.com

David Kastrup wrote:
> It is important to note that shifting inside of a markup using,
> say, \translate-scaled will _not_ have any effect (or at least
> no well-predictable effect) as long as self-alignment-X is not
> set to ##f.

Could you please elaborate? I don't understand at all. In fact, i don't even understand the purpose of \translate-scaled - I found it in NR and tried writing an example, but it seemed to behave exactly like \translate.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-30

Originally posted by: dak@gnu.org

\translate-scaled is like \translate when font-size is 0. But if you scale up a font, the translation of \translate-scaled also scaled. Important for assembling compound glyphs like accordion symbols.

Shifting some markup around on itself does not change anything when self-alignment-X is a number since that number means that the reference point will be calculated relative to left and right edge anyway.

If you state "If we have two separate properties, \override LyricText.self-alignment-X = #LEFT will have different (and probably quite surprising) output than now." seems exaggerated to me since I think "now" means "for version 2.19.10 or later".

Depending on the callbacks we change, we might need to write corresponding convert-ly rules. But I think that we would still be closer to 2.19.9 behavior than 2.19.10 without losing the _abilities_ of the latter. And the behavior should be easier to understand: currently self-alignment-X shows a number of quite different behaviors depending on the callback in use, and weeding those out will make things simpler.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-30

Originally posted by: k-ohara5...@oco.net

> If we have two separate properties,
> \override LyricText.self-alignment-X = #LEFT will have different
> (and probably quite surprising) output than now.
>
Up to now, that override aligns the left edge of the lyric with the left edge of the note.
LyricText is the /only/ object that uses aligned-on-x-parent, which moves reference points on both the object and parent.

For all other objects Grob.self-alignment-X = #Q changes the point Q on Grob that is aligned to some fixed point on the parent, that fixed point being chosen in various different mysterious ways for each Grob.

> Do you have some idea on how we could mitigate these problems?

Let aligned-on-x-parent interpret
'parent-alignment-X = ##f
as "please use the same value as for self-alignment-X" (similarly to your current patch)
and define LyricText.parent-alignment-X = ##f

For all the other Grob types, if and when you change their default X-offset to
self-alignment-interface::aligned-on-parent, also define their 'parent-alignment-X
to #CENTER or #LEFT so as to match the former behavior.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-31

Originally posted by: janek.li...@gmail.com

@David:
> \translate-scaled is like \translate when font-size is 0. But if you
> scale up a font, the translation of \translate-scaled also scaled.
> Important for assembling compound glyphs like accordion symbols.

Ah, i see now. \translate-scaled is used for moving one part of a markup relative to another one, not the whole markup. It's hard to see that from the documentation example, and the output of the documentation example looks virtually the same for \translate and \translate-scaled.

@Keith:
> Let aligned-on-x-parent interpret
> 'parent-alignment-X = ##f
> as "please use the same value as for self-alignment-X" (similarly to
> your current patch) and define LyricText.parent-alignment-X = ##f
>
> For all the other Grob types, if and when you change their default X-offset to
> self-alignment-interface::aligned-on-parent, also define their 'parent-alignment-X
> to #CENTER or #LEFT so as to match the former behavior.

This makes sense. However, I think i would prefer using another special value for such behavior, and let parent-alignment-X = ##f mean a similar thing as self-alignment-X = ##f (i.e. "align on reference point of respective object").

That's because there are situations when the reference point does carry some useful information (i.e. it's neither simply on the left or in center) - for example in case of fretboard diagrams.

An even better example: note heads. Most of them have refpoint on their left edge, but the breve and longa are different (see attached). What's important is that the refpoint is where the notehead is attached to the musical moment (i.e. PaperColumn, shown with blue line here). So, we want to be able to align things like LyricTexts on that very refpoint.

fretboard-refpoint.png

notehead-refpoint.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-31

Originally posted by: dak@gnu.org

I think that parent-alignment-X = ##f should be strictly reserved for letting the reference point (0) of the parent come through like it does for InstrumentName.self-alignment-Y = ##f in incipits.

For LyricText I see two approaches: parent-alignment-X = #'() as an indicator for shadowing self-alignment-X, or using a different callback for offset-X altogether. The latter is apparently what we have as of 2.18.

At any rate, I am not convinced that the alignment parent is chosen optimally in cases like
{ \override NoteHead.font-size = 8
<c cis ces d dis des> q q q
} \addlyrics {
\override LyricText.self-alignment-X = #LEFT
One
two
\override LyricText.self-alignment-X = #RIGHT
three
four
}

It would appear to me that the parent should not be a particular notehead but more likely something comprising several of them. NoteColumn? Just guessing here.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-07-31

Originally posted by: janek.li...@gmail.com

@David (comment 24): this is actually a feature, see issue 2245. And (suprise! ;P) the behaviour can be changed using X-align-on-main-noteheads:

{ \override NoteHead.font-size = 8
<c cis ces d dis des> q q q
} \addlyrics {
\override LyricText.X-align-on-main-noteheads = ##f
\override LyricText.self-alignment-X = #LEFT
One
two
\override LyricText.self-alignment-X = #RIGHT
three
four
}

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Patch: Allow specifying different alignment for grob and its parent

Issue Tracker for LilyPond

Searches

Help

#4022 Patch: Allow specifying different alignment for grob and its parent

Discussion