2009/9/19 Carl Sorensen <c_soren...@byu.edu>: > Well, during the translation step the translators write output to the output > file using the appropriate output calls, don't they? So they make use of > the file that was created using the output-prefix. So this has *something* > to do with translation, even though it's not a characteristic of an > engraver.
I don't think so, since the output file doesn't exist until a Paper_book object has been finalized and sent to the appropriate output framework. > This is part of the function of LilyPond that I don't understand. Maybe you > can help clarify it for me. Let me give my brief understanding. Seriously, I don't understand it either. :) > I think the third phase is engraving. During this phase, the music streams > are converted into printed objects, and sent to the appropriate output file. I think this phase is much more complicated than the other two, since there's a great deal of work going on after grobs have been created (e.g., line-breaking and page-breaking) before anything is dumped to an ouput file. > It would be convenient if the output-prefix could be defined in the /score > or /layout block that causes the creation of a Score context. I think > that's why Ian was wanting to make it a context property of Score. But I > suspect (although I can't prove) that the file handler exists *outside of*, > not inside of, the Score context. Hence, we don't want to make it a context > property of Score, because we could change the property inside of the Score, > and the file handler wouldn't know about it. I think this is the main stumbling block (leaving aside the issue of whether it's appropriate to store a file suffix at this point); I can't see any elegant (kludge-free) way of getting this information to the file handler. Regards, Neil _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
