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

[thomasmorley65]

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#newcode314
scm/define-markup-commands.scm:314: (height 0.5)
On 2016/01/07 00:04:26, thomasmorley651 wrote:
> 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.

So, I strongly object here to change the user-interface to something
other than the usage of absolute values and not doing any further
adjustments. I think it wouldn't help, but obfuscate what's going on.

Otoh, I see this different for markup-commands which do sort of wrapping
themselves around an argument, like \circle or \parenthesize.
Here I wouldn't object to do adjustments and use multiplayer and the
like. because the user most likely want the _argument_ circled,
parenthesized, etc in a nice mannor, out of the box, without need to
fight with properties most of the time.
(I do have an improved parenthesize-markup-command lieing around
locally, only needing some final polish, where I do exactly this sort of
coding)

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-commands.scm#newcode325
scm/define-markup-commands.scm:325: It's appearance may be customized by
overrides for @code{thickness},
On 2016/01/06 19:13:58, simon.albrecht wrote:
> s/It's/Its/

Done.

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-commands.scm#newcode326
scm/define-markup-commands.scm:326: @code{angularity}, @code{height} and
@code{orientation}
On 2016/01/06 19:13:58, simon.albrecht wrote:
> (full stop or colon missing)

Done.

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