Fix #888: Add ly:stencil-scale.

Fix #888: Add ly:stencil-scale.

* lily/stencil-interpret.cc (interpret_stencil_expression):

  interpret new stencil command `scale-stencil', unscaling offset of body to
  compensate for change in output scale

* lily/stencil-scheme.cc (ly_stencil_scale):

  export new function `ly:stencil-scale'

* lily/stencil.cc, include/stencil.hh (scale):

  new method for scaling stencils

* scm/define-markup-commands.scm (scale):

  new markup command

* scm/define-stencil-commands.scm

  (ly:all-stencil-commands): add stencil commands for setting and resetting
  scale (`setscale', `resetscale')

  (ly:all-output-backend-commands): add `scale-stencil' command

* scm/output-ps.scm, output-svg.scm (setscale, resetscale):

  implement stencil outputters for scaling

[Valentin Villenave, 2010-10-04 10:36:47]

http://codereview.appspot.com/2275042/diff/2001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):

http://codereview.appspot.com/2275042/diff/2001/scm/define-markup-commands.sc...
scm/define-markup-commands.scm:3375: (number? number? markup?)
Hi Neil, your patch looks awesome! Minor comment:
Wouldn't a number-pair be more consistent with existing markup commands such as
translate-scaled?

[Patrick McCarty, 2010-10-08 05:32:32]

Hi Neil,

Looks great!

I just have a couple of comments for you (below).

Thanks,
Patrick

http://codereview.appspot.com/2275042/diff/2001/input/regression/stencil-scal...
File input/regression/stencil-scale.ly (right):

http://codereview.appspot.com/2275042/diff/2001/input/regression/stencil-scal...
input/regression/stencil-scale.ly:21: (ly:stencil-scale
(ly:text-interface::print grob) 2 1.6))
There is trailing whitespace on this line.

http://codereview.appspot.com/2275042/diff/2001/lily/stencil-interpret.cc
File lily/stencil-interpret.cc (right):

http://codereview.appspot.com/2275042/diff/2001/lily/stencil-interpret.cc#new...
lily/stencil-interpret.cc:104: y_scale));
"resetscale" doesn't really need any formal parameters, since they are unused in
the backends.

Interestingly, "resetrotation" also has (unused) formal parameters, but
"resetcolor" does not.  :)

http://codereview.appspot.com/2275042/diff/2001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):

http://codereview.appspot.com/2275042/diff/2001/scm/define-markup-commands.sc...
scm/define-markup-commands.scm:3375: (number? number? markup?)
On 2010/10/04 10:36:47, Valentin Villenave wrote:
> Hi Neil, your patch looks awesome! Minor comment:
> Wouldn't a number-pair be more consistent with existing markup commands such
as
> translate-scaled?

I have a slight preference for a number-pair instead of two separate numbers.

[Neil Puttock, 2010-10-24 11:46:39]

On 2010/10/04 10:36:47, Valentin Villenave wrote:

> Hi Neil, your patch looks awesome!

Thanks.

> Wouldn't a number-pair be more consistent with existing markup commands such
as
> translate-scaled?

Yep, and it saves a hash too. :)

Cheers,
Neil

[Neil Puttock, 2010-10-24 11:51:22]

On 2010/10/08 05:32:32, Patrick McCarty wrote:

> Looks great!

Thanks.

>
http://codereview.appspot.com/2275042/diff/2001/input/regression/stencil-scal...
> File input/regression/stencil-scale.ly (right):
> 
>
http://codereview.appspot.com/2275042/diff/2001/input/regression/stencil-scal...
> input/regression/stencil-scale.ly:21: (ly:stencil-scale
> (ly:text-interface::print grob) 2 1.6))
> There is trailing whitespace on this line.

Oops, standards are slipping. ;)

> http://codereview.appspot.com/2275042/diff/2001/lily/stencil-interpret.cc
> File lily/stencil-interpret.cc (right):
> 
>
http://codereview.appspot.com/2275042/diff/2001/lily/stencil-interpret.cc#new...
> lily/stencil-interpret.cc:104: y_scale));
> "resetscale" doesn't really need any formal parameters, since they are unused
in
> the backends.
> 
> Interestingly, "resetrotation" also has (unused) formal parameters, but
> "resetcolor" does not.  :)

Ah, I just obediently followed the example of `resetrotation', while thinking it
slightly silly to send unused params.
 
> http://codereview.appspot.com/2275042/diff/2001/scm/define-markup-commands.scm
> File scm/define-markup-commands.scm (right):
> 
>
http://codereview.appspot.com/2275042/diff/2001/scm/define-markup-commands.sc...
> scm/define-markup-commands.scm:3375: (number? number? markup?)
> On 2010/10/04 10:36:47, Valentin Villenave wrote:
> > Hi Neil, your patch looks awesome! Minor comment:
> > Wouldn't a number-pair be more consistent with existing markup commands such
> as
> > translate-scaled?
> 
> I have a slight preference for a number-pair instead of two separate numbers.

OK, I'll sort out a revised patch with all the suggested changes.

Cheers,
Neil

[Patrick McCarty, 2010-10-25 05:41:21]

LGTM.

Thanks,
Patrick

[lemzwerg, 2010-10-25 06:03:36]

LGTM too.

http://codereview.appspot.com/2275042/diff/18001/lily/stencil-scheme.cc
File lily/stencil-scheme.cc (right):

http://codereview.appspot.com/2275042/diff/18001/lily/stencil-scheme.cc#newco...
lily/stencil-scheme.cc:398: {
Don't say @code{@var{...}} but @var{...}.

http://codereview.appspot.com/2275042/diff/18001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):

http://codereview.appspot.com/2275042/diff/18001/scm/define-markup-commands.s...
scm/define-markup-commands.scm:3381: Scale @code{@var{arg}}. 
@code{@var{factor-pair}} is a pair of numbers
Don't say @code{@var{...}} but @var{...}

[Neil Puttock, 2010-10-25 21:53:54]

On 2010/10/25 06:03:36, lemzwerg wrote:

> Don't say @code{@var{...}} but @var{...}.

Hmm, have I misinterpreted Mark's post here?:

http://lists.gnu.org/archive/html/lilypond-devel/2010-09/msg00285.html

[wl_gnu.org, 2010-10-26 05:52:08]

>> Don't say @code{@var{...}} but @var{...}.
> 
> Hmm, have I misinterpreted Mark's post here?:
> 
> http://lists.gnu.org/archive/html/lilypond-devel/2010-09/msg00285.html

Well, have a look at section A.17 (Scheme functions) and see how
function names and arguments are formatted.  Mark is referring to code
blocks which contain metasyntactical variables.  However, for your
function (which is eventually appearing in A.17 too), this is not
appropriate.


    Werner

[Mark Polesky, 2010-10-26 08:21:41]

On 2010/10/26 05:52:08, wl_gnu.org wrote:
> Well, have a look at section A.17 (Scheme functions) and
> see how function names and arguments are formatted.  Mark
> is referring to code blocks which contain metasyntactical
> variables.  However, for your function (which is
> eventually appearing in A.17 too), this is not
> appropriate.

Well... Okay, yeah, but see this:
http://kainhofer.com/~lilypond/Documentation/contributor/syntax-survey.html#m...

I'm the one that wrote the @var description there.  And yes,
the rationale is simplistic: "This improves readability in
the PDF and HTML output."  But I think Neil's impulse to
format it that way matches the spirit of the rationale, no?
And I certainly wouldn't be opposed to instituting the same
policy for A.17, though of course that would be best left
for a different patch than this one.

Werner, if you have any objections to adding @code to all
the @var's in A.17, I'd like to hear them.

Thanks.
- Mark

[wl_gnu.org, 2010-10-26 12:07:47]

> I'm the one that wrote the @var description there.  And yes, the
> rationale is simplistic: "This improves readability in the PDF and
> HTML output."

Does it?  It's not clear to me why the formatting of A.17 looks better
if using typewriter in upright and italic shapes.  It's really a
matter of taste...

> Werner, if you have any objections to adding @code to all the @var's
> in A.17, I'd like to hear them.

It is not an important issue to me whether to use typewriter or not.
Whatever you decide to use, it should be *consistent*.  So for the
time being, stuff going to A.17 should look similar to the other
entries already there.


    Werner

[Carl, 2010-10-27 18:39:30]

On 2010/10/26 08:21:41, Mark Polesky wrote:

> Well... Okay, yeah, but see this:
>
http://kainhofer.com/%7Elilypond/Documentation/contributor/syntax-survey.html...
> 
> I'm the one that wrote the @var description there.  And yes,
> the rationale is simplistic: "This improves readability in
> the PDF and HTML output."  But I think Neil's impulse to
> format it that way matches the spirit of the rationale, no?
> And I certainly wouldn't be opposed to instituting the same
> policy for A.17, though of course that would be best left
> for a different patch than this one.


I think that wrapping a variable declaration in a code declaration is
undesirable.  It complicates the format of the documentation, for very little
benefit (if any).

If we want to change the format of @var{} in HTML and PDF format, we ought to be
able to do that in our texinfo program.

Or alternatively, we should get a different texinfo macro, e.g. @var{} for
outside of code, and @codevar{} for use inside of code.

THanks,

Carl

[Graham Percival, 2010-10-29 06:09:10]

On Wed, Oct 27, 2010 at 06:39:30PM +0000, Carl.D.Sorensen@gmail.com wrote:
> I think that wrapping a variable declaration in a code declaration is
> undesirable.  It complicates the format of the documentation, for very
> little benefit (if any).
> 
> If we want to change the format of @var{} in HTML and PDF format, we
> ought to be able to do that in our texinfo program.

I like this idea.  We're never going to want a non-code variable
in our docs.

Cheers,
- Graham