lilypond-devel
[Top][All Lists]
Advanced

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

Re: Adds dimension stencil command to correct with-dimension (issue 1295


From: Mike Solomon
Subject: Re: Adds dimension stencil command to correct with-dimension (issue 12957047)
Date: Wed, 28 Aug 2013 08:30:32 +0200

On 28 août 2013, at 05:28, "Keith OHara" <address@hidden> wrote:

> On Mon, 26 Aug 2013 23:57:58 -0700, Mike Solomon <address@hidden> wrote:
> 
>> On 27 août 2013, at 09:01, "Keith OHara" <address@hidden> wrote:
>> 
>>> On Mon, 26 Aug 2013 22:37:17 -0700, Mike Solomon <address@hidden> wrote:
>>> 
>>>> I'd argue that (2) is better.
>>> 
>>> What, then, is your argument ?
>> 
>> What I put below - namely, that it is consistent with the previous practice 
>> of stencils separating layout information from graphical content.
>> 
> 
> That kind of separation is not always good.
> 
> We like having the 'staff-padding' between the staff and tempo mark separate 
> from the text "Adagio", because we usually want to control the padding 
> globally for all tempo marks.
> 
> We would like to keep the space request closely associated with the graphic in
> { d'2-\markup {\italic { c r e s c. } \pad-around #0.5 {- - -} } d' b b }
> so that as the font and inter-word space change, the space request follows.
> 
> 
>> It's true that a new primitive works.  But, it seems that, on a more 
>> systemic level, this is not a tenable solution as it would lead to the 
>> creation of many different stencil primitives for different types of padding.
>> 
> 
> The new stencil primitive in the patch set I have posted now does not assume 
> any kind of padding.  You said the stencil expression should not contain data 
> influencing layout, so I went back to the patch set that simply turns off 
> skylines for markup using \with-dimensions and similar.
> 
> I withdrew the patches that preserve the space around the "- - -" leader, 
> because they put data based on the #0.5 into the stencil expression.
> 
> Of course I think it would be better to allow box dimensions in the stencil 
> expression.  Boxes are simple enough to enter as coordinates in markup 
> expressions like \pad-to-box, they are a useful building block for arbitrary 
> skylines, and the current code builds skylines from the stencil expression.
> 

If we are willing to say that boxes should be an exception because of how 
primitive they are, then it makes more sense to make an exception for them, as 
they can be used in concord to create more complex structures.  In that case, 
we may want to accept a list of boxes (or a list of quadrilaterals) instead of 
just a box, as at that point we can approximate any shape.

Cheers,
MS


reply via email to

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