Re: Issue 5788: New French Beamimg Approach (issue 557500043 by address@hidden)

[dak]

On 2020/02/25 13:06:31, Be-3 wrote:
> On 2020/02/24 06:44:39, hanwenn wrote:
> > One thing to consider: since the mechanics are now very predictable,
maybe we
> > can name the property in after its mechanics? ie. french-correction
->
> > stem-end-shorten or something?
> 
> After having thought about it for quite a while I'm not too happy with
> "stem-end-shorten", for the following reasons:
> 
> The term "end" does not carry any information, because stems can only
be
> shortened at their end, as their starting point is nailed to a
notehead. ;)

TabStaff and some rhythmic stems aren't.

> There already are stem-shortenish properties in standard stem
processing
> (beamed-stem-shorten and stem-shorten).
> 
> Most importantly, the french-correction property is different from all
the other
> shortenish propertie in so far as all of them will heavily influence
the layout
> (affecting overall positioning), but "french-correction" is the only
property
> that will shorten the stem for printing only, leaving all positioning
aspects
> untouched.

Then stem-extra-shortening would be the analog to the extra-offset
property that works after positioning.
> Therefore, I'll very much like to have it called something with
"french" in it
> to emphasize the special role it plays in French beaming (and really
*nowhere*
> else).
> 
> Would "french-shorten" be a viable compromise?
> 
> Thanks for looking into this,
> Torsten

It seems weird to give an explicit value here rather than a flag, as the
effect should likely apply regardless of how you scale beams and their
thicknesses up and down.  There is no better way to fudge this
value/calculation in less conspicuously?  Like using
grob::offset-function or one of its cousins/equivalents from
lily/grob-closure.cc ?

https://codereview.appspot.com/557500043/