[PATCH] ledger lines

[Han-Wen Nienhuys]

address@hidden writes:
> Hi!
> 
> Attached is a revision of the patch that I sent on last December 31st,
> regarding ledger lines.  It was rejected due to blotdiameter problems.
> I tried to solve them as far as possible, revealing some oddities that
> are still in lily.  Hence, I hope this patch satisfies your quality
> constraints, even if it still contains some issues, which, however,
> reflect more general issues of lily that I can not fix in a single
> patch -- this patch is already quite big as for a few relatively
> simple goals!

looks good.

> When I sent the first revision of this patch, it was rejected since
> the resulting ledger lines had sharp edges, although the draw_box
> routine in music-drawing-routines.ps seemed to regard blotdiameter.
> In the meantime, draw_box seems to consider blotdiameter (at least
> with the environment of my machine).  Though a faced a couple of new
> problems that I would like to discuss.

I agree with you that blotting should also be a parameter of the
drawing routines; that solves some problems. At the moment,
blotdiameter has been set to 0, to prevent beams from looking silly
(the bug that Rune reported).

 
> To circumvent this situation, I would like to suggest a different
> model for "blotting" an existing shape: given an arbitrary shape, just
> move a pencircle of size blotdiameter around the outline of this shape
> to create a blotted shape.  In the case of draw_box, this leads to the
> following model:

I'm not sure what the best approach is. In some cases, you might want
to combine objects that have different blot parameters, and align
them, or align blotted objects to stafflines (which are unblotted).
Perhaps we should store both extents (including and excluding) the blot.

> In my attached patch, I have included an implementation for the above
> box model (at least for ps; I could not find out how to easily draw a
> circle in pdf; any volunteers appreciated!); see
> Lookup::roundfilledbox ().

PDF output is non-functional;  that is, I can not recall seeing it
work.  I believe it was part of the PDFTeX output module, which was
contributed by Ian Peters.

> 
> b) Once again the same shape composed from beams with blotting as
> above suggested:
> 
>        _
>       / \
>       |  \
>       |   \
>       |    \
>       |     \
>       |      \
>       |       \
>        \       \
>         |      |
>         |      |
>         |      |
>         |      |
>          \     |
>           \    |
>            \   |
>             \  |
>              \_/
> 
> In c), the two shapes overlap by an amount such that inner edges as in
> b) do not arise.


(nice ASCII art BTW) -- this probably would also fix the issues with
the rounded beams producing vees at the stmes. 

> By the way, I think, blotdiameter should be passed as parameter to
> general-purpose functions like filledbox, since different notation
> styles may prefer different values for blotdiameter.  The fact that in
> the metafont code, pencircles of different sizes are used, stresses
> this need.  With the current implementation, setting blotdiameter in
> the paper block has no effect on Lookup::filledbox; my implementation
> of Lookup::roundfilledbox however considers blotdiameter; and this
> effect can also be seen on ledger_lines if Lookup::roundfilledbox is
> used in Note-head::brew_ledger_lines.


indeed, see above.

> By another way, do I really need a Grob *me, to do a thing like
> me->paper_l ()->get_var ("...")?  I think, these variables are global,
> and hence there should be a possibilty of accessing them without
> having a Grob at hand (I really do not like to pass a Grob into a
> function of class Lookup).  Or am I missing here something?

No -- you're right. However, you could pass a Paper_def into Lookup,
no?


> Ah, and yes, it seems the blotdiameter on bezier curves and filledbox
> (when called by roundfilledbox on the ps level in ps.scm) is too big
> by an estimated factor of 2.  Maybe radius and diameter have been
> confused somewhere?  For compensation of this error, the call to

Yes, probably. I think it's time to go over everything that uses
blotting to make sure it is correct.

> porrectus.cc:
> >  /*
> >
> >  TODO:
> >
> >  ugr. why not  called direction?
> >
> >   */
> >  SCM stem_direction_scm = me->get_grob_property ("direction");
> 
> Because it's really only the direction of the stem (or rather
> "cauda"), not the direction of the whole grob.  But this code will
> have to be revised in a few weeks, anyway.

yes -- but I could not find a direction for the whole, grob, so the
stem- prefix looks superfluous.


The patch looks good. I'm putting it in.

-- 

Han-Wen Nienhuys   |   address@hidden    | http://www.cs.uu.nl/~hanwen/