Plan for revising markups ::
NAMESPACE MANGLING OF GROB PROPERTIES
--) function
All grob properties will be associated with their interface. So, `Y-extent'
will no longer be internally represented as `Y-extent' but rather
`Y-extent@grob-interface'. When someone does:
\override Stem #'Y-extent = #'(0 . 0)
or
(ly:grob-property stem 'Y-extent)
or
(ly:grob-set-property! stem 'Y-extent '(0 . 0))
LilyPond will automatically mangle the property to the right name by searching
all of the grob's interfaces and attaching the correct one.
If the user writes in the mangling, like:
\override Stem #'Y-extent@grob-interface = #'(0 . 0)
LilyPond will be smart enough not to do the automatic mangling.
--) rationale
Eventually, in the model elaborated below, advanced users will be creating
their own grobs on the fly with custom properties and interfaces. Most of
these definitions will need to be basic, on the order of:
#(define-markup-command (foo layout props bottom top)
...)
#(define-markup-command (bar layout props bottom top)
...)
LilyPond will do some magic (through functions...ideally not through macros) to
create the "Foo" grob with properties bottom@foo-markup-interface and
top@foo-markup-interface that implements markup-interface and
foo-markup-interface. Ditto for the Bar grob. This type of namespace mangling
assures that no properties are double-defined. It is a sort of namespacing of
properties.
REWRITE OF define-markup-command
--) function
All markup commands should do either two things.
1) The creation of a Grob.
2) The overriding of a Grob.
So:
\markup "foo"
Will create a `MarkupText' grob that has as its #'text property "foo"
\markup \raise #0.5 \note #"4" #UP
Will create a `NoteColumn' grob that has its Y-offset property chained to a
callback that raises it by 0.5.
\markup \column { foo bar }
Will create a `Container' grob that has in its element list two MarkupText
grobs and a layout-manager property of column-layout-manager (see below).
\markup \concat { foo bar }
Will create a `Container' grob that has in its element list two MarkupText
grobs and a layout-manager property of concat-layout-manager.
Somehow, define-markup-command will have to do the on-the-fly creation of grob
definitions if they don't already exist and create the corresponding grobs.
--) rationale
Currently, all markups are evaluated @ compile time save certain esoteric
situations. This means that they cannot communicate with scores at all. It
makes their layout possibilities rather limited and requires kludgy functions
to deal with retrieving page numbers and footnotes for markups. If every
graphical object in LilyPond has the internal representation of a grob, it'll
make handling them much more uniform and extensible.
CREATION OF THE LayoutManager CLASS
--) function
SpacingSpanner, Page_layout_manager, and other things that take care of the
positioning of other grobs will inherit fro the layout manager class. In
theory, any layout manager should be able to take a group of grobs and lay them
out according to their rules (i.e. Java).
--) rationale
Currently, there are a lot of aspects of LilyPond with shared functionality
(i.e. \justify in markup-speak and the SpacingSpanner) that are not grouped
together in class inheritance mechanisms. By doing this, we'll provide an
easier template for future development.
ELIMINATION OF THE Prob CLASS
--) function
Everything is a grob. A System is a grob that can be split up into several
systems and put into a Container grob with a MarkupText.
A Page is a spanner that is split into several broken_intos_ on which various
other grobs are put.
A Book is an object that contains several pages in a given orientation
(vertical, horizontal, etc.).
--) rationale
With this addition, a cross-staff Beam can theoretically connect beams from two
different scores on the same Page (or even the same Book) because there will
always be a common-Y.
EXTENSIBILITY
--) function
LayoutManagers and grobs should be easy to define on the fly through various
channels. define-markup-command should, in theory, be able to define both
(depending on what the markup command does).
--) rationale
This is in keeping with developments in LilyPond like Scheme engravers.
*****
That's a lot of text! But, it may be worth it to go down this road now. At
the coding partaaayyyy, Nicolas Sceaux told me that the idea was kicked around
before I was born to do some serious overhaul on markups, but it was then
decided that this was more trouble than it was worth, so markups kinda stay put
in their conceptual advancement while grobs took many great leaps forward.
It'd be great to get markups to this level of sophistication as well, mostly so
I could typeset the contemporary music example on the SCORE webpage using
LilyPond.
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
