towards a 'normal' Emmentaler font

[Werner LEMBERG]

While playing around with accidentals, I compared Bravura's glyph
metrics with the ones from Emmentaler.  In short: Bravura looks like a
'normal' font, while Emmentaler is non-standard.

With 'normal' I mean that if you mix Bravura glyphs with other text,
they behave as expected, that is, the current position on the line
gets increased similarly to other glyphs like 'a' or 'x'.  This is not
true for Emmentaler glyphs: due to the concept of an extended bounding
box, the advance width only contains the width, not the breapth of the
bbox.  Some glyphs, for example all braces, have a zero width, making
them behave like accents – this is certainly not desirable.

A drawing from `feta-autometric.mf` illustrates Emmentaler's extended
bounding boxes as present in its METAFONT code.

```
  breapth (bp), width (wd), depth (dp), height (ht)

               ^ y
               |
               |
  --      +----+------------+
          |    |            |
          |    |            |
          |    |            |
  ht      |    |            |
          |    |            |
          |    |            |
          |    |(0|0)       |
  --   ---+----o------------+---> x
          |    |            |
  dp      |    |            |
          |    |            |
  --      +----+------------+
               |
               |

          | bp |     wd     |

  `breapth` is positive leftwards; `depth` is positive downwards.
```

I want to improve the situation eventually; I think the goal should be
to make Emmentaler glyphs have similar bounding boxes as Bravura (and
probably all other music notation fonts not designed for LilyPond).

The solution on the font side is very simple: Move all glyphs to the
right so that 'bp' becomes zero.  This automatically gives all glyphs
the correct advance width.  The necessary changes on the METAFONT side
are just a few lines of code.

[Note that the DVI proof sheet output would stay as-is; the horizontal
 shift happens at glyph shipout time, which comes later.]

There are now various approaches how to include such a change into
LilyPond.

(1) Use correct advance widths but don't change the values in the font
    Lisp tables.  In my first preliminary tests this works
    surprisingly well – apparently, most code of LilyPond only uses
    the full width of glyphs, which is the same for both the old and
    new approach.  System braces are a notable example of stuff that
    doesn't work out of the box.

    However, there are functions like
    `Open_type_font::get_indexed_char_dimensions` that would then
    return a Lisp table bounding box (as specified in the drawing
    above) for Emmentaler glyphs but 'normal' bounding boxes for all
    other fonts.  My gut feeling says this isn't a good solution.

(2) The same as (1), but make LilyPond undo the font changes
    internally, that is, it horizontally translates a glyph's outline
    back to the position specified by the Lisp tables (if the glyph is
    in the tables).  This ensures both consistency and backwards
    compatibility with both LilyPond user code and fonts.

(3) Change both the Lisp table and advance widths.  I haven't tested
    this yet since it needs some more code changes; for example, it
    would be necessary to introduce a new parameter 'origin-hoffset'
    to specify what is currently the `bp` value.  As an example, this
    entry (from the build file `mf/out/feta16.lisp`)

    ```
      (accidentals.flat .
        ((bbox . (-0.557540 -2.587750 3.174010 7.145160))
         (subfont . "feta16")
         (subfont-index . 66)
         (attachment . (3.174010 . 0.000000))
         (attachment-down . (-0.557540 . 4.557400))))
    ```

    would become

    ```
      (accidentals.flat .
        ((bbox . (0 -2.587750 3.731550 7.145160))
         (origin-hoffset . 0.557540)
         (subfont . "feta16")
         (subfont-index . 66)
         (attachment . (3.731550 . 0.000000))
         (attachment-down . (0 . 4.557400))))
    ```

    [An alternative would be to not modify the Lisp code but compute
    `origin-hoffset` within C++.]

I think (2) might be the route to go.  Comments?


    Werner