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='//[@lily: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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel