Multiple strikes in OpenType bitmap fonts can't use different advance widths

[lampmerchant]

Hi HarfBuzz devs!

tl;dr: EBDT/EBLC tables contain advance widths per strike in pixels, but HarfBuzz ignores them and only uses advance widths from the hmtx table

What I'm trying to do is create an OpenType (.otb) version of a bitmap font that contains multiple strikes. The problem I have is that even in bitmap-only OpenType fonts, HarfBuzz appears to take advance widths from the hmtx table and ignore the ones provided in the EBDT/EBLC tables. This wouldn't be a problem in a bitmap font with only one strike, since the values from EBDT/EBLC could just be mirrored in hmtx (after being converted from pixels to font units), however, in fonts with multiple strikes, if the advance widths aren't proportional to the pixels per em, the font writer appears to be out of luck...

I'm attaching a font with such a problem: monegasque.otb.gz

It contains strikes at both 12 ppem and 16 ppem (9 and 12 point), however only the advance widths of the 12 ppem strike are correct - the advance widths of the 16 ppem strike are too wide.

The 16 ppem strike looks like this:

But it should look like this:

Am happy to provide any more information that might be needed. Thanks for looking!

[behdad]

We can implement that (and hdmx as well?) for when ppem is set.

[lampmerchant]

That'd be super cool. Thank you!

[behdad]

I don't have time immediately work on this. If anyone else wants to pick it up that would be great.

[lampmerchant]

Happy new year! Just wanted to give this a bump - please let me know if there's anything else I can provide by way of debugging info to facilitate this.

[behdad]

I'll take a look soon.

[behdad]

One issue I can think of is that the hdmx numbers are designed for the font when hinting is enabled. That's problematic for renderers that don't do hinting. I suppose those then should not set ppem. But how to know to set ppem for bitmap fonts and not other fonts is not clear.

[lampmerchant]

Hi @behdad - just wanted to shake the tree on this a little. I'm not sure how to answer the question about the hdmx numbers, only to say that my converter does not create an hdmx table (maybe it should?) In any case, please let me know if I can provide any more information about the non-working font.

I know this probably isn't high on the priority list and I appreciate you taking a look. =) Thanks!

[behdad]

I haven't forgotten this. Can you produce a font with hdmx? I'll then try to implement it. Thanks.

[jafd]

Ah, so it may also be the cause of some bitmap fonts getting s p a c e d r e a l l y w i d e, especially when a higher-dpi application is trying to render them — font units are not necessarily the same as physical pixels. (I tried this with a single-strike font generated with the default FontForge settings; I'm not sure which tables are present there, will look when I have some time to play with it again.)