Issue 4015: Add \magnifyStaff.

* Add \magnifyStaff.
* Rewrite parts of the \magnifyMusic function so that it can share
  some scheme code with the new \magnifyStaff function.
* Add regtests.
* Update documentation.

Issue 4015 on the tracker:
http://code.google.com/p/lilypond/issues/detail?id=4015

[Mark Polesky, 2014-07-16 10:02:52]

Here's a new music function called \magnifyStaff (along the lines of
\magnifyMusic) that scales staff sizes, staff lines, bar lines, beamlets, and
horizontal spacing at the Staff context level.  Staff lines are prevented from
being scaled smaller than the default (and consequently, so are stems, slurs,
etc., since the thickness of each is based on staff lines).  This should improve
the user experience for this task, which is somewhat cumbersome as it stands.

I rewrote the backend to \magnifyMusic so that the two functions could share
some code.  The bulk of the code is in:
  ly/music-functions-init.ly
  scm/music-functions.scm
  scm/define-context-properties.scm

You can see example usages in the modified Documentation files and regtests.

This is issue 4015 on the tracker:
http://code.google.com/p/lilypond/issues/detail?id=4015

Cheers,
Mark

[marc, 2014-07-17 06:10:49]

On 2014/07/16 10:02:52, Mark Polesky wrote:
> Here's a new music function called \magnifyStaff (along the lines of
> \magnifyMusic) that scales staff sizes, staff lines, bar lines, beamlets, and
> horizontal spacing at the Staff context level. 

Just a nitpick: would a renaming to \scaleMusic and \scaleStaff be more
appropriate?
At least, taht's what these functions really do ...

Marc

[david.nalesnik, 2014-07-17 12:44:20]

Looks well coded and well commented.  I have some observations/questions about
the regtests, but otherwise LGTM.

https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyS...
File input/regression/magnifyStaff-bar-lines.ly (right):

https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyS...
input/regression/magnifyStaff-bar-lines.ly:30: 
Are so many examples necessary?

https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyS...
File input/regression/magnifyStaff-dots-beamlets.ly (right):

https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyS...
input/regression/magnifyStaff-dots-beamlets.ly:1: \version "2.19.11"
This looks to do what it says (and is very appealing visually), but I notice
that the note-spacing becomes more compressed as the magnification increases. 
Is this OK?

https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyS...
File input/regression/magnifyStaff-space-alist.ly (right):

https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyS...
input/regression/magnifyStaff-space-alist.ly:2: 
Looks fine.  I get a programming error: "No spacing entry from KeyCancellation
to `custos'"  Not sure if this is something on my end.

https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyS...
input/regression/magnifyStaff-space-alist.ly:35: 
Impressive display, but should there be so many examples?

[Mark Polesky, 2014-07-17 19:34:21]

On 2014/07/17 12:44:20, david.nalesnik wrote:
>
https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyS...
> input/regression/magnifyStaff-bar-lines.ly:30: 
> Are so many examples necessary?

No.  I've reduced from 5 examples to 3.

>
https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyS...
> input/regression/magnifyStaff-dots-beamlets.ly:1: \version "2.19.11"
> This looks to do what it says (and is very appealing visually), but I notice
> that the note-spacing becomes more compressed as the magnification increases. 
> Is this OK?

Not really.  I had disabled the automatic spacing for fear of Issue 3990
http://code.google.com/p/lilypond/issues/detail?id=3990
but it turns out that enabling it here is not as detrimental as it was for
\magnifyMusic, so I'll leave it enabled.

>
https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyS...
> input/regression/magnifyStaff-space-alist.ly:2: 
> Looks fine.  I get a programming error: "No spacing entry from KeyCancellation
> to `custos'"  Not sure if this is something on my end.

That's a separate problem; I don't think it compromises this patch.  I'll look
into it.

>
https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyS...
> input/regression/magnifyStaff-space-alist.ly:35: 
> Impressive display, but should there be so many examples?

No.  I've reduced from 5 examples to 3.

While I have your attention, there was some discussion on the mailing list about
changing \magnifyMusic and \magnifyStaff to \resizeMusic and \resizeStaff.  Any
opinion?

Thanks for your comments,
Mark

[david.nalesnik, 2014-07-17 23:59:09]

Hi Mark,

On Thu, Jul 17, 2014 at 2:34 PM, <markpolesky@gmail.com> wrote:

>
>
> While I have your attention, there was some discussion on the mailing
> list about changing \magnifyMusic and \magnifyStaff to \resizeMusic and
> \resizeStaff.  Any opinion?
>
>
Hmm.  To be honest, I rather like \magnifyMusic and \magnifyStaff.  I
wouldn't think twice about asking for a magnification of 0.5.  Besides,
there is a markup command \magnify, which presumably allows shrinking.  I
don't see any issue with calling the commands \scale..., either.  I don't
see a conflict with \scaleDurations, or the markup command \scale, for that
matter.

I don't particularly like \resize..., as there's no sense of a relative
change, just a change to some other size.


>
> https://codereview.appspot.com/117830043/
>

[marc, 2014-07-18 07:00:10]

Am 18.07.2014 01:59, schrieb David Nalesnik:
>
> Hi Mark,
>
> On Thu, Jul 17, 2014 at 2:34 PM, <markpolesky@gmail.com
> <mailto:markpolesky@gmail.com>> wrote:
>
>
>
>     While I have your attention, there was some discussion on the mailing
>     list about changing \magnifyMusic and \magnifyStaff to \resizeMusic and
>     \resizeStaff.  Any opinion?
>
>
> Hmm.  To be honest, I rather like \magnifyMusic and \magnifyStaff.  I
> wouldn't think twice about asking for a magnification of 0.5.  Besides,
> there is a markup command \magnify, which presumably allows shrinking.

I wasn't aware of that. Should this be renamed, too?

>   I don't see any issue with calling the commands \scale..., either.  I
> don't see a conflict with \scaleDurations, or the markup command \scale,
> for that matter.

+1

> I don't particularly like \resize..., as there's no sense of a relative
> change, just a change to some other size.

\rescale...?

Marc

[david.nalesnik, 2014-07-20 23:48:12]

The changes look good to me, but I'm getting a property type-check warning for
`thin-kern.'

https://codereview.appspot.com/117830043/diff/80001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):

https://codereview.appspot.com/117830043/diff/80001/ly/music-functions-init.l...
ly/music-functions-init.ly:721: (BarLine kern)
Shouldn't this now be segno-kern?

[david.nalesnik, 2014-07-20 23:57:10]

On Fri, Jul 18, 2014 at 2:00 AM, Marc Hohl <marc@hohlart.de> wrote:
>
>
> \rescale...?
>
>
\scale.. would be better, but my favorite is still \magnify...

--David

[Mark Polesky, 2014-07-21 01:23:27]

On 2014/07/20 23:48:12, david.nalesnik wrote:
>
https://codereview.appspot.com/117830043/diff/80001/ly/music-functions-init.l...
> ly/music-functions-init.ly:721: (BarLine kern)
> Shouldn't this now be segno-kern?

Done.

Regarding the naming, looks like it's a tie between `resize' and `magnify', with
`magnify' slightly ahead if you count Paul's vote as split:

scale:  Paul
resize: Paul, Marc
magnify: James, David N.

Unless there's more opposition, I'll probably push it as `magnify'; we can
always change it later.

Thanks,
Mark