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
