lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: address@hidden
Subject: Re: Allows for framing comments in LilyPond backends. (issue 5450086)
Date: Sun, 4 Dec 2011 18:53:31 +0100

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

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

Cheers,
MS


reply via email to

[Prev in Thread] Current Thread [Next in Thread]