[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [frogs] Enhancement request: Define output-suffix as a configurable

From: Neil Puttock
Subject: Re: [frogs] Enhancement request: Define output-suffix as a configurable context property.
Date: Mon, 21 Sep 2009 21:38:41 +0100

2009/9/19 Carl Sorensen <address@hidden>:

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]