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 _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user