Re: Scholarly footnotes

[Urs Liska]

Am 11.11.2015 um 19:16 schrieb Urs Liska:
> 
> 
> Am 10.11.2015 um 17:39 schrieb Urs Liska:
>>
>>
>> Am 10.11.2015 um 17:08 schrieb Graham King:
>>> ...  long snip ...
>>>
>>> I confess I'm a bit daunted by the LaTeX learning curve, and it is
>>> possible that I'm not uniquely inadequate in that respect.  So a
>>> Lilypond-only solution would be ideal for me, and would save others
>>> the prospect of learning yet-another-language.  
>>
>> OK, on the long run I will want to have both, but actually it doesn't
>> matter where to start ...
>>
>>> I'm brainstorming a bit here, but if, for example, ScholarLy could
>>> make its annotations available as a Scheme array for metadata and
>>> markup, the lilypond user could access that array in a \markup block
>>> after the end of the music.  Layout could then be left to the user,
>>> selecting just the desired elements of data.
>>>
>>> The array might look something like:
>>> (((author . "A.N.Other")
>>>   (bar . 2)
>>>   (beat . 1)
>>>   (text . "\markup { \note #"4" #1 } added")
>>>   ...)
>>> ((author . "F.Bloggs")
>>>   (bar . 5)
>>>   ...)
>>> ...))
>>
>> I haven't looked in the code right now, but I'm pretty sure there *is*
>> such a Scheme tree structure at some point. The question is if that is
>> available at the moment we'd need it.
>> While parsing the input annotations are built and added to an array,
>> and when parsing is finished they are processed, i.e. sorted,
>> (optionally) filtered and exported. I'm not sure if a reasonable
>> representation is already available when regular markup is used and
>> interpreted.
>>
>> One thing should definitely be possible: Writing that structure out to
>> a temporary file and read that in at a later moment. Maybe this would
>> allow to use the data only in another bookpart? But that's something
>> to be discussed with those people who know more about the process of
>> collecting elements of a book.
>>
> 
> Now I've looked into it *to some extent*, and it seems my assumption was
> quite appropriate.
> 
> 'annotate' works in two steps and has two separate engravers:
> \annotationCollector is (automatically) consisted to all the staff-like
> contexts. Whenever it comes across an annotation in the input it appends
> an object to a global 'annotations' list.
> 
> Later \annotationProcessor (which is consisted to the Score context)
> iterates over this list, applies filtering and sorting, and exports it
> to the desired targets.
> 
> It is possible to access the annotations list/array from within
> \annotationProcessor, and it is easy to create a command (like e.g.
> \printReport) that switches of a certain processing.
> 
> But when I try to access the 'annotations' object from LilyPond input
> (be it from a toplevel command before or after the score or whenever, or
> from within the music) this object seems to be empty.
> 
> So I assume that it's only possible to access the information from
> within the engraver and not from the user code.
> 
> This leaves two options, and I would like to get an opinion which of
> these is/are possible:
> 
> a)
> have that \annotationProcessor produce some markup in the current score,
> presumably (starting) on a new page at the end of the score or have it
> create a new bookpart consisting of such markup
> 
> b)
> write out the data to a temporary file (clearly possible) for another
> command. This would have to read in the data and produce the necessary
> markup. Would it be possible to place such a command in a new bookpart,
> i.e. have an engraver in one bookpart write out something to disk and
> sos me other function in a later bookpart read that in again?
> 
> c)
> as a last resort LilyPond could write the data to a temporary file and a
> second command could process that data from within *another* file that
> would have to be compiled separately.
> This would of course be quite hacky but still avoid having to use a
> second tool (LaTeX).
> 
> I'd be grateful for any opinions/suggestions/solutions.
> 
> Urs
> 

Having had a night over it I realized that there is an obvious first
step towards b) and c) and that the infrastructure is already there for it!
I will add support for writing out the raw Scheme object and simply
integrate it as an additional export-target. I wouldn't mind if someone
would give me a hint with regard to (de-)serializing a Scheme object to
and from a file before I'll have the opportunity to look into it myself ;-)

When that file is available I can then see at what point it's there so I
can see if b) or c) or both are possible.

Urs


-- 
Urs Liska
www.openlilylib.org