Re: [LSR] Ready-to-use LilyPond macros: advanced layout and titles, using a special stylesheet

[David Kastrup]

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

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

-- 
David Kastrup