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

[Ralf Mattes]

On Sun, 04 Dec 2011 17:19:50 +0100, address@hidden wrote:

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

Yes, indeed. But Postscript is _not_ any kind of structural markup, and 
it's not meant to be postprecessed and those comments are an afterthought
(i.e. how to add information without breaking the spec). Postscript is
a kind of "drawing assembler" (or forth, but this doesn't matter for this
discussion). One ofthe  big benefits of xml is exactly the structure of
the markup and the possibility to do tree editing instead of text 
replacement.  I'd like to go for some marking that's robust and reliable
within a xml processing workflow. BTW, you are aware of the fact that it's
entirely valid for a xml parser/transformer to _drop_ comments?
 
>> (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.

My point ;-) Lilypond's svg output is way to unstructured! SVG everything
in place to mark up semantic units - just add a lily:mark attribute.
BTW, this would make editing of lilypond's output so much more easy.
One more nice thing about attributes: you could have more than one 
without worrying about proper nesting. So you could mark grobs as well as
i.e. the voices a grob belongs to. Imagine a xslt stylesheet where 
you could select/transform node 

  <xsl:template match='//address@hidden:function = 'cantus firmus'>
    <!-- do something special with C.F. notes here .. -->
  </xsl:template>


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

Ah, the same reason why I looked at this briefly ;-) If the grouping 
really starts to become a performance issue than remove it in the final 
output - that's dead easy with xslt, isn't it?

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

Yes, but then you don't operate on the textual representation of the 
document rather than the node tree. That's considered "not a smart idea"
(and a long time standing joke about so called "web programmers" - for 
someone with only regexp everysing starts to look like a string 
substitution :-)
 
>> 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.

I personally prefer robust code over fragile hacks, belive me, at some 
point someone _will_ enter such characters of death. Why waste debugging 
time?

 Cheers, RalfD
  
> Cheers,
> MS