[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Doc: NR 4.1.2: Reorganize vertical dimensions. (issue2316042)
From: |
perpeduumimmobile |
Subject: |
Re: Doc: NR 4.1.2: Reorganize vertical dimensions. (issue2316042) |
Date: |
Mon, 04 Oct 2010 11:11:58 +0000 |
In short: great work, push it. Two slight remarks on skylines (I prefer
the wording in your answer on my post), and perhaps about Hooke's law.
But I don't have a strong point on the latter.
On 2010/10/02 16:09:22, Mark Polesky wrote:
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. [...]
Are you saying you'd prefer to define the four keys individually
for each of the eight variables?
Okay, I withdraw... I somehow thought there are places where markups
have their "origin" on the top, and others on the bottom, but this is
plainly wrong. Looks like this is still in a flux... But when we have
the natural choices, we should include them in the docs. (Distance USA
- Portugal from L.A. ...)
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.
I'd prefer this, but that's just me...
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).
Yup.
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"?
"Yes they are possible." I admit I can't tell you an example, but I'll
never say it will never be useful... ;-)
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... [...]
Oops, sorry. I just meant a sentence like "stretchability is the
inverse spring constant in Hooke's law", perhaps in parenthesis; your
explanation is perfect! It's just for those who already know the law
that they have the right (or even better) understanding from just one
sentence. I would not expect a physicist's explanation of the law...
I feel that simply mentioning Hooke's law does little to help the
LilyPond user
Well, not each and every one, but some of the users are math- and
science-addicts, and quite a number of them will have heard of the law.
http://codereview.appspot.com/2316042/
- Re: Doc: NR 4.1.2: Reorganize vertical dimensions. (issue2316042), (continued)
- Re: Doc: NR 4.1.2: Reorganize vertical dimensions. (issue2316042), percival . music . ca, 2010/10/03
- Re: Doc: NR 4.1.2: Reorganize vertical dimensions. (issue2316042), percival . music . ca, 2010/10/03
- Re: Doc: NR 4.1.2: Reorganize vertical dimensions. (issue2316042), markpolesky, 2010/10/03
- Re: Doc: NR 4.1.2: Reorganize vertical dimensions. (issue2316042), markpolesky, 2010/10/03
- Re: Doc: NR 4.1.2: Reorganize vertical dimensions. (issue2316042),
perpeduumimmobile <=