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

[Carl Sorensen <c_sorensen@xxxxxxx>]

On 9/21/09 2:38 PM, "Neil Puttock" <n.puttock@xxxxxxxxx> wrote:

> 2009/9/19 Carl Sorensen <c_sorensen@xxxxxxx>:
> 
>> 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.

OK, so what sends Paper_book objects to output frameworks?

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

I agree.  My understanding is that first, grobs are created (and grobs are
*not* ink on paper, they are scheme objects that will eventually be
converted into ink on paper).

Once grobs are created, layout happens (line breaking, page breaking, and
collision resolution, I think).  During layout, properties of grobs are
changed, and new grobs are sometimes created.

Then, once layout happens, Paper_book objects are sent to output framework
where they are converted into output that will ultimately put ink on the
page (e.g. postscript instructions, or svg instructions).

Is this even close?


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

What do you think of Ian's suggestion to create pv-properties for parser
variables?

Carl


---

----
Join the Frogs!