Re: towards a 'normal' Emmentaler font
>> I think (2) might be the route to go. Comments? > > semi-related: what about the Y dimension (depth?). For accidentals, > the glyph is centered on the center of the notehead, but for > integrating with text, it should typically be centered on 0.5ex ? Something like this, yes. I will soon send a better proposal to the list. Werner
Re: towards a 'normal' Emmentaler font
> 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. Meanwhile I came to the conclusion that this doesn't matter because... > 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'. ... after re-reading the SMuFL standard I found out that this isn't true for Bravura either. > 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). Again, I convinced myself that this isn't necessary since... > 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. ... there is a much cleaner solution: Provide a completely different set of metrics to create a text version of the Emmentaler fonts: 'Emmentaler Text', similar to 'Bravura Text'. > [Note that the DVI proof sheet output would stay as-is; the horizontal > shift happens at glyph shipout time, which comes later.] I now envision an additional macro `set_textchar_box`, to be inserted right after `set_char_box`. ``` set_textchar_box (, , ); ``` If the global METAFONT parameter `text_metrics` is set to value 1, it would do the following. (1) Shift the glyph and its bounding box horizontally to the right by the value of the 'breapth' parameter given in `set_char_box`. (2) Apply and , where shifts the glyph further to the right (so that the left side of the bounding box is positioned at x=0), and further extends the right side of the bounding box. (3) Scale the glyph by to make it look good if typeset as text. (4) In DVI proof mode, draw the new bounding box in stead of the old one. Note that the goal is *not* to emulate what 'Bravura Text' is doing – for example, it contains a poor-man's method to typeset small music snippets with textglyphs (see https://github.com/steinbergmedia/bravura/blob/master/redist/bravura-text.md for more details); this is something that `lilypond-book` can do much better. The idea is rather to make the use of `\markup` easier by entering Emmentaler glyphs without the need to apply `\hspace`, `\magnify`, and other commands excessively; it would also help packages like 'lilyglyphs' (for LaTeX) work better. On the technical level, the Emmentaler fonts would become OpenType Collections (which don't get the expected extension `.otc` but `.ttc` for various reasons), containing both 'Emmentaler' and 'Emmentaler Text' (compare this to the MS font `cambria.ttc`). The glyphs with new metrics would be composite glyphs that simply reference the glyphs with the default metrics; this means that the size increase of the font would be just a few kByte. We would further need to implement WOFF2 support since neither WOFF nor SVG support OpenType Collections. Werner
Re: towards a 'normal' Emmentaler font
>> (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. > > I'm totally unaware of any details here, but why would LilyPond need > to fake the "old" non-standard glyph properties. Put differently, > what is the point (0,0) used for? For the METAFONT design, (0,0) is the intersection of the horizontal and vertical symmetry axes in most (if not all) glyphs. This helps a lot while designing a glyph. For non-symmetrical glyphs, (0,0) is the position where you should put the glyph by default, then applying some vertical offset to avoid collision with the parent grob. With the current design, you simply position, say, a fermata glyph at a given point, and it gets rendered symmetrically. This is very convenient and probably makes the LilyPond code easier to understand. I will soon send another e-mail to the list with a much better idea to proceed. Werner
Re: towards a 'normal' Emmentaler font
On Mon, Nov 22, 2021 at 10:26 AM Werner LEMBERG wrote: ... > > I think (2) might be the route to go. Comments? semi-related: what about the Y dimension (depth?). For accidentals, the glyph is centered on the center of the notehead, but for integrating with text, it should typically be centered on 0.5ex ? My suggestion: make the font bboxes/advance widths work well to integrate with text, and use an auxiliary table (ie. a lisp) to specify the center of the glyph for musical purposes. I think that is your option (3). Finally, for integrating with text, should we have a different sizing scheme? (could we make it so emmentaler 20pt matches with Times New Roman 20pt?) -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: towards a 'normal' Emmentaler font
Am Montag, dem 22.11.2021 um 09:25 + schrieb Werner LEMBERG: > (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. I'm totally unaware of any details here, but why would LilyPond need to fake the "old" non-standard glyph properties. Put differently, what is the point (0,0) used for? Jonas signature.asc Description: This is a digitally signed message part
towards a 'normal' Emmentaler font
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.00)) (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.00)) (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
