Re: Add a procedure to add slashes to Beams and straight Flags (issue 562550043 by address@hidden)

[thomasmorley65]

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/