Are OTF fonts from Glyphs broken on Windows?

James Puckett

I’ve run into a showstopping problem during QA of a new typeface. My OTF fonts mastered in Glyphs are broken on Windows. I’m using Wordpad on Windows 10 for my testing. When text is just English it renders correctly. But accented text turns into a mix of my font and characters randomly falling back to system fonts. The characters do exist in my fonts, but they fall back anyway. Even letters with no accents will fall back when accented letters are in the text. This problem only occurs with OTF fonts, Truetype fonts work. There’s nothing weird about this font, it’s just a typical Latin typeface with a big character set (Latin Plus, Vietnamese, and Pinyin).

I tested with 2.4.1 and 2.4.2 versions of Glyphs and it’s a problem with both, so it’s not a new bug. But it doesn’t seem to have been a problem with older versions of Glyphs. I tested a font from 2012 and that works correctly. 

A screenshot is attached. This is an example of me testing an OTF font in Wordpad, on Windows 10, using a dump of all the glyphs in the font. The same text renders properly in Adobe apps and Apple Textedit.

I would appreciate it if other people would test this out with their fonts to see if they have the same problem. If it turns out Glyphs has been generating fonts that don’t work with accents in Wordpad there might be a lot of broken fonts out there (and a lot of broken QA procedures).

Mike Wenzloff

People actually use WordPad? Sorry.

I would be happy to test. But have no idea what tool is used on what fonts. I think Mark S. uses Glyphs and I own a few of his fonts, but I suspect they are old enough (like my copy of Coquette) that it was an older version of FL anyway.

Can you point to a font and it's version number that is using the recent Glyphs revision needed? As a Mac only application, I suspect testing on Windows in non-Adobe applications is done much. That's my understanding as to why so many fonts under Windows break families anyway.

James Puckett

Mike, I was asking type designers to test their own fonts, not fonts people have bought.

And Wordpad is generally used as the benchmark for QA on Windows. If it doesn’t work in Wordpad, it’s probably not going to work in most Windows apps.

Mark Simonson

I did a quick check on this with the latest version of Proxima Nova, which I think was generated by 2.4.1, and don't see this issue. It contains Vietnamese characters and they display as expected. If it was something happening to all OTFs generated by recent versions of Glyphs, I definitely would be hearing about it, but I've had no reports of anything like this from users.

Erwin Denissen

Do send the font file to me if you want me to test the font. I'm currently running Windows 10 Pro version 1703 (a.k.a. Windows 10 Creators Update).

I will also open your font in FontCreator which allows me to easily spot and fix errors.

James Puckett

Thanks, Mark. Does Proxima Nova use the combining marks feature building in glyphs or have you stuck with the old mark names (acute vs. acutecomb, etc.)?

James Puckett

Erwin, if you email james.puckett@gmail.com I’ll send the font for you to look at.

Erwin Denissen

I'll send you an email, but you'd better remove your mail address to prevent (more) spam. Next time you can also send me a PM.

John Hudson

Have you confirmed that OS/2 things like codepage and Unicode range bits are correct in the font that is being generated? That's the most common font fallback trigger on Windows.

You say that TTF works, so I would do a table comparison between the CFF and TTF fonts generated from Glyphs for the same type. Check OS/2 table first, and also cmap table entries for accented characters.

James Puckett

Thanks, John. I’ll fire up OTM and start digging.

Mark Simonson

Combining marks: Yes, but the Vietnamese glyphs are all precomposed. Both acute and acutecomb (for example) are in the font; but acutecomb is used for precomposed glyphs. mark-to-base and mark-to-mark are supported.

Erwin Denissen

I don't see anything wrong with the font that could lead to this behaviour. It looks like Wordpad is doing some magic related to code pages or character sets, and then detects the font doesn't support it, so it then uses a fallback font (Arial).

Wordpad on Windows 7 works just fine. Same goes for Word on Windows 10, Firefox, etc.

James Puckett

Thanks, Erwin!

Mike Wenzloff

James Puckett said:

Mike, I was asking type designers to test their own fonts, not fonts people have bought.

And Wordpad is generally used as the benchmark for QA on Windows. If it doesn’t work in Wordpad, it’s probably not going to work in most Windows apps.

Twas just trying to help in lieu of others stepping forward.

