Re: GSoC spanners project

[David Kastrup]

Nathan Chou <address@hidden> writes:

> Hello,
>
> Thank you for the information! I have been thinking more and a few
> questions have come to mind:
>
> * However the cross voice Spanner object is created, is it expected to
> be identical to the object currently created by the hidden voice
> workaround? Just to make sure, Spanners are Grobs, which only contain
> graphical information and aren't associated with a context, right?

Spanners are Grobs.  Grobs contain a whole lot more than only graphical
information (the graphical part is their stencil) but are employed only
during graphical typesetting (the one governed by \layout blocks).
Spanners tend to split into separate quasi-items at line breaking, with
each such item covering one line.

They aren't themselves associated with contexts, but the _announcements_
(or rather "acknowledgments") of grobs mention the engraver originating
the announcement.  That engraver is hosted by a particular (and
queryable) context.

> * Although it is possible to deliver the STOP spanner event to the
> engraver of the corresponding START event (e.g. if the spanner has an
> ID to match the START and STOP events), is this an undesirable
> solution because it basically does the same thing as the hidden voice
> workaround?

There is no need to base the implementation on workarounds.  At the
current point of time, slurs and phrasing slurs have ways of dealing
with multiple spanners.  That has not much of a user interface and it
requires putting up engravers in some context where it will see the
announcements of both starting and ending slur.  The mechanism is also
tied rather hard into the engravers themselves without a good way to
generalize this into other engravers.

Currently engravers listen to events and acknowledgments only in their
dedicated context but can announce anywhere.  It's possible to move the
listeners around independently if that opens a viable solution.  Of
course, the lifetime of an engraver is tied to its hosting context,
however.

-- 
David Kastrup