lilypond-auto
[Top][All Lists]
Advanced

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

Re: [Lilypond-auto] Issue 3524 in lilypond: Patch: Allows inner-markup s


From: lilypond
Subject: Re: [Lilypond-auto] Issue 3524 in lilypond: Patch: Allows inner-markup spacing using skylines.
Date: Fri, 06 Sep 2013 04:23:13 +0000


Comment #8 on issue 3524 by address@hidden: Patch: Allows inner-markup spacing using skylines.
http://code.google.com/p/lilypond/issues/detail?id=3524

Here is the principal thing that I balk at: we have code in the page builder (and elsewhere) that uses skylines. So the skylines have obvious utility. However, skylines are not really integrated into the model of a stencil at all. Why would we want or need to see them integrated?

Because there are inherent uses. The normal way of stacking systems will put a fixed distance between the staves unless skylines intersect in which case they will get pushed further apart based on skylines. And that's actually also the way lines are usually spaced: fixed distance between baselines (box dimensions), additional space when skylines intersect with each other. Even when we are spacing lyrics with the help of skylines, we want to keep at least the x-height strip free of intruding graphical material.

So we need a useful model for combining skylines and box dimensions in stencils. We don't have that, which is non-nice. We use skylines for spacing systems on the page, but not for making page break decisions. Which is absurd, and partly a consequence of the ephemerality of skylines.

So we don't have a model for how skylines are supposed to work with stencils, and as one consequence even our page-making code does not use them consistently. So we need to find a useful model, integrate it with the stencils, and then refactor our existing code to use that model.

And we don't want a duplication of coding where the user-accessible primitives are modeled to be almost, but not quite, entirely unlike what we use for building pages. Rather we want everything to be using the primitives written for implementing the model.

If you take a look at issue 3330, this involved a consolidation of primitives and letting everything use those primitives in order to achieve an effect. It turned out that the sanest way to do this was to split this into two separate primitives, one for "stacking" stencils, one for "adding at edge", because those were sufficiently different to warrant different behavior. They might grow further apart in case our stencils will gain metrics specific for stacking (characters will usually have character extents/dimensions as well as a character width used for advancing the reference point when placing the character in a line).

But the point is: if our interfaces for working with stencils and/or the skylines within are not really what works well for implementing the currently existing uses of skylines, then we have picked bad interfaces. And if we provide them in a stable version, people will get to rely on them.

It is a defect that we can't work with skylines outside of what LilyPond does internally, but the solution is not some semi-parallel construction imitating part of the current internals at a performance cost. That's going to be a conceptual nightmare, and it will keep our current internals opaque, not explainable or codable in terms of user-accessible functions.

That's a wrong direction to take. The right way is to refactor the existing code working based on skylines in a manner that it uses the same interfaces as we want to provide to the user. Not provide semi-parallel constructions.

--
You received this message because this project is configured to send all issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings



reply via email to

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