Hi Malte, thanks for review.
Currently I follow a different route: create a Slash-grob. Once it is mature I'll publish a concurrent patch-set in a different issue. For now I'll set this one back to 'needs-work'. However you spotted some valid points, which I'll likely have to take into account for a possible Slash.stencil as well. https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm File scm/define-grobs.scm (right): https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm#newcode408 scm/define-grobs.scm:408: (slash-stem-part . 1) On 2019/03/16 20:42:11, Malte Meyn wrote:
It’s not that easy in some cases, see example code below.
Yep, it's quite impossible to find a fixed default number-value which looks nice in all cases, thus I made it a overridable (sub-)property. Should I try to find some procedure looking at the actual stem-length and set slash-stem-part accordingly? Wouldn't it be over-engineered? https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm#newcode409 scm/define-grobs.scm:409: (slash-gradient . (1 . 2)) On 2019/03/16 20:44:19, Malte Meyn wrote:
On 2019/03/16 20:42:11, Malte Meyn wrote: > IMHO that’s to steep, I’d prefer something like '(3 . 4)
Also, wouldn’t it be simpler (for the user) to use a number here
instead of a
pair? #3/4 or 0.75 instead of #'(3 . 4)
This is one of the TODO's in 'slash-stencil'. Possible would be pair, fraction, number or even an angle. I'd love to read more opinions about it. https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm#newcode409 scm/define-grobs.scm:409: (slash-gradient . (1 . 2)) On 2019/03/16 20:42:11, Malte Meyn wrote:
IMHO that’s to steep, I’d prefer something like '(3 . 4)
Well, a matter of taste I'd say. The slash for beams needs to be more steep in most cases (compared to slashed default-flags). I'll take your suggestion and do some tests. https://codereview.appspot.com/562550043/diff/564540043/scm/define-grobs.scm#newcode410 scm/define-grobs.scm:410: (slash-x-y-over-shoot . (0.4 . 0.8)) On 2019/03/16 20:42:11, Malte Meyn wrote:
I don’t really understand how this works: Why does one need a so much
larger y
value? The result doesn’t look like the slash sticks out further at
the top than
at the left side.
The x-value does not need to look at beam's gradient as opposed to the y-value. Tbh, I didn't care much about this problem after finding some working code. Though, you stumbled across it and maybe you will not be the only one. I'll look how to improve it.
Also, that’s a really complicated name, how about something simpler
(maybe
slash-overshoot)?
I'll delete the dash in 'over-shoot' according to the existing 'break-overshoot' Though, looking at other related properties like the already mentioned 'break-overshoot' or 'shorten-pair', those pairs always work in one axis' direction. I wanted to make clear those values serve different directions. Again, I'd love to hear more opinions. https://codereview.appspot.com/562550043/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
