Re: [Lilypond-auto] Issue 3330 in lilypond: bracketify-stencil moves grob's refpoint

[lilypond]

Comment #31 on issue 3330 by address@hidden: bracketify-stencil moves grob's  
refpoint
http://code.google.com/p/lilypond/issues/detail?id=3330

Ok, here is some bit of rambling: basically, it makes things nicer if  
add-do-stencil and derived functions are _associative_, meaning that
\line { \line { x y } \line { z } }
is the same (regarding visual appearance and metrics) as
\line { \line { x } \line { y z } }
since otherwise things are getting really hard to explain.

Now how does typesetting a line usually work?  Quite banally: every  
character has in its metrics an "escape width".  The character is placed at  
its reference point, and then the reference point is moved forward by the  
escape width.

With that algorithm, we won't solve issue 732 and issue 3330 at the same  
time.  So we need a left _and_ a right escape width (and a top and a bottom  
one).

Ultimately, it would be a good idea if one can optionally specify those  
when creating a stencil.  For one thing, it would give us characters that  
behave properly like when typeset as a Pango string.  But if we assume  
those as an abstraction, we just need to figure out what formula we want to  
use for calculating them given the normal object dimensions, and we can  
figure out behavior from there.

Why go through this kind of complication/abstraction?  Because I figured  
out that it is _really_ hard to create consistent and useful behavior just  
by cobbling together code until it works.  Or not.  If we first have a  
model how it is supposed to work based on some useful principles, we can  
check problem reports along two lines:

a) is the behavior violating its model? -> bug
b) is the desired behavior not representable with the model? -> tough luck.
Or the model is insufficient and needs to get amended.

But in either case, we get away from the "poke things with a stick and  
declare some state ""correct"" until we find another exception that would  
be fun" approach, an approach which does not help writing reliable  
documents as they depend on the behavior of the day.

In other words: I am moving into planning mode right now.  I have the  
feeling that something like \translate will actually be rather hard to give  
nice behavior without having separate extents and escape width and am  
leaning towards letting it completely retain metrics (meaning that the  
metrics are completely unusable for figuring out bounding boxes then).  Ot  
let it extend metrics in the direction of translation.

Anyway, back in a bit of time.

--
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