Am 14.05.2018 um 00:02 schrieb David Kastrup:
Urs Liska <li...@openlilylib.org> 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 <grob-type>
<class-name> 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
