Re: Guidelines for bounding boxes?

[Patrick McCarty]

On Mon, Aug 10, 2009 at 07:02:39AM +0200, Werner LEMBERG wrote:
> 
> > Also, in the case of Metafont glyphs, there doesn't appear to be a
> > clear convention: some bounding boxes are underestimated, but others
> > are overestimated.
> 
> What you call `bounding boxes' aren't real bboxes but the metrics
> boxes of the glyphs.  In case of the bass clef, for example, the top
> shape is treated as with many other rounded glyphs in normal fonts:
> The `overshoot' sticks out.  On the other hand, the height has been
> enlarged so that it covers the staff vertically.
> 
> Similar considerations hold for other glyphs.  However, I don't object
> to revising the metrics since the dimensions of the glyphs stem from
> the time where the TeX engine has been used for layout.  Most
> restrictions are probably no longer of importance.

Okay, I see the difference now.  Thanks for your explanation.

So, if I am understanding correctly, LilyPond currently uses the same
dimensions for both the "metrics" box and the "bounding" box for each
glyph.  This is why the longa glyph, for example, is cropped in the
EPS/PNG output.  Is this true?

> One issue remains: Should the metrics and the bbox differ at all?  My
> opinion is yes, but this is something Joe can probably answer best.

It sounds like they should differ, depending on the case, since the
boxes deal with two different concepts.

> > I've attached examples of various cases.  The "longa" example uses
> > the glyph "noteheads.sM2neomensural".
> 
> Perhaps we have to add new fields to the lilypond tables embedded into
> the OpenType fonts which gives real bounding boxes.  Alternatively, we
> can use FontForge to compute them automatically.

I think it would be a good idea to compute them with FontForge.

> Another improvement would be to provide `shaped metrics': Currently,
> the metrics for a glyph consist of a single rectangle.  This could be
> extended to a list of rectangles which are then merged.  For the longa
> glyph, this could be these two boxes:
> 
> 
>      +-----+          ++         ++----+
>      |     |          ||         ||    |
>      +-----+     +    ||    =    ++----+
>                       ||         ||
>                       ||         ||
>                       ||         ||
>                       ||         ||
>                       ||         ||
>                       ++         ++
> 
> 
> Doing so would allow much enhanced precision in collision handling.

This is quite interesting.

But would this help with collision handling?  I was under the
impression that the Stencil extents (which form a box) are used for
collision handling (skylines, etc.).

Or is the glyph metrics information used instead of the Stencil
extents?


Thanks,
Patrick