Hi Paul.
On 2016-12-16 16:02, Paul wrote:
Hi Knut and everyone,
Great to see your work which seems like a nice improvement. I just have
some thoughts on the implementation / use of properties.
We are just talking about grob properties and not context properties
right? In that case no need to also create context properties as you do
in your patch, since the grob properties are sufficient.
Yes, I think that's a general agreement now. AFAICS, the idea of context
properties quickly vanished after we recognized that we can get rid of
__ (or ExtenderEvents) entirely, at least as far as the user is
concerned. They are now more like an implementation detail for no-extender.
What about a way to do this with fewer than 3 separate grob properties?
LyricExtender.minimum-length
LyricExtender.no-extender
LyricExtender.force-extender
If I understand correctly, only 1 of 3 kinds of behavior can be in
effect at a given point:
1. no extensions
2. forced extensions
3. automatically added extension depending on a 'minimum-length' number
Not quite. I can imagine that no-extender and force-extender could be
combined. E.g., as create-extender = { one of #'auto, #'never, #'always }:
#'auto means the default: create extenders on melismata and nowhere else.
#'never means: create no extenders, period.
#'always means that extenders are enforced even on non-melismata (where,
by definition, there should not be an extender; but there are situations
where it makes sense to overwrite it; e.g., for a continuation of an
extender in a second volta repeat, or in divisi lyrics).
Minimum-length [2] is orthogonal - it is more concerned with the layout.
With some reasonable minimum-length, extenders that reduce to mere
flyspecks are hidden. This happens often in somewhat dense choral
settings: the extender is not printed if the syllable text is almost as
wide (or even wider) than the distance between the respective noteheads.
It's a threshold value that tells which existing extenders will be
printed and visible. [1]
But this decision entirely depends on horizontal spacing, and will vary
with line breaks, other voices, etc. IMHO, that's a whole different
quality of a variable than the previous one (existence vs. appearance).
And the general design principle throughout Lilypond is to separate
semantics from layout as much as possible.
[1] One exception: on forced extenders on non-melismata (which do not
have any natural length, obviously), minimum-length will not serve as a
threshold, but to /set/ the length.
[2] Side Note: other proposed names for minimum-length so far:
(1) minimum-space
(2) show-length
(3) hide-below-length
(4) hide-if-shorter-than
(5) minimum-visibility
(6) visibility-threshold
(7) printing-threshold
(8) extender-threshold
So why not one grob property (name to be determined) that can be a
boolean or a number:
LyricExtender.extenders = ##f % no extensions
LyricExtender.extenders = ##t % forced extensions
LyricExtender.extenders = 2 % a number, auto extensions
For example, it could be set to a number and then use \once to set it to
##t to force (or ##f to suppress) a given extender.
See [1] above; we need to be able to specify a length for forced
extenders (that do not have a natural length because there's only one
note). Yes, something like extenders = #'(forced? length) with a boolean
for forced? and a number for length would be sufficient (note that #'(#f
+inf.0) amounts to #'never...), but that's quite opaque.
Another possibility (2 properties) might be:
LyricExtender.stencil = ##f % no extensions
LyricExtender.force-extender = ##t % forced extensions
LyricExtender.minimum-length = 2 % auto extensions (if force-extender
is not ##t and stencil is not ##f)
Yes, that'll work: stencil = ##f means #'never; stencil = ##t and
force-extender = ##t means #'always; and stencil = ##t and
force-extender = ##f means #'auto.
However, I personally dislike to touch stencil. That's my last resort,
but it feels hacky; IMHO stencil is a more or less internal layout
procedure, and I should not have to abuse it for semantic purposes
(i.e., #'never).
Cheers,
Alexander
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
