I'm currently doing the groundwork before embarking on a project to
implement Baroque lute tablature. As this is likely to involve
how LilyPond works in several areas I'd like to air the discussions
here as I go for later reference by others as well as me.
OK, first up is a comment asked with beguiling innocence by Neil.
Here's the background:
> Neil Puttock wrote Saturday, November 28, 2009 6:01 PM
>> 2009/11/26 Trevor Daniels <[hidden email]>:
>>> Lettered fret indications
>>> Based on "Letter tablature formatting" example from LSR
>>> Needs to be installed in scm/translation-functions.scm
>>> Call it fret-letter-tablature-format
>> I notice the example pdf doesn't have whiteouts around the notes;
>> would you consider making this a tweakable option?
I replied "will do" before I realised the implications.
As it stands, impementing this without any control over whiteout
is trivial: simply install the LSR code in
and arrange for it to be called by overriding the context property
tablatureFormat. That's all.
Making the whiteout tweakable raises a question: should the
property controlling the whiteout be a context or a grob property?
Technically it could be either; ideally it should be a grob property
to provide tweakable control over individual grobs, even those
in chords, but this makes implementation more difficult.
Here's my current understanding; confirmation or discussion
At present the implemention of tablatureFormat is a simple
Scheme function called during translation, ie before grobs
are created. It has access to context properties but not grob
properties, as the grob does not exist. So to implement whiteout
as a grob property means changing the implementation from a
simple Scheme callout to C++ code in an engraver, and changing
from adding markup to creating stencils.
So, I can either implement it easily using a context property or
write it (later) as a routine called from the tablature engravers.
I'm still undecided which route to take.