gmane.comp.gnu.lilypond.general

Neil Puttock | 30 Nov 19:06

Re: horizontally centering denominator in compound time signatures

2008/11/30 Reinhold Kainhofer <reinhold <at> kainhofer.com>:

> It's actually not a problem of spacing between the clef and the time
> signature, but rather a problem with make-center-column-markup, which ignores
> the left extents. for example, it also breaks for 2/4 + (2+3)/8. The second
> fraction will overlap with the first +, because the extents left to the center
> of the (2+3)/8 fraction will be totally ignored. In other words, the center of
> the (3+2)/8 fraction will be where its left edge should be...

As far as I can see, if you have centred columns in a line, the
problem appears to be that while each element in a column is aligned
to its centre, it's also aligned to the centre of the previous column.

A workaround is to \left-align each centred column.

> So, this is a general problem with the general-column scheme function...

Perhaps there's a bug in stack-lines?

Regards,
Neil

headers

Neil Puttock | 30 Nov 19:11

Re: horizontally centering denominator in compound time signatures

2008/11/30 Neil Puttock <n.puttock <at> gmail.com>:

> it's also aligned to the centre of the previous column.

Sorry, this should read: "each column is aligned to the centre of the
previous column."

headers

Reinhold Kainhofer | 30 Nov 19:54

Re: horizontally centering denominator in compound time signatures


Am Sonntag, 30. November 2008 19:06:09 schrieb Neil Puttock:
> 2008/11/30 Reinhold Kainhofer <reinhold <at> kainhofer.com>:
> > It's actually not a problem of spacing between the clef and the time
> > signature, but rather a problem with make-center-column-markup, which
> > ignores the left extents. for example, it also breaks for 2/4 + (2+3)/8.
> > The second fraction will overlap with the first +, because the extents
> > left to the center of the (2+3)/8 fraction will be totally ignored. In
> > other words, the center of the (3+2)/8 fraction will be where its left
> > edge should be...
>
> As far as I can see, if you have centred columns in a line, the
> problem appears to be that while each element in a column is aligned
> to its centre, it's also aligned to the centre of the previous column.
>
> A workaround is to \left-align each centred column.

Actually, that's not the problem. The problem is that the stencil extents of 
the column ignore everything left of the center of the column, while extents 
to the right are correctly calculated and applied.

If you take a look at
       http://www.fam.tuwien.ac.at/~reinhold/temp/time_sigs.pdf
(where each fraction is a separate make-center-column-markup), you will see at 
the first time signature that the extents to the right of the enter of the 
centered column are calculated correctly. But if you look at the other time 
signatures, you'll notice that the parts of each fraction are correctly 
aligned with each other, but the whole fraction is positioned as if there was 
nothing left of its center. So, my guess is that the extents of the stencil 
for the whole centered column are set to the center as the left edge instead

(Continue reading)

headers

Neil Puttock | 30 Nov 20:48

Re: horizontally centering denominator in compound time signatures

2008/11/30 Reinhold Kainhofer <reinhold <at> kainhofer.com>:

> If you take a look at
>       http://www.fam.tuwien.ac.at/~reinhold/temp/time_sigs.pdf
> (where each fraction is a separate make-center-column-markup), you will see at
> the first time signature that the extents to the right of the enter of the
> centered column are calculated correctly. But if you look at the other time
> signatures, you'll notice that the parts of each fraction are correctly
> aligned with each other, but the whole fraction is positioned as if there was
> nothing left of its center. So, my guess is that the extents of the stencil
> for the whole centered column are set to the center as the left edge instead
> of the real extents...

Ah yes, I see the problem.

> On the other hand, the time sig after measure 6 (the one at the end of the
> line) does NOT overlap with the barline, so somehow the left extents seem to
> work there...

That's because the 'space-alist for BarLine uses 'extra-space instead
of 'minimum-space for time-signature; why this should stop the
collision, I don't know.

Regards,
Neil

headers

Neil Puttock | 30 Nov 22:16

Re: horizontally centering denominator in compound time signatures

2008/11/30 Neil Puttock <n.puttock <at> gmail.com>:

> That's because the 'space-alist for BarLine uses 'extra-space instead
> of 'minimum-space for time-signature; why this should stop the
> collision, I don't know.

