[Top][All Lists]

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

Re: Guidelines for bounding boxes?

From: Werner LEMBERG
Subject: Re: Guidelines for bounding boxes?
Date: Mon, 10 Aug 2009 07:02:39 +0200 (CEST)

> Are there any guidelines LilyPond adheres to for creating bounding
> boxes?


> For example, when I adjusted the bbox for the \eyeglasses markup
> command, I _underestimated_ the bbox.  Should I have slightly
> _overestimated_ instead?  Attached is a PNG displaying the bbox.

I think overestimation is better.

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

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.

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

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.


reply via email to

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