gmane.comp.gnu.lilypond.general

Graham Percival | 30 Nov 16:07

Picon

Re: horizontally centering denominator in compound time signatures

On Sun, Nov 30, 2008 at 12:41:46AM +0100, Reinhold Kainhofer wrote:
> Now, in my first step, I'm implementing the display of (1+2+3)/8 fractions. My 
> only problem with this is that with the methods shown in the LSR snippets the 
> 8 is always left-aligned and not centered between the 1+2+3. How can I do 
> this?

You're going to kick yourself for this... :)

s/make-column-markup/make-center-column-markup

Now that said, this causes the 1+2+3 to collide with the clef.
I'm not certain why, but you can probably work around it by
setting X-offset manually.

Incidentally, I still prefer my version:
http://lists.gnu.org/archive/html/lilypond-user/2008-10/msg00681.html
since the markup is constructed in close-to-normal lilypond markup
language.  It would be fairly simply to change that function to
use a centered column and no parentheses.

Incidentally*2, I think there's enough interest in compound time
signatures that we should add it to the main lilypond.  There's a
lot of different styles (just compare yours with mine!), though,
so we'd need a #'style property to pick the desired one.  I'm not
certain how to go about doing that.

Cheers,
- Graham

Reinhold Kainhofer | 30 Nov 17:14

Re: horizontally centering denominator in compound time signatures

Am Sonntag, 30. November 2008 16:07:39 schrieb Graham Percival:
> On Sun, Nov 30, 2008 at 12:41:46AM +0100, Reinhold Kainhofer wrote:
> > Now, in my first step, I'm implementing the display of (1+2+3)/8
> > fractions. My only problem with this is that with the methods shown in
> > the LSR snippets the 8 is always left-aligned and not centered between
> > the 1+2+3. How can I do this?
>
> You're going to kick yourself for this... :)
>
> s/make-column-markup/make-center-column-markup

Ah, thanks. I was grepping for make, column and markup in the lilypond 
sources, but since the make-*-markup commands are generated on the fly, of 
course I didn't find it...

> Now that said, this causes the 1+2+3 to collide with the clef.
> I'm not certain why, 

It seems that make-center*-markup only sets the correct extents to the right, 
but not to the left (which is apparently set to 0...).

> but you can probably work around it by
> setting X-offset manually.

Actually, I can't, since this is 1) supposed to be a general solution to 
complex time signatures and 2) supposed to be used by musicxml2ly, too.

> Incidentally, I still prefer my version:
> http://lists.gnu.org/archive/html/lilypond-user/2008-10/msg00681.html

(Continue reading)

Neil Puttock | 30 Nov 17:30

Picon

Re: horizontally centering denominator in compound time signatures

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

> It seems that make-center*-markup only sets the correct extents to the right,
> but not to the left (which is apparently set to 0...).
>
>> but you can probably work around it by
>> setting X-offset manually.

Try this:

\override Staff.Clef #'(space-alist time-signature) = #'(extra-space . 1.2)

Regards,
Neil

Reinhold Kainhofer | 30 Nov 17:50

Re: horizontally centering denominator in compound time signatures


Am Sonntag, 30. November 2008 17:30:06 schrieb Neil Puttock:
> 2008/11/30 Reinhold Kainhofer <reinhold <at> kainhofer.com>:
> > It seems that make-center*-markup only sets the correct extents to the
> > right, but not to the left (which is apparently set to 0...).
> >
> >> but you can probably work around it by
> >> setting X-offset manually.
>
> Try this:
>
> \override Staff.Clef #'(space-alist time-signature) = #'(extra-space . 1.2)

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...

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

Cheers,
Reinhold
--

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinhold <at> kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer

(Continue reading)

Neil Puttock | 30 Nov 19:06

Picon

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

Neil Puttock | 30 Nov 19:11

Picon

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."

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)

Neil Puttock | 30 Nov 20:48

Picon

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

Neil Puttock | 30 Nov 22:16

Picon

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)

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)

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)

Neil Puttock | 1 Dec 01:06

Picon

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

