Re: Allow scripts to be defined either as glyphs or stencils. (issue 348120043 by address@hidden)

[v . villenave]

On 2019/02/22 22:11:58, dak wrote:
> There is some fundamental confusion here.  A stencil expression is a
list.  It
> never satisfies the ly:stencil? predicate and always satisfies the
pair?
> predicate.

Oh, I see.  I mixed up "unsmob" and "eval": a stencil expression becomes
a Stencil when it’s eval’d, not unsmobbed.

> A Stencil
> type contains both a stencil expression and a bounding box.

Indeed: I wondered if I had to create a Box object with appropriate X
and y extents, but I realized that the stencil expression does that on
its own when evaluated.  (At least it’s my understanding.)

> ly:script-interface::print is a Scheme callback (it may or may not be
> implemented in C++ but that's not really relevant).  What does
overriding
> script-stencil buy you that overriding stencil would not equally well
do?  I
> want to understand what this achieves in a better way than what we
have already.

I’m still struggling to understand; are you referring to the stencil
property of the grob? (Which, since we don’t have ScriptStaccato or
ScriptMarcato defined as different grobs, would affect all Script
objects regardless of their individual specifics?)

«What we have» is convenient, as it allows for several Script objects to
be defined as an alist, each one with different properties (e.g.
avoid-slur, script-prio etc.) and a specific Feta glyph (even allowing
for different glyphs depending on direction).  That glyph lookup is
defined as the script-stencil property, which effectively replaces the
Script grob’s stencil (via the script-interface::print callback).
(Please correct me if I’m wrong.)

As I was aiming for the less disruptive change possible, I suggested
that this script-stencil property could also be defined as a stencil
expression (in which case there’s no font glyph lookup anymore), but
preserving every other part of the current logic. I initially thought
about adding an additional property (something maybe called
"script-stencil-formatter", that would allow users to _both_ use a
specific glyph _and_ throw in a (lambda (stil) (ly:stencil-scale stil))
function, for example.  Then I decided against it.

The current mechanism relies on the script-stencil property, in a rather
inflexible way: see for example the hardcoded "feta" reference in
script-interface.cc; I’m merely trying to make it a bit more versatile
by allowing users to define new Script objects (or redefine existing
ones) as stencil expressions (not just Feta glyphs), _within_ the
alist-based structure we already offer (thus keeping the ability to
fine-tune all the other properties available individually for each
articulation type)…  And within that alist, the relevant property
happens to be named script-stencil, not just stencil.  So I thought
that’s where I’d look.

V.

https://codereview.appspot.com/348120043/