Re: \class grob property
Huh, looks like I already created a changes entry and regtests for this output-attributes feature. https://codereview.appspot.com/308430043 https://sourceforge.net/p/testlilyissues/issues/4974/ I think I didn't do user documentation because the previous ID-only functionality didn't have any. So I can work on adding that somewhere. Looks like the infrastructure for really testing svg output is an open issue: https://sourceforge.net/p/testlilyissues/issues/5185/ (And since this functionality is not visible in the svg (by itself), tests would need to check the svg source code rather than its visual result.) Cheers, -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \class grob property
Am 17.05.2018 um 15:46 schrieb David Kastrup: Paul Morris writes: On 05/17/2018 09:00 AM, David Kastrup wrote: Man, I must have slept through this. "this is already supported in 2.19" is misleading if it's actually only supported _outside_ of 2.19, namely by chancing upon people in the know in the mailing lists. The problem with that kind of support is that it's unreliable. Stuff might get reimplemented because people cannot find what they are looking for, and the old code might get removed as bit rot at any point of time. To actually move it to "supported" state inside of LilyPond, there need to be regression tests (which also stop bit rot), user-level documentation and a Changes entry. That gives a new feature a reasonable chance of getting tested and consolidated in order to be useful for more than a single application (often by a single person) in its region of interest. Do you feel up to getting that kind of support into LilyPond? Hi David, I agree that this deserves to have regression tests, user-level docs, and a changes entry (to go with its current documentation in the internals reference). I'll try to find time to work on those things in the next weeks. That would be very appreciated. Just from the few bits I have read right now, it appears to me like the purpose, scope, and behavior of that extension is a whole lot more specific, prescriptive and predictable in connection with various backends than Urs' proposal. Not necessarily ;-) I think the main difference between Paul's and my descriptions is that his basically does *not* talk about use cases and simply describes what is implemented, while I tried to tease out suggestions by giving rather vage descriptions. However, the examples we've seen from Paul are better than what I had in mind in so far as this property is somewhat generic: it allows the user to generate arbitrary attributes in the XML elements, not only the standardized "id" and "class" ones. Which does not preclude Urs building some higher-level functionality of the kind he envisions based on this. Exactly :-) Best Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \class grob property
Paul Morris writes: > On 05/17/2018 09:00 AM, David Kastrup wrote: > >> Man, I must have slept through this. "this is already supported in >> 2.19" is misleading if it's actually only supported _outside_ of 2.19, >> namely by chancing upon people in the know in the mailing lists. >> >> The problem with that kind of support is that it's unreliable. Stuff >> might get reimplemented because people cannot find what they are looking >> for, and the old code might get removed as bit rot at any point of time. >> >> To actually move it to "supported" state inside of LilyPond, there need >> to be regression tests (which also stop bit rot), user-level >> documentation and a Changes entry. That gives a new feature a >> reasonable chance of getting tested and consolidated in order to be >> useful for more than a single application (often by a single person) in >> its region of interest. >> >> Do you feel up to getting that kind of support into LilyPond? > > Hi David, I agree that this deserves to have regression tests, > user-level docs, and a changes entry (to go with its current > documentation in the internals reference). I'll try to find time to > work on those things in the next weeks. That would be very appreciated. Just from the few bits I have read right now, it appears to me like the purpose, scope, and behavior of that extension is a whole lot more specific, prescriptive and predictable in connection with various backends than Urs' proposal. Which does not preclude Urs building some higher-level functionality of the kind he envisions based on this. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \class grob property
On 05/17/2018 09:00 AM, David Kastrup wrote: Man, I must have slept through this. "this is already supported in 2.19" is misleading if it's actually only supported _outside_ of 2.19, namely by chancing upon people in the know in the mailing lists. The problem with that kind of support is that it's unreliable. Stuff might get reimplemented because people cannot find what they are looking for, and the old code might get removed as bit rot at any point of time. To actually move it to "supported" state inside of LilyPond, there need to be regression tests (which also stop bit rot), user-level documentation and a Changes entry. That gives a new feature a reasonable chance of getting tested and consolidated in order to be useful for more than a single application (often by a single person) in its region of interest. Do you feel up to getting that kind of support into LilyPond? Hi David, I agree that this deserves to have regression tests, user-level docs, and a changes entry (to go with its current documentation in the internals reference). I'll try to find time to work on those things in the next weeks. Cheers, -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \class grob property
Paul Morris writes: > Hi Urs, > > On 05/13/2018 02:02 PM, Urs Liska wrote: > >> 1) for SVG output the objects would get the class assigned (along >> with an id). I don't have any idea yet how that is implemented, >> though. This will make it possible to work with CSS in a display >> environment. > > You'll be glad to know this is already supported in 2.19. Check out > this grob property: > > |output-attributes| (list) > >An alist of attributes for the grob, to be included in output files. >When the SVG typesetting backend is used, the attributes are >assigned to a group () containing all of the stencils that >comprise a given grob. For example, |'((id . 123) (class . foo) >(data-whatever . “bar”))| will produce |data-whatever=“bar”> … |. In the Postscript backend, where there >is no way to group items, the setting of the output-attributes >property will have no effect. > > > It's only documented in the internals reference. I think it probably > gives you what you need to do what you want? > > I added this functionality to LilyPond awhile back while working on > 'lilypond-html-live-score'. (Would like to find more time to do more > work with that, but...) This code might be of interest: > https://gitlab.com/sigmate/lilypond-html-live-score/blob/master/grob-inspector.ily Man, I must have slept through this. "this is already supported in 2.19" is misleading if it's actually only supported _outside_ of 2.19, namely by chancing upon people in the know in the mailing lists. The problem with that kind of support is that it's unreliable. Stuff might get reimplemented because people cannot find what they are looking for, and the old code might get removed as bit rot at any point of time. To actually move it to "supported" state inside of LilyPond, there need to be regression tests (which also stop bit rot), user-level documentation and a Changes entry. That gives a new feature a reasonable chance of getting tested and consolidated in order to be useful for more than a single application (often by a single person) in its region of interest. Do you feel up to getting that kind of support into LilyPond? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \class grob property
Hi Paul, thanks for this information. This is indeed exactly what I was looking for and will make life easier for several things. I think we'll be investigating the options in this year's GSoC project, maybe that will be helpful thinking about hierarchical stylesheets another way. Best Urs Am 17.05.2018 um 14:15 schrieb Paul Morris: Hi Urs, On 05/13/2018 02:02 PM, Urs Liska wrote: 1) for SVG output the objects would get the class assigned (along with an id). I don't have any idea yet how that is implemented, though. This will make it possible to work with CSS in a display environment. You'll be glad to know this is already supported in 2.19. Check out this grob property: |output-attributes| (list) An alist of attributes for the grob, to be included in output files. When the SVG typesetting backend is used, the attributes are assigned to a group () containing all of the stencils that comprise a given grob. For example, |'((id . 123) (class . foo) (data-whatever . “bar”))| will produce | … |. In the Postscript backend, where there is no way to group items, the setting of the output-attributes property will have no effect. It's only documented in the internals reference. I think it probably gives you what you need to do what you want? I added this functionality to LilyPond awhile back while working on 'lilypond-html-live-score'. (Would like to find more time to do more work with that, but...) This code might be of interest: https://gitlab.com/sigmate/lilypond-html-live-score/blob/master/grob-inspector.ily Cheers, -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \class grob property
Hi Urs, On 05/13/2018 02:02 PM, Urs Liska wrote: 1) for SVG output the objects would get the class assigned (along with an id). I don't have any idea yet how that is implemented, though. This will make it possible to work with CSS in a display environment. You'll be glad to know this is already supported in 2.19. Check out this grob property: |output-attributes| (list) An alist of attributes for the grob, to be included in output files. When the SVG typesetting backend is used, the attributes are assigned to a group () containing all of the stencils that comprise a given grob. For example, |'((id . 123) (class . foo) (data-whatever . “bar”))| will produce | … |. In the Postscript backend, where there is no way to group items, the setting of the output-attributes property will have no effect. It's only documented in the internals reference. I think it probably gives you what you need to do what you want? I added this functionality to LilyPond awhile back while working on 'lilypond-html-live-score'. (Would like to find more time to do more work with that, but...) This code might be of interest: https://gitlab.com/sigmate/lilypond-html-live-score/blob/master/grob-inspector.ily Cheers, -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \class grob property
2018-05-14 11:55 GMT+02:00 Urs Liska : > I wasn't aware of the fact that you can simply add unknown properties to the > 'details'. It's a little so-so. 'details is an established grob-property, and we don't type-check sub-properties. But not every grob has 'details per default Meaning: compiling with -dcheck-internal-types will likely show some programming errors. Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \class grob property
Hi Harm,
Am 14.05.2018 um 10:36 schrieb Thomas Morley:
2018-05-14 8:50 GMT+02:00 Urs Liska :
Am 14.05.2018 um 00:02 schrieb David Kastrup:
Urs Liska writes:
Hi all,
I'm thinking about having a new grob property \class, but before
digging deeper I'd like to put the idea up for discussion.
This would have two different goals:
1) for SVG output the objects would get the class assigned (along with
an id). I don't have any idea yet how that is implemented,
though. This will make it possible to work with CSS in a display
environment.
2) (Formatting) functions can check for a grob's class to perform
e.g. highlighting operations (=> color all NoteHeads with class
"temporary" red)
In addition I would like to use that to export class information to
MusicXML.
Any comments or objections?
The various semantics seem to be tied more to the word "class" than a
common concept underlying the proposed uses of this property. Maybe
explain some more what the generic concept of class should be and why
the proposed backend semantics are in every case the proper match to the
concept?
The idea is to give various grobs a secondary name, making same-named grobs
belong to a group of objects where the grouping is independent from
groupings like grob type or voice/staff/measure/etc. context. To express
what I mean other words would be appropriate as well, such as e.g. "type",
but I would suggest to use the same word (and concept) as is used in CSS.
In scholarly editions you may have score items you want to mark up as
"addition", "emendation", "deletion". It's already possible to define music
functions that produce the highlighting you want to apply to these types of
grobs, for example dash slurs added by the editor. With that you also have a
way to centrally control the appearance, for example to also use colors
while working on the edition and suppress that for the final publication.
However, the resulting grob will not "know" it is an addition but only that
it is dashed and green, for example.
My suggestion is to have the possibility (which of course doesn't discourage
the use of music functions as would be done currently) to instead set a
grob's 'class' property to semantically mark up that grob instead of
(directly) changing its appearance, deferring the styling to a later stage.
In LilyPond this can for example be an engraver that tests grobs for their
class property and acts upon that.
If the class property is exported to SVG then the appearance of objects can
be controlled interactively with CSS. The same should be possible when
exporting to MusicXML.
Probably an engraver should be made available as well (but not consisted to
any context by default), along with a means of defining "styles" (maybe an
alist of property/value pairs) that will be applied to grobs with the given
class. A style should be somewhat hierarchical, at least to allow generic
property/value pairs and additional ones for specific grob types (for
example note heads should probably not be dashed ...). I haven't thought
about the idea of actually make styles cascading like in CSS, and I'm not
sure there's an appropriate concept of nestedness that would make that a
natural thing to pursue.
I think it would be nice to provide a command [\once] \class
which should also be usable as a \tweak on individual grobs.
Very practical would also be to have a context property as well, so
\set Voice.class = "unclear"
would attach the class to every grob within its scope.
Like with CSS multiple classes should be possible with
\class Beam "unclear addition"
My examples so far all come from scholarly editing but I think this could
open up a wide array of use cases. Think about classes like the following:
\class LyricText "excited"
\set Voice.class = "muted"
\class Hairpin "grey1 dashed with-text"
\class RehearsalMark "rehearsal-mark"
\class RehearsalMark "section-mark"
Urs
Hi Urs,
it's still not very clear to me what you want.
This may be due to my limited knowledge of the english language: I
tend to skip detailed explanations.
Not always the right thing, I have to admit...
I'd prefer code.
You certainly know how to define custom context/grob-properties. But
even without doing so, below row implementation is possible. At least
for grobs.
TstEngraver =
#(lambda (context)
(make-engraver
(acknowledgers
((grob-interface engraver grob source-engraver)
(let* ((details (ly:grob-property grob 'details '()))
(class (assoc-get 'class details)))
(cond ((symbol-list? class)
(if (member 'deleted class)
(ly:grob-set-property! grob 'color grey)))
((symbol? class)
(case class
((addition)
(ly:grob-set-property! grob 'color red))
(else '())
\layout {
\context {
\Voice
\consists \TstEngraver
}
}
{
\once \
Re: \class grob property
2018-05-14 8:50 GMT+02:00 Urs Liska : > > > Am 14.05.2018 um 00:02 schrieb David Kastrup: >> >> Urs Liska writes: >> >>> Hi all, >>> >>> I'm thinking about having a new grob property \class, but before >>> digging deeper I'd like to put the idea up for discussion. >>> >>> This would have two different goals: >>> >>> 1) for SVG output the objects would get the class assigned (along with >>> an id). I don't have any idea yet how that is implemented, >>> though. This will make it possible to work with CSS in a display >>> environment. >>> >>> 2) (Formatting) functions can check for a grob's class to perform >>> e.g. highlighting operations (=> color all NoteHeads with class >>> "temporary" red) >>> >>> In addition I would like to use that to export class information to >>> MusicXML. >>> >>> Any comments or objections? >> >> The various semantics seem to be tied more to the word "class" than a >> common concept underlying the proposed uses of this property. Maybe >> explain some more what the generic concept of class should be and why >> the proposed backend semantics are in every case the proper match to the >> concept? >> > > The idea is to give various grobs a secondary name, making same-named grobs > belong to a group of objects where the grouping is independent from > groupings like grob type or voice/staff/measure/etc. context. To express > what I mean other words would be appropriate as well, such as e.g. "type", > but I would suggest to use the same word (and concept) as is used in CSS. > > In scholarly editions you may have score items you want to mark up as > "addition", "emendation", "deletion". It's already possible to define music > functions that produce the highlighting you want to apply to these types of > grobs, for example dash slurs added by the editor. With that you also have a > way to centrally control the appearance, for example to also use colors > while working on the edition and suppress that for the final publication. > However, the resulting grob will not "know" it is an addition but only that > it is dashed and green, for example. > > My suggestion is to have the possibility (which of course doesn't discourage > the use of music functions as would be done currently) to instead set a > grob's 'class' property to semantically mark up that grob instead of > (directly) changing its appearance, deferring the styling to a later stage. > In LilyPond this can for example be an engraver that tests grobs for their > class property and acts upon that. > If the class property is exported to SVG then the appearance of objects can > be controlled interactively with CSS. The same should be possible when > exporting to MusicXML. > > Probably an engraver should be made available as well (but not consisted to > any context by default), along with a means of defining "styles" (maybe an > alist of property/value pairs) that will be applied to grobs with the given > class. A style should be somewhat hierarchical, at least to allow generic > property/value pairs and additional ones for specific grob types (for > example note heads should probably not be dashed ...). I haven't thought > about the idea of actually make styles cascading like in CSS, and I'm not > sure there's an appropriate concept of nestedness that would make that a > natural thing to pursue. > > I think it would be nice to provide a command [\once] \class > which should also be usable as a \tweak on individual grobs. > Very practical would also be to have a context property as well, so > \set Voice.class = "unclear" > would attach the class to every grob within its scope. > > Like with CSS multiple classes should be possible with > \class Beam "unclear addition" > > My examples so far all come from scholarly editing but I think this could > open up a wide array of use cases. Think about classes like the following: > \class LyricText "excited" > \set Voice.class = "muted" > \class Hairpin "grey1 dashed with-text" > \class RehearsalMark "rehearsal-mark" > \class RehearsalMark "section-mark" > > Urs Hi Urs, it's still not very clear to me what you want. This may be due to my limited knowledge of the english language: I tend to skip detailed explanations. Not always the right thing, I have to admit... I'd prefer code. You certainly know how to define custom context/grob-properties. But even without doing so, below row implementation is possible. At least for grobs. TstEngraver = #(lambda (context) (make-engraver (acknowledgers ((grob-interface engraver grob source-engraver) (let* ((details (ly:grob-property grob 'details '())) (class (assoc-get 'class details))) (cond ((symbol-list? class) (if (member 'deleted class) (ly:grob-set-property! grob 'color grey))) ((symbol? class) (case class ((addition) (ly:grob-set-property! grob 'color red))
Re: \class grob property
Am 14.05.2018 um 00:02 schrieb David Kastrup: Urs Liska writes: Hi all, I'm thinking about having a new grob property \class, but before digging deeper I'd like to put the idea up for discussion. This would have two different goals: 1) for SVG output the objects would get the class assigned (along with an id). I don't have any idea yet how that is implemented, though. This will make it possible to work with CSS in a display environment. 2) (Formatting) functions can check for a grob's class to perform e.g. highlighting operations (=> color all NoteHeads with class "temporary" red) In addition I would like to use that to export class information to MusicXML. Any comments or objections? The various semantics seem to be tied more to the word "class" than a common concept underlying the proposed uses of this property. Maybe explain some more what the generic concept of class should be and why the proposed backend semantics are in every case the proper match to the concept? The idea is to give various grobs a secondary name, making same-named grobs belong to a group of objects where the grouping is independent from groupings like grob type or voice/staff/measure/etc. context. To express what I mean other words would be appropriate as well, such as e.g. "type", but I would suggest to use the same word (and concept) as is used in CSS. In scholarly editions you may have score items you want to mark up as "addition", "emendation", "deletion". It's already possible to define music functions that produce the highlighting you want to apply to these types of grobs, for example dash slurs added by the editor. With that you also have a way to centrally control the appearance, for example to also use colors while working on the edition and suppress that for the final publication. However, the resulting grob will not "know" it is an addition but only that it is dashed and green, for example. My suggestion is to have the possibility (which of course doesn't discourage the use of music functions as would be done currently) to instead set a grob's 'class' property to semantically mark up that grob instead of (directly) changing its appearance, deferring the styling to a later stage. In LilyPond this can for example be an engraver that tests grobs for their class property and acts upon that. If the class property is exported to SVG then the appearance of objects can be controlled interactively with CSS. The same should be possible when exporting to MusicXML. Probably an engraver should be made available as well (but not consisted to any context by default), along with a means of defining "styles" (maybe an alist of property/value pairs) that will be applied to grobs with the given class. A style should be somewhat hierarchical, at least to allow generic property/value pairs and additional ones for specific grob types (for example note heads should probably not be dashed ...). I haven't thought about the idea of actually make styles cascading like in CSS, and I'm not sure there's an appropriate concept of nestedness that would make that a natural thing to pursue. I think it would be nice to provide a command [\once] \class which should also be usable as a \tweak on individual grobs. Very practical would also be to have a context property as well, so \set Voice.class = "unclear" would attach the class to every grob within its scope. Like with CSS multiple classes should be possible with \class Beam "unclear addition" My examples so far all come from scholarly editing but I think this could open up a wide array of use cases. Think about classes like the following: \class LyricText "excited" \set Voice.class = "muted" \class Hairpin "grey1 dashed with-text" \class RehearsalMark "rehearsal-mark" \class RehearsalMark "section-mark" Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \class grob property
Urs Liska writes: > Hi all, > > I'm thinking about having a new grob property \class, but before > digging deeper I'd like to put the idea up for discussion. > > This would have two different goals: > > 1) for SVG output the objects would get the class assigned (along with > an id). I don't have any idea yet how that is implemented, > though. This will make it possible to work with CSS in a display > environment. > > 2) (Formatting) functions can check for a grob's class to perform > e.g. highlighting operations (=> color all NoteHeads with class > "temporary" red) > > In addition I would like to use that to export class information to > MusicXML. > > Any comments or objections? The various semantics seem to be tied more to the word "class" than a common concept underlying the proposed uses of this property. Maybe explain some more what the generic concept of class should be and why the proposed backend semantics are in every case the proper match to the concept? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
