[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Introduce new markup-command draw-squiggle-line. (issue 281210043 by

From: thomasmorley65
Subject: Re: Introduce new markup-command draw-squiggle-line. (issue 281210043 by address@hidden)
Date: Thu, 07 Jan 2016 21:21:08 +0000
File scm/define-markup-commands.scm (right):
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 (*
> height-fraction))`? That would be more descriptive of the looks.

There are two general, sometimes conflicting problems here:
Which arguments should hold a default-value and then should be coded
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
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
them out himself. I think we should go this route, at least it
respects the

> 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
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
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
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:

scm/define-markup-commands.scm:326: @code{angularity}, @code{height} and
On 2016/01/06 19:13:58, simon.albrecht wrote:
(full stop or colon missing)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]