[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 00:04:26 +0000

Too late for a follow-up, but:
File scm/define-markup-commands.scm (right):
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.
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 (*
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 as
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
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.

reply via email to

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