Le Dec 4, 2011 à 5:57 PM, Ralf Mattes a écrit :
> On Sun, 04 Dec 2011 17:19:50 +0100, m...@apollinemike.com 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='//[@lily: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.
Cheers,
MS_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
