macOS ATSUI font services not recognizing Source Code Variable

[siegel]

Customer reports that after installing Source Code Variable and selecting it as the default font in BBEdit's "Editor Defaults" preferences, the font is not rendered in text editing views.

This is likely because the font is missing data that ATSUI (the macOS font rendering stack that BBEdit uses) requires; but I cannot speculate as to what that might be.

You can download BBEdit here.

This is observed using the TTF deliverables; when using the OTF deliverables, the macOS Font Book application reports critical validation issues as shown in the attached.

[erniemarch2]

FontBook has intermittent issues with CFF and CFF2 fonts when added using FontBook. If you copy the CFF2 (OTF) Variable font(s) directly into the /Library/Fonts folder, they will show up in FontBook and will pass validation. The BBEdit issue is likely separate. I installed the fonts on the latest Mac OS and they indeed do not work in BBEdit, but they work fine in TextEdit, which suggests that perhaps BBEdit has not implemented support, although I cannot say for certain.

[siegel]

There's no "support" for BBEdit to implement :-), the issue is that the macOS font rendering stack that BBEdit uses isn't handling the font correctly. (It's an older API.) So there's no quick fix in BBEdit for the OS's inability to supply the font when requested by the application.

However, since Source Code Pro does work, presumably the variance in behavior is explainable in terms of the structure of Source Code Variable, and that's something that perhaps the font's developers can address.

[punchcutter]

I don't see any variable fonts working in BBEdit, even Apple's variable version of SF Mono. They are applied to the Line Numbers, but not to the main editor text. CoreText handles variable fonts fine. Wasn't ATSUI deprecated years before variable fonts even existed? I can't see how it could possibly support them.

[punchcutter]

I mean variable fonts are supposed to work in older APIs as if they were just a single static font, but in this case they are being read correctly as variable and the instances can be applied to the line numbers so I'm not sure what else could be done on the font side to make BBEdit use the instances in the editor view.

[siegel]

@punchcutter right, the issue isn't is that ATSUI needs to support variable fonts, nobody could reasonably expect that. However, Source Code Variable should still be displayable as a static font. The issue is that it is not, and that's related to the font itself and thus outside of BBEdit's control.

[punchcutter]

I don't see how this has anything to do with Source Code Pro. Every variable font shows up the same in BBEdit and they all show up as variable fonts. And they all get applied to the line numbers which means that something in BBEdit is reading them as variable fonts and applying that part correctly. If BBEdit can't apply the font to the editor text then it's a problem with BBEdit, not the fonts.

[siegel]

The line numbers are drawn using Core Text, but that's not an option for the editing view. (There's a long distance between simply drawing short line numbers and a full text editing engine, and Core Text does not actually support the necessary low-level layout control. That is not really relevant here.)

So then the problem is that ATSUI isn't correctly rendering variable fonts that you tested, even though it seems like it should render such fonts correctly. As you said:

I mean variable fonts are supposed to work in older APIs as if they were just a single static font

If every variable font in existence fails to render correctly using ATSUI, then the issue is moot. However, if there exists any variable font that renders correctly in BBEdit's editing area, then the hypothetical font that renders correctly must be formed correctly in a way that Source Code Variable is not. Given that, addressing that issue in Source Code Variable should resolve the symptom.

[punchcutter]

My guess is that every variable font in existence will fail to render correctly here. Most variable fonts out there right now are built the same way so contain the same basic data.

Anyway, I tried some tests... Loading any variable font in Windows 7 (which has zero variable font support) works just fine. The default instance is read and can be used. This is exactly what should be happening.

Removing all named instances in the variable font except for the default instance makes it work in BBEdit, but defeats the whole purpose of having a variable font with named instances. Also, even if the default instance could be loaded in BBEdit for Source Code Pro that's ExtraLight which really does not look good as the single code font. So removing all named instances except one makes it work, but that's not a solution at all. The only real solution I see here is to use the static fonts.

I use BBEdit myself every day and I personally can't see a reason to need a variable font here, but if there's some way to do it that I'm missing then I'm all for figuring it out.