[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [LSR] Ready-to-use LilyPond macros: advanced layout and titles, usin

From: David Kastrup
Subject: Re: [LSR] Ready-to-use LilyPond macros: advanced layout and titles, using a special stylesheet
Date: Wed, 14 Oct 2015 13:21:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Thomas Morley <address@hidden> writes:

> 2015-10-14 10:17 GMT+02:00 Pierre Perol-Schneider
> <address@hidden>:
>> I'd suggest to simply delete the 'vspace' defs in "book-titling.ily"
> Well, the coding is different, causing different results.
> Look at the output from:
> \version "2.18.2"
> #(define-markup-command (vspace-lsr layout props amount) (number?)
>   "This produces a invisible object taking vertical space."
>   (let ((amount (* amount 3.0)))
>     (if (> amount 0)
>         (ly:make-stencil "" (cons -1 1) (cons 0 amount))
>         (ly:make-stencil "" (cons -1 1) (cons amount amount)))))
> \markup
>   \box
>   \line  {
>     "lsr-def: " \box \column { A \vspace-lsr #-5 B }
>     "source-def: " \box \column { A \vspace #-5 B }
>   }
> In said snippet only positive numbers are used, thus no big
> difference.

LilyPond's definition of vspace was once similar to the one in the LSR
but isn't anymore (issue 3330).  The old definition creates an object
that gets padding on both sides, and \hspace (but not \vspace I think)
tried compensating for it but often predicted the value it needed to
compensate for wrong.  Even then, negative vspaces did not work well.
The new definition has an empty X-extent which is recognized by the
spacing engine as _not_ marking an object.  Consequently, \vspace #0
does not add padding or line spacing or other stuff, and negative and
positive values work smoothly starting from there.

> I'm more or less undecided. Admittedly, using negative numbers will
> circumvent calculated extents. Bug or feature?

Issue 3330 clearly is intentional.  In particular, it strove hard to
make spacing and vspace/hspace more predictable and reliable.  There is
also some convert-ly rule to counter for \vspace no longer adding

The LSR version of vspace (when was this ever a good idea?) by now has
markedly diverged from the built-in variant, so it really should get
removed and its effect compensated.

So it might make sense to run

convert-ly -f 2.17.18 -t 2.17.19

on the LSR snippet (though it's possible that this has already been done
once and should not be repeated) before throwing out its own vspace

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]