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).
Comments
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.
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.
I will also open your font in FontCreator which allows me to easily spot and fix errors.
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.
Wordpad on Windows 7 works just fine. Same goes for Word on Windows 10, Firefox, etc.
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.
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.
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.
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.
(Sorry for off-topic).
In any case, I'll bow out of this thread before even I feel I am tilting at windmills...
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.
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 â.