Right, I've had a dig around in break-alignment-interface.cc, and I
think I've worked out what's happening here; this is a separate issue
from the overlapping \center-column problem.

Here's the code from Break_alignment_interface::calc_positioning_done ():

      if (r)
	{
	  if (type == ly_symbol2scm ("extra-space"))
	    offsets[next_idx] = extents[idx][RIGHT] + distance
	      - extents[next_idx][LEFT];
	  /* should probably junk minimum-space */
	  else if (type == ly_symbol2scm ("minimum-space"))
	    offsets[next_idx] = max (extents[idx][RIGHT], distance);
	}

If 'extra-space is set for the next grob, its offset from the current
grob is increased by its left extent.  As this suggests, there's no
problem with the left extent here; it's just ignored when
'minimum-space is set.  You can test this by trying to change the car
of 'X-extent: it has no influence on the positioning unless the
space-alist is changed.

Regards,

(Continue reading)

headers

Reinhold Kainhofer | 30 Nov 22:52

Re: horizontally centering denominator in compound time signatures


Am Sonntag, 30. November 2008 19:06:09 schrieb Neil Puttock:
> 2008/11/30 Reinhold Kainhofer <reinhold <at> kainhofer.com>:
> > So, this is a general problem with the general-column scheme function...
>
> Perhaps there's a bug in stack-lines?

I've now done some more digging and understand the situation. I just need some 
info on how things are supposed to work.

Here's the situation:
-) make-center-column-markup (or rather general-column) does 
        (ly:stencil-aligned-to x X align-dir)
   to center-align the markup. This shifts the origin 0 to the horizontal
   center of the markup
-) stack-lines is called on the centered markups, which places the lines one
   above each other and creates a stencil with X-extents (-halfwidth .
   halfwidth), so this part seems to work. 

We now have a stencil with x-extents (-halfwidth . halfwidth)

The problem is when line (which calls stack-stencil-line) comes into play:

-) the stack-stencil-line markup function goes through the markups starting
    from the tail and moves all markups after the currently process by the cdr
   of the x-extents of the stencil:
                 (xoff (+ space (cdr (ly:stencil-extent head X)))))
            (ly:stencil-add head
                             (ly:stencil-translate-axis tail xoff X)))
   The car of the extents (ie. in our case the part of the stencil left of the

(Continue reading)

headers

Reinhold Kainhofer | 30 Nov 23:42

[PATCH] Re: horizontally centering denominator in compound time signatures


Am Sonntag, 30. November 2008 22:52:45 schrieb Reinhold Kainhofer:
> So, basically, there are two solutions:
> 1) Change stack-stencil-line to use the whole extents of the stencil (i.e.
> make it work correctly with stencils where the left edge is not at 0.
> 2) Change center-column to translate the stencil so that 0 lies at the left
> edge.
>
> Thinking about it, I suppose that 1) is the better solution. The only
> reason I see against it is to be able to let a stencil print something
> beyond its left edge. But then, a stencil can always print something beyond
> its extents, so there is no reason to special-case stack-stencil-line. It
> would even make sense to fix this for stencils where the left edge of the
> extent starts at a positive value. Those stencils get translated too much.
>
> What do you think is the correct solution?

I tried out both: 
If I only implement 1), then center-column markups that are not inside a line, 
but rather on their own, are still wrongly aligned (e.g. the first time 
signature in my examples). So 2) is definitely needed to fix this issue.

I've now implemented both:
http://codereview.appspot.com/8687

Comments please!

Cheers,
Reinhold
--

--

(Continue reading)

headers

Neil Puttock | 1 Dec 01:06

Re: [PATCH] Re: horizontally centering denominator in compound time signatures

2008/11/30 Reinhold Kainhofer <reinhold <at> kainhofer.com>:

> I tried out both:
> If I only implement 1), then center-column markups that are not inside a line,
> but rather on their own, are still wrongly aligned (e.g. the first time
> signature in my examples). So 2) is definitely needed to fix this issue.

Are you sure 2) is necessary?  You're effectively compensating for a
problem unrelated to \center-column; as I've pointed out, the issue
for the single-column examples is 'minimum-space.

The changes you've made to stack-stencil-line have done weird things
to fret diagrams and figured bass: fret diagrams are left-aligned with
notes, while figured bass alterations are left-aligned; slashed digits
are left-aligned with the slash.

Regards,
Neil