Re: Stencils

[David Feuer]

On 4/6/06, Han-Wen Nienhuys <address@hidden> wrote:
> David Feuer wrote:
> > I don't see it.  stencil-interpret.cc seems neither particularly
> > complex nor particularly efficient.  Speaking of which, all the Scheme
> > code heavily overuses lists.  Guile provides records and structures
> > (I'm not sure of the difference yet).  We should use them.
>
> I guess you're right. Do you have a specific idea you'd like to work on?
> FWIW, it would be cool if we could add a libgnomeprint backend to lily,
> so we could have direct PDF generation, without requiring Ghostscript

I have an idea, yes.  My biggest hurdle, coding-wise, is that I don't
know the Guile C++/Scheme interfaces at all, and I'm not too good with
C++ (though I am good at C), so when I look at the C++ code I can only
get a rough idea of what's going on.  My concept is:

1.  Change the Scheme stencil representation to use lists only where
lists make sense, and structures/records and vectors elsewhere.

2.  Make the framework*.scm files drive the output process from start
to finish, as coroutines with the formatter and each other.  I haven't
yet figured out how page and line breaking happens, so this is a rough
idea, and is based on a paged score (rather than fragments), but this
should be able to adapt to whatever really happens:

I.  Lilypond parses input file.
II.  Lilypond calls the master output functions in the framework files
as coroutines in a round-robin fashion.  Each of them does some work
and then calls get-page, which returns control to Lilypond.  Once all
the master output functions have called back, Lilypond formats the
first page and returns it to the first fragment, etc.

The master output functions look something vaguely like:

(define (master-output global-settings outputter get-page)
   (outputter (make-header relevant-globals))
   (let do-page ()
      (outputter (output-page (get-page)))
      (do-page))
   (outputter (make-footer relevant-globals)))

Where output-page is a procedure for taking a page description
(composed of page information and translated-stencil thunks) and
putting together a page.  I said translated-stencil thunks because
when the master outputter uses that thunk (which may actually be
slightly more than a thunk), control shifts to a procedure that
manages thunks and stencils much as Lilypond handles pages.  I'm not
sure of the exact order, but roughly, that procedure will continue its
round-robin.  When it gets back, it'll call the appropriate stencil
translator and return the result to output-page.  The motivation for
this architecture is to support shared stencil translators (between,
say the PostScript and the TeX backends) without having to translate
any stencil more times than necessary, and to manage that without
making the backends deal with the complexities of keeping track of the
translated stencils.  As complicated as this looks as I write it, I
don't think the code itself will be too complex.

David Feuer