Re: [Lilypond-auto] Issue 3524 in lilypond: Patch: Allows inner-markup spacing using skylines.

[lilypond]

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