Re: Allows for framing comments in LilyPond backends. (issue 5450086)

[address@hidden]

Le Dec 4, 2011 à 4:51 PM, Ralf Mattes a écrit :

> On Sun, 04 Dec 2011 10:12:55 +0000, mtsolo wrote:
> 
>> Reviewers: ,
>> 
>> Message:
>> Hey all,
>> 
>> I'm working on a piece w/ scripted SVG, and this'll make it easier for
>> me to parse the file in Python and move things around.  Try it with:
>> 
>> \relative c' {
>>  \override NoteHead #'framing-comments = #'("NoteHead coming up." .
>>  "NoteHead finished.") \repeat unfold 16 { f }
>> }
>> 
>> Then use the svg or ps backend and look for these comments.
> 
> 
> Sorry, but I think this a rather uggly and hackish solution.

I make no claims to the contrary - this type of thing is precisely for those 
who will subsequently hack their way through a document.

> You treat comments as meta-markup in a markup language. Kind of against 
> the purpose, isn't it?

Comments are used all the time to provide additional information via 
meta-markups.  EPS documents, for example, work that way to communicate the 
BoundingBox.

> (And I have a nagging feeling that you try to
> process xml with regular expressions instead of xpath/xtransform. 
> Something considered a "bad idea" ... ;-)

I'm using pyparsing to take the comments, read them, and then integrate them 
back into the document intelligently via svgwrite.  It is a 10-line-of-code 
hack to get all of the information into python cleanly.  But that's just me.  
This code is the most open way to allow people who hack their way through 
lilypond-generated documents to perform said hacks.  In my opinion, anything 
more specific would be too restrictive.

> I'd be more that happy with the possibility to mark thing in the xml
> output, but why not a lily:marker attribute? 

I see two issues with this.

1) A grob's stencil can span several xml nodes in the svg output.  It's unclear 
which of these nodes should receive the lily:marker attribute.
2) Even if you wrapped these nodes in <g></g> (which is what I did in an 
earlier version of this patch), this would not necessarily be desirable.  Too 
many <g></g> constructs slow down SVG animations, for example (SVG animations 
are the indirect reason I'm proposing this patch, so I'm particularly sensitive 
to this issue).  One could easily do:

\relative c' {
 \override NoteHead #'framing-comments = #'("UNCOMMENTME<g>" .
 "UNCOMMENTME</g>") \repeat unfold 16 { f }
}  

And then a 5 line python script (or even Scheme w/in LilyPond) could create the 
actual svg by scanning for <!--UNCOMMENTME<g>--> and<!--UNCOMMENTME</g>--> .

> BTW, your patch is pretty fragile: try the following:
> 
> \relative c' {
>  \override NoteHead #'framing-comments = #'("NoteHead coming up." .
>  "--> look here") \repeat unfold 16 { f }
> }  

If someone who is haxorish enough to use this feature puts that into their 
SVG-exported LilyPond file, then I'd consider it their own fault.

Cheers,
MS