Le Dec 4, 2011 à 5:57 PM, Ralf Mattes a écrit :
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 completely agree w/ respect to XML. The goal of this patch is to find a uniform way to put wrapping around the stencils coming from grobs in any backend (including postscript). People can then do whatever they want with these comments - even if its just for pedagogical/archival purposes (i.e. comments that say the name of the grob, the day it was created, its LilyPond properties, etc.), it is useful to have this info able to be exported into any backend. I admit that my personal usage is kludgy insofar as it is used, via processing, to create more xml information, but I think that the advantage of this patch is that people can use it for more or less anything where id-ing a the commands associated with a given grob in a given output format is necessary.
I'd like to go for some marking that's robust and reliable
within a xml processing workflow.
This is not at all incompatible with my patch, but it'd be another patch. Currently, there are certain stencils (i.e. embedded-ps) that only work in certain backends. For all backends in which xml matters (svg is the only whose existence I know of, although there could be other 3rd party stuff), this type of thing could be proposed as a separate commit.
BTW, you are aware of the fact that it's
entirely valid for a xml parser/transformer to _drop_ comments?
Yes, which is why anyone who uses framing-comments should know what they're doing. Anyone who uses it in an XML parser and expects it to do anything useful would, then, not know what they're doing.
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!
I agree, and this exists for two main reasons. To wit:
1) The type of heirarchical organization of material that is present in xml (and thus musicxml) is not uniformly present in LilyPond. For example, there is a NoteColumn grob in LilyPond that contains note heads, stems, flags, and arpeggios in its elements list but not tremoli, articulations, or fingerings.
2) Even if this did exist, stencils are completely decoupled from grobs before being shipped to a backend. This is because stencils can belong to things that are not only grobs - they can belong to toplevel markups, for example. One of my long (long) term projects is to standardize all this so that everything in LilyPond is a grob, but for now, this is not possible).
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>
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?
This is over my head...I trust you, though!
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 :-)
I agree that this is sub-ideal, but it is a quick way for me (or anyone) to get work done in anticipation of features arriving way down the line.
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?
I prefer this as well. The problem is that I have a piece that is being played on February 8th that I need to use this for and I don't have time to make all of the changes necessary to LilyPond to make it xml-friendly. I think that comments, as hackish as they are, are a last-ditch way to infuse information into a document and then do what one needs to do with it. But, as I said before, independent of the backend used (or the reason it is used), I think that it is useful to have comments that delimit grobs so that, when reading through the document, it becomes more human readable.