lilypond-devel
[Top][All Lists]
Advanced

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

Re: Non-quadratic form of whiteout


From: Thomas Morley
Subject: Re: Non-quadratic form of whiteout
Date: Sun, 16 Sep 2018 11:39:25 +0200

2018-09-13 23:56 GMT+02:00 Lukas-Fabian Moser <address@hidden>:
> Addendum: Of course, "quadratic" is not the right word. What I mean by it is
> that the horizontal and vertical protrusions of the whiteout box around the
> actual rectangular hull of the object are equal. For, e.g., noteheads, this
> /does /lead to an (almost) quadratic shape.
>
>
>
> Am 13.09.2018 um 23:52 schrieb Lukas-Fabian Moser:
>>
>> Dear developers,
>>
>> following a feature request on -user I tried my hand at implementing a
>> feature enabling non-quadratic form for box-whiteouts.
>>
>> As I never participated in developing before (and only rarely get down to
>> coding these days), I'm pretty sure that what I did is substandard. Urs
>> Liska was kind enough to point me to the LilyPond repository on GitHub (and
>> comment on some aspects of my changes), but I unterstand that is not really
>> the right place.
>>
>> So I just post a patch here in case anyone would be interested in helping
>> me bring my small contribution up to scratch.
>>
>> Basically it adds to the 'whiteout property - which, at the moment, can
>> either be a boolean or a number indicating the dimension of a quadratic
>> whiteout box - a third possibility, namely a number pair giving x- and
>> y-dimension separately. For instance:
>>
>> \version "2.21"
>>
>> \new Staff {
>>   \override NoteHead.whiteout = #'(5 . 40)   % Pair of X-thickness and
>> Y-thickness
>>   g'4
>>   r2
>>   \override NoteHead.whiteout = #'(40 . 5)
>>   g'4
>> }
>>
>> Best
>> Lukas


Some thoughts:

The current implementation, was first done with issue 4418 for 2.19.22
https://sourceforge.net/p/testlilyissues/issues/4418/
See also the review-discussion:
https://codereview.appspot.com/236480043/
Since then more patches were done on top of this one.

Currently the whiteout-property can be set to a boolean or a number.
Additionally a `whitout-style`-property is usable.

If whiteout is true, the amount of space added to the stencil is zero
or some default-value (provided in the `stencil-whiteout`-procedure)
for 'outline or 'rounded-box.
If whiteout is a number, this value will be taken.

So far the current state of it, as far as I understand it.


I don't think even the current state is satisfying.
Why provide a hard-coded default for some styles?
I'd vote for doing the same for all styles (the default box with
square corners, rounded-box and outline).
Even curently whiteout set zero will result in the same output as
doing whiteout #t, ofcourse only for the default style.
We have several code examples about whiteout in the docs, mostly in
the regtests and in snippets. Most of them explicitely set a number,
if a different style is desired.

So my first suggestion would be to drop the boolean argument for 'whiteout.
Instead let the user decide. Providing a number shouldn't be too hard.
Dropping the boolean was already disussed here:
https://codereview.appspot.com/236480043/#msg15
Though, I don't see much arguments. otoh it's not unlikely I don't
understand the argument(s) ;)
A disadvantage would be the neeed to code some convert-rule (which is
beyond my coding-capabilities).

Quite often users (including myself) want to customize the
whiteout-amount even more than currently possible.
So my second suggestion is to make whiteout accepting a number-or-pair.
A number would do what's already done with it.
A simple pair like '(1 . 2) would extent the whiteout-amount for
x-y-axis differently.
A pair-list like '((1 . 2)(3 . 4)) would extent the whiteout-amount in
x-axis with the values of the first pair, in y-axis with the values of
the second pair.

Providing a pair or a pair-list will not work for 'outline ofcourse, I
don't have a good thought how to deal with this style, though.
Probably printing a message and/or providing some default, which may
be zero.

Thoughts?



Cheers,
  Harm



reply via email to

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