|
From: | Urs Liska |
Subject: | Re: Scholarly footnotes |
Date: | Wed, 11 Nov 2015 19:16:54 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
Am 10.11.2015 um 17:39 schrieb Urs
Liska:
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 |
[Prev in Thread] | Current Thread | [Next in Thread] |