Reinhold Kainhofer | 30 Nov 21:52

Re: horizontally centering denominator in compound time signatures


Am Sonntag, 30. November 2008 17:50:41 schrieb Reinhold Kainhofer:
> Am Sonntag, 30. November 2008 17:30:06 schrieb Neil Puttock:
> > 2008/11/30 Reinhold Kainhofer <reinhold <at> kainhofer.com>:
> > > It seems that make-center*-markup only sets the correct extents to the
> > > right, but not to the left (which is apparently set to 0...).
> > >
> > >> but you can probably work around it by
> > >> setting X-offset manually.
> >
> > Try this:
> >
> > \override Staff.Clef #'(space-alist time-signature) = #'(extra-space .
> > 1.2)
>
> 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...
>
> So, this is a general problem with the general-column scheme function...

Following up the mails on lilypond-user, I can now confirm that the \center-
column markup command has an issue with the extents of the stencil it returns. 
It seems that the returned markup ignores all extents left of its center, so 
the first half of the column-markup will overlap with previous markups. A 
simple test case is attached:

(Continue reading)

Mats Bengtsson | 30 Nov 23:16

Picon

Picon

Re: horizontally centering denominator in compound time signatures

Quoting Reinhold Kainhofer <reinhold <at> kainhofer.com>:

>> So, this is a general problem with the general-column scheme function...
>
> Following up the mails on lilypond-user, I can now confirm that the \center-
> column markup command has an issue with the extents of the stencil it 
> returns.
> It seems that the returned markup ignores all extents left of its center, so
> the first half of the column-markup will overlap with previous markups. A
> simple test case is attached:
>
> \markup \line {
>     \center-column { \line {a b} \line {c} }
>     \vcenter {"+"}
>     \center-column { \line {a b} \line {c} }
> }

Isn't the problem you describe here, rather the same as what I 
described below "One final detail" at 
http://lists.gnu.org/archive/html/lilypond-user/2008-08/msg00593.html?

   /Mats

Reinhold Kainhofer | 30 Nov 23:33

Re: horizontally centering denominator in compound time signatures


Am Sonntag, 30. November 2008 23:16:50 schrieb Mats Bengtsson:
> Quoting Reinhold Kainhofer <reinhold <at> kainhofer.com>:
> >> So, this is a general problem with the general-column scheme function...
> >
> > Following up the mails on lilypond-user, I can now confirm that the
> > \center- column markup command has an issue with the extents of the
> > stencil it returns.
> > It seems that the returned markup ignores all extents left of its center,
> > so the first half of the column-markup will overlap with previous
> > markups. A simple test case is attached:
> >
> > \markup \line {
> >     \center-column { \line {a b} \line {c} }
> >     \vcenter {"+"}
> >     \center-column { \line {a b} \line {c} }
> > }
>
> Isn't the problem you describe here, rather the same as what I
> described below "One final detail" at
> http://lists.gnu.org/archive/html/lilypond-user/2008-08/msg00593.html?

Yes, exactly the same problem as with the right-align...

Cheers,
Reinhold
--

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinhold <at> kainhofer.com, http://reinhold.kainhofer.com/

(Continue reading)

Reinhold Kainhofer | 11 Dec 02:17

Re: horizontally centering denominator in compound time signatures


Am Sonntag, 30. November 2008 16:07:39 schrieb Graham Percival:
> Incidentally*2, I think there's enough interest in compound time
> signatures that we should add it to the main lilypond.

I have now found a nice workaround for my problems with the center-column-
markup: Simply wrap a left-column-markup around to offset the shifted 
reference point...

Here is my current version, where only the proper auto-beaming settings are 
missing. What do you think is the best way to add something like this directly 
to lilypond?
http://www.fam.tuwien.ac.at/~reinhold/temp/time_sigs.pdf
http://www.fam.tuwien.ac.at/~reinhold/temp/time_sigs.ly

Cheers,
Reinhold

--

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinhold <at> kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

Return

Return to gmane.comp.gnu.lilypond.general.

Advertisement

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane