[Bug] Some Fonts don’t work properly in JUCE8 (bitmap)

I have noticed three Fonts installed on my Mac, that work fine in the “Fonts Demo” for JUCE 7.0.12, but fail in the DemoRunner for JUCE 8.

In JUCE 7, they display their names properly in the list, and in the PreviewBox:

In JUCE 8, the names are blank and the PreviewBox is either blank or corrupted:

Also: I would also point out that the alphabetization of the lists is different between JUCE 7 and JUCE 8; it’s almost like JUCE 8 is using some internal font name to decide the order, and not the displayed font name. JUCE 7 list seems alphabetized properly. For example, the “JFRingMaster” name shows up in the JUCE 7 list in the right place, but shows up elsewhere in the JUCE 8 list. But this is a separate issue.

If I build and debug the JUCE 8 Fonts Demo, it is failing and hitting this assert at Line 496 of juce_SimpleShapedText.cpp:

    // It this is hit, the typeface can't display one or more characters.
    // This normally shouldn't happen if font fallback is enabled, unless the String contains
    // control characters that JUCE doesn't know how to handle appropriately.
    jassert (unknownGlyph == infos.end());

I noticed that these 3 fonts are .bmap files. Is this no longer supported?

I have attached one of the fonts in question here. It should be noted that two of them are custom fonts created specifically to display only a few characters, but I have used them for 20+ years without issues for specialized needs. But Kaffeesatz Schwartz (the one included here) is a publicly available font I’ve also had installed for 20+ years.

KaffeesatzEF-Schwarz.bmap.zip (18.3 KB)

On Sonoma 14.6.1 on an Arm Mac, I’m unable to install the demo font you provided at all. I can view it without problems in FontForge, but Font Book tells me:

KaffeesatzEF-Schwarz.bmap contains no fonts that can be installed on macOS. Check your selection and try again.

If I manually copy the file into ~/Library/Fonts, it doesn’t show up in the FontsDemo for either JUCE 7.0.12 or 8 develop.

I’d be interested to know which macOS version and processor you’re using, and whether Font Book is able to successfully validate/install the font file on your computer.

Support for bmap fonts wasn’t deliberately removed, but may no longer be supported as a side effect of other changes in JUCE 8.

JUCE’s text layout engine is based on HarfBuzz in JUCE 8, which in turn only supports OpenType fonts. I’m not an expert on font formats and compatibility, but perhaps the font file you provided isn’t a valid OpenType font, or uses non-standard tables, in which case text shaping and layout wouldn’t work as expected.

Another difference from JUCE 7 is that JUCE 8 now uses CTFontDrawGlyphs rather than CGContextShowGlyphsAtPositions to do the actual rendering of glyphs. CTFontDrawGlyphs supports rendering colour glyphs (emoji), which is not supported by CGContextShowGlyphsAtPositions. An untested theory is that the CG function supported the display of glyphs in bmap format, but the CT function does not.

I also note that the file you provided has an empty data fork, and all of the font data in the resource fork. This is different to modern fonts, which store all data in their data fork. Access to resource forks uses different APIs than access to data forks, so it wouldn’t surprise me if this caused compatibility issues in some software. Particularly, it makes it impossible to embed the font file as BinaryData in a JUCE project, because the BinaryData conversion reads only the data fork.

When I manually extract the resource fork to the data fork of a new file, and embed that instead, I see that the createSystemTypefaceFor call fails internally on CGFontCreateWithDataProvider, which suggests that the OS doesn’t know how to interpret the font data.

I’m very interested to know how this font was able to display in JUCE 7. Do the fonts work correctly in other non-JUCE applications?

I am using (for this) an Intel Mac with Big Sur. Yes, the fonts install in Fontbook and display normally.

Yes, in JUCE 7 on this same computer it works fine. And I can use the font in Photoshop, Word, etc.

Thanks for taking a look!

On an Intel Mac running the Sequoia 15.0 beta, I got the same result as the Arm 14.6.1 Mac, i.e. the font is not recognised by FontBook.

On another Intel Mac running Monterey 12.7.6, FontBook does at least regonise the font, but fails to validate it:

It looks like this font may have some problems that prevent it from being used on more modern versions of macOS.