lilypond-devel
[Top][All Lists]
Advanced

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

Re: Fix Issue 1290 (issue3832046)


From: David Kastrup
Subject: Re: Fix Issue 1290 (issue3832046)
Date: Sat, 08 Jan 2011 09:49:20 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

"Keith OHara" <address@hidden> writes:

> -------- Original Message --------
>> From: "Carl Sorensen" <address@hidden>
>> Sent: Friday, January 07, 2011 3:28 PM
>
>> 
>> I was hoping that by setting the default, we'd get good spacing and we
>> wouldn't need the override.
>> 
>
> I hadn't seen this exchange when I commented on the define-grobs.scm; 
> sorry.
>
> The large horizontal padding of 2.0 told Lily that the upper loops of the 
> treble clefs were intolerably close to the whole notes, in 
> stem-length-estimation.ly.   The stem length test passes with 0.5.
>
> The bug report test and your reg-test are rather extreme examples,
> with very tall and narrow protrusions.  It seems fine to have an
> extreme example for your reg-test, though, and to include an override
> that adjusts the very feature being tested.

Needing several different overrides for different cases feels kludgy.
The current form of horizontal padding is an all-or-nothing approach
where minuscule changes can have drastic consequences.

A somewhat more fuzzy approach would be to use trapezoidal padding.
Namely, if the horizontal overlap is negative, one checks whether
vertical_overlap*fuzz+horizontal_overlap*(1-fuzz) is still negative.
Currently "fuzz" is zero.  If it is 1, we basically get box spacing.

But probably we should rather get one basic solution working at first.
It would probably be nice to factor those decisions to a well-understood
location in the code so that further experiments need not touch dozens
of arbitrarily located code passages, but can just meddle with one basic
code block.

-- 
David Kastrup




reply via email to

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