Re: Extending \lilypondfile to support separate handling of header fields for use by LaTeX et.al.

[Bernard Hurley]

On Sun, 2006-01-01 at 13:12 -0500, Michael Haynie wrote:

Some more thoughts on markup:

1] My method of dealing with this does not currently handle lilypond
markup at all. This is because it uses regular expressions to handle the
header block and assumes the first "}" is the end of the block. It would
be possible to patch this up a bit using regular expressions - for
instance ignoring "}" symbols that occur in quotes. But this would
assume all the header fields look like:

        field = "value"

(There is still the problem of quotes in quotes, but there are ways
round this.) To do anything more sophisticated would require a parser.

2] If you are going to use a lilypond-book-like program to handle the
formatting, why bother about lilypond markup at all? Why not simply
allow LaTeX markup within the "value" string? A clean way of doing this
would be to have extra headers like "latextitle" etc. The idea being
that if only "title" exits we use it, but if "latextitle" exists we
substitute that.

3] There is still the problem of actually extracting a header containing
lilypond markup, which, as I say, my code dosn't do yet, All header
entries seem to have one of the formats:

        field = "value"
        field = ##t 
        field = ##f
        field = #( ... scheme code ... )
        field = \markup .... text markup .....

If [2] is implemented then we are not going to translate this into LaTeX
and so a fairly simple parser could be used, one that merely recognises
the correct format for markup etc. It could a string in all cases, or
may be simply ignore entries not of the first type. In any case it would
be easier than trying to do the translation into LaTeX markup, and would
be less afected by changes in the lilypond parser.

        /Bernard

> * markup in header text is not handled well at all.  I'm really not 
> certain how to proceed -- the lilypond markup doesn't look much like 
> the equivalent LaTeX markup, though some type of parser should be able 
> to translate from one form to the other.  It would be easy to write 
> such a filter in C/C++, but that would introduce yet another language 
> into the mix.  Not a happy thought.  A top-down parser could be 
> hand-written, I suppose.
>