Re: Doc: NR 4.1.2: Reorganize vertical dimensions. (issue2316042)

[markpolesky]

http://codereview.appspot.com/2316042/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):

http://codereview.appspot.com/2316042/diff/1/Documentation/notation/spacing.itely#newcode200
Documentation/notation/spacing.itely:200: @table @code
On 2010/10/02 09:17:16, perpeduumimmobile wrote:
> Hm. As long as vertical spacing is not absolutely
> bullet-proof specified, I don't like to see this
> sections deleted.  The NR is a reference, so it's
> okay to have per-entry specifications therein.
> I'd leave them, but push them below your
> introductory part.

Are you saying you'd prefer to define the four keys individually for
each of the eight variables?  Even though the NR is a reference, I think
this would be needlessly crufty.  But I could be convinced if you feel
strongly about it.

http://codereview.appspot.com/2316042/diff/1/Documentation/notation/spacing.itely#newcode239
Documentation/notation/spacing.itely:239: the combined items.
On 2010/10/02 09:17:16, perpeduumimmobile wrote:
> Yes, but this somehow sounds like a rectangle you
> can put between two staves or something, and this
> is _not_ correct (because padding specifies
> whitespace between the skylines).  I'm not sure
> why we avoid the "skyline" term in the NR; it's
> not too hard a concept IMHO.  But if we don't use
> it, you might think again over this sentence.

Well, that's why I used the word "unobstructed".  But I could easily
change it to:

  "the minimum required amount of unobstructed vertical whitespace
between the skylines of the two items."

Though that's slightly inaccurate, since markups don't have skylines, as
far as I know.  But the idea may be clearer anyway.

http://codereview.appspot.com/2316042/diff/1/Documentation/notation/spacing.itely#newcode246
Documentation/notation/spacing.itely:246: reference point of a system is
the middle line of the nearest
On 2010/10/02 09:17:16, perpeduumimmobile wrote:
> For markups, things are different (and yet to
> specify).

You mean code-wise, I presume (I did cover markups in this paragraph).

> It'd make sense to use either the top or bottom
> corner of a markup depending on where the
> specified space lies...

That would be my preference.

http://codereview.appspot.com/2316042/diff/1/Documentation/notation/spacing.itely#newcode248
Documentation/notation/spacing.itely:248: @code{padding} or
@code{minimum-distance} are not meaningful,
On 2010/10/02 09:17:16, perpeduumimmobile wrote:
> Yes, they are.  They can be stretched, and the
> resulting space will be larger than padding or
> minimum-distance.

"Yes they are meaningful", or "yes they are possible"?  Can you give a
meaningful example where

  space < padding < minimum-distance

such that the behavior changes when space is increased to equal
minimum-distance?  Are there cases where setting space below padding
and/or minimum-distance is necessary to achieve some desired effect?

http://codereview.appspot.com/2316042/diff/1/Documentation/notation/spacing.itely#newcode264
Documentation/notation/spacing.itely:264: @code{+inf.0}.
On 2010/10/02 09:17:16, perpeduumimmobile wrote:
> Again, it's a reference.  We can mentioned Hooke's
> law, don't we?

Okay, here we go...

  Hooke's law:  F=-kx

  "x" is the displacement of the end of the spring
  from its equilibrium position (in SI units: "m");

  "F" is the restoring force exerted by the material
  (in SI units: N or kg·m/s^2); and

  "k" is the force constant (or spring constant) (in
  SI units: N/m or kg/s^2).

So, according to Joe, stretchability is equal to 1/k.  So, if we use "s"
for stretchability, then

   F=-x/s

Now, hopefully you realize that this is completely uninformative unless
we explain the following, all of which remain unclear to me:

1) what is the "equilibrium position" of the stretchable space?

2) what is its "displacement" from the equilibrium?

3) what is the "restoring force" exerted by the stretchable space and
what is its unit of measurement?

> Joe said that a reasonable default for
> stretchability is space, because this keeps
> proportions of 'space values and actual whitespace
> constant, if possible due to the constraints.

I don't mean to be difficult, but this still confuses me.  What is the
unit of measurement of stretchability?  If the stretchable space were a
spring, we could speak of an "inverse Newton" or "time squared divided
by mass" (s^2/kg).  So then with regard to the stretchable space, what
is the "time" and what is the "mass"?

Consequently, when 'stretchability equals 'space, what are the resulting
values of the "displacement" and "restoring force"?  And what is it
about those values that "keeps proportions of 'space values and actual
whitespace constant (where possible)"?

I feel that simply mentioning Hooke's law does little to help the
LilyPond user understand how to select meaningful values to achieve the
desired vertical spacing.  Is there anyone here for whom the Hooke's law
analogy clarifies the spacing behavior?  (Carl?)

> (and actually, why isn't this the default)?

That's a good question.

http://codereview.appspot.com/2316042/