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. > _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel