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

[Ralf Mattes]

On Sun, 04 Dec 2011 18:53:31 +0100, address@hidden wrote:

> Le Dec 4, 2011 à 6:43 PM, Ralf Mattes a écrit :
> 
>> On Sun, 04 Dec 2011 16:57:27 +0000, Ralf Mattes wrote:
>> 
>> 
>>> 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>
>>> 
>>> 
>> BTW, there are a few more items on my personal svg wishlist (isn't
>> christmas approaching?):
>> 
>> * an easy way to control node ids (again: having an id for
>>   lilypond entities would be great - we could do click-to-edit or
>>   (midi)-playback in an HTML-5 browser).
>> 
>> * Maybe use 'use'? Emitting the same path for every notehead, barline
>> or
>>   staff line seems redundant. Why not define these at the start of the
>>   document and use them later on with 'svg:use'?
>> 
>> Just dreaming ....
> 
> These things are on my wishlist as well.  It seems like all things are
> going the way of XML, 

Let's hope not :-)

> .... and people have been kicking around ideas of
> making LilyPond more XML friendly for a long time now (check out the
> mailing list discussions about a ly->musicxml converter).

That would be great. I was a bit shocked to see that Lilypond uses string
formatting to output xml - that's really not the way to do it (and it will
break in unexpected situations). There are several scheme xml libraries 
that do serialization (guile for example has sxml, you could even use
sxml's transform module to do a lot of the modifications you need).
And then there is libxml2/libxslt which does excellent  output serialization as 
well (and xslt transformation).
  
> The issue is that LilyPond is a program cobbled together from many
> different contributors with different specialties and thus does not have
> a unified way of representing or channeling all graphical data
> (especially when it comes to getting these data to talk to each other). 

I know, I know, I had a look at the code.

> A big project of mine has been making \markups behave like grobs, but it
> may take me two years to get it all straightened away. 

That sounds marvelous! 

> I think that, in
> development, it's important to balance wishlist thinking (which is what
> I do with most of my patches) with expedients.  Obviously too much of
> the latter leads to really kludgy ways of using code, but too much of
> the former means that nothing ever gets done.

IMHO, "messy" spots attract more messy kludges - you might need you patch
just for your next project, but once it's in there's a good chance that it'll
stay and people will use it instead of doing it correctly.

 Cheers, RalfD   
> Cheers,
> MS