As regards using WordPad as a benchmark (of any sort)? Nope. Sorry. I didn't get the memo. I will ensure what I make works in all common layout applications (4 of them), several vector editors and a few image editors. I will make sure that even Word and LibreOffice will work both as regards to characters being present and insofar as their pitiful OT feature support allow.

If and when I ever get an email stating that any font I make or have a part in doesn't work in application X, I'll deal with the issue. Even if applicaiton X = WordPad. But something that resides in a Windows start menu folder named "Windows Accessories" isn't going to be a something I ever test in.

John Hudson

Re. testing on Windows:

The perennial problem is that there are so many different layers of system, shared libraries, and apps, that it is difficult to diagnose where a problem is occurring. Testing in the major Microsoft productivity apps makes a lot of sense in terms of user support, i.e. in Word and other Office apps. But if one runs into a problem there, then there are too many levels at which the cause might be, so then it makes sense to fall back to simpler test environments such as WordPad and even Notepad.

Peter Constable

Mike Wenzloff said:

People actually use WordPad? Sorry.

I'm not sure how many people use WordPad, but regardless it might still be useful for testing since WordPad is a wrapper around the RichEdit control, which is quite widely used in Windows and Office, including Office on other OS platforms.

I should make a qualification: I don't know enough details to know if code paths used in WordPad are distinct. RichEdit was originally built using GDI, but later revised to enable use of other text code that Office uses across platforms. I'm not sure to what extent WordPad is using GDI-only code paths.

Mike Wenzloff

That was written slightly tongue in cheek. As was the word, slightly. 

It is true I don't see the point. And it is true that I in no way see WordPad as a standard to check fonts with. 

I will, and do, use Word when testing. Even so, it isn't the 1st through 15th application I will test in. I see that as no different than never only checking in Adobe applications, for obvious reasons. 

Adam Jagosz

Wow, now that's a beginning of an interesting debate. Imho Notepad is more worthy as a testing environment than WordPad for this simple reason:

(Sorry for off-topic).

Adam Twardoch

Notepad applies kerning and WordPad doesn't but this doesn't make WordPad a lesser testing environment, because people should test the fonts they make in apps their users will use, including not-so-sophisticated apps. Unless of course they only make fonts for very specific environments! 

Mike Wenzloff

I don't think not testing in WordPad is as much a fault as only testing in Adobe applications and I know several designers that if they test in anything else consider their fonts "proper" if they work in them and not so well in non-Adobe applications. I know, I get paid to fix enough of them. 

In any case, I'll bow out of this thread before even I feel I am tilting at windmills...

John Hudson

NotePad is especially useful for testing raw OpenType lookup behaviour as processed by Uniscribe. There's minimal intervening levels in Notepad, so it is better suited for this process than Word or Wordpad.

But as Peter noted, Wordpad is a fairly simple wrapper round the RichEdit library, so is ideal for testing and diagnosing the kind of problem that Hames is experiencing, because RichEdit includes a font fallback algorithm.

James Puckett

I dumped the CMAP tables to compare in FileMerge. The only difference is the sfnt version.

John Hudson

Any differences in the OS/2 table codepage or Unicode range bits?

James Puckett

Codepage and unicode range match.

Khaled Hosny

What happens if you dump the font with ttx and compile it back? Sometimes this would silently fix otherwise broken fonts for me (might not be a solution, but if it works would explain why ttx dump shows no difference).

James Puckett

Compiling with TTX doesn’t fix it. Thanks for the suggestion.

James Puckett

I did try copy/pasting the DSIG table from the TTF to OTF file. No luck.

Mark Simonson

Have you tried asking on the Glyphs forum? I don't seem to see any threads there about it.

James Puckett

I haven’t tried the Glyphs forum yet. I’ll open a thread there.

I’ve been testing the font with the Windows Vietnamese keyboard layout. This is wacky. I can input â but ẩ (adding a hook) will fall back to a system font. What’s weirder is that if â but ẩ are adjacent the first â will also fall back when the hook is added to the second â.

Khaled Hosny

I had a similar fallback issue with Windows once where certain letter combinations would cause the whole text to use fallback font. After lots of debugging turned out that combination triggers a specific lookup that seemed to cause Uniscribe to fail and this seems to cause the font to be rejected and a fallback is used. Not sure if this is the case here.

Erwin Denissen

I think it is a generic issue with CFF based fonts. I took a regular Windows font which works perfect in Wordpad, exported it as CFF based and then it failed.