lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: \class grob property


From: David Kastrup
Subject: Re: \class grob property
Date: Thu, 17 May 2018 15:00:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Paul Morris <address@hidden> 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 (<g>) containing all of the stencils that
>    comprise a given grob. For example, |'((id . 123) (class . foo)
>    (data-whatever . “bar”))| will produce |<g id=“123” class=“foo”
>    data-whatever=“bar”> … </g>|. 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]