Re: Introduce new markup-command draw-squiggle-line. (issue 281210043 by address@hidden)

[thomasmorley65]

Too late for a follow-up, but:


https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-commands.scm#newcode309
scm/define-markup-commands.scm:309: (define-markup-command
(draw-squiggle-line layout props sq-length dest eq-end?)
On 2016/01/06 19:13:58, simon.albrecht wrote:
> For the third parameter, ‘sq-number-odd?’ might be a more descriptive
name IMO.

The main motivation to name it "eq-end?" was to keep the
80-characters-line-width. For now I let it as is.
Not sure ‘sq-number-odd?’ is really more descriptive.
Others?

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-commands.scm#newcode314
scm/define-markup-commands.scm:314: (height 0.5)
On 2016/01/06 19:13:58, simon.albrecht wrote:
> How about using `(height-fraction 1)`, with `(define height (*
sq-length
> height-fraction))`? That would be more descriptive of the looks.

There are two general, sometimes conflicting problems here:
(1)
Which arguments should hold a default-value and then should be coded as
properties?
(2)
Which properties can be used at all?

I would have loved to make "eq-end?" above a property with a boolean
default-value. But I vaguely remember David K explained the inflationary
use of new properties will probably cause problems (cc-ing him). This
would be true for `height-fraction' as well.
I tried to give the other properties default-values which will be nice
for the most common use-cases.
But for not so common line-lengths, they will not return good output.
How to deal with it?
I could sort of reset/adjust the user-input. But I'm already not very
happy scaling the user input of `sq-length' to fit the final
line-length. (No way to do this different, though.)
The other way is to let it up to the user (wanting unusual values), to
figure them out himself. I think we should go this route, at least it
respects the user-input.

> Also it seems
> to me that the results are good only for height-fraction >= 1.

Why should `height' be influenced by `sq-length' in any way?
As stated above the user is responsible to find the needed values.

Look at this example, with high zoom:

#(set-global-staff-size 500) %%!!!
\markup {
  \override #'(thickness . 0.04)
  \override #'(height . 0.03)
  \draw-squiggle-line #0.01 #'(0.2 . 0) ##t
}

It will return good output and still all values are adjustable.
`height-fraction' would be a multiplyer (with value 3 in this case)
Consequently we could do `thickness-fraction' (with value 4 here) as
well.
I think everyone will agree that would be a bad idea. `thickness' needs
to be given as absolute value (although scaled by `line-thickness',
which is discussable, but inline with many other markup-commands). Why
do it different for `height'?

Or this one:
\markup {
  \override #'(thickness . 0.05)
  \override #'(height . 0.25)
  \draw-squiggle-line #0.5 #'(5 . 0) ##t
}

`height-fraction' would be 0.5 and I see no problem here, _if_ thickness
is adjusted as well.

https://codereview.appspot.com/281210043/