3

Recently, a windows user made us aware that Japanese (and other unicode) characters in our app don't display properly under Windows. He just gets boxes with numbers instead.

We're using Pango, Fontconfig/freetype and rendering with Cairo. In Unix (that is, both Linux and macOS) it works perfectly. However, under Windows we just can't seem to get it to work.

I imagine it has to do with how font fallback/linking works under Windows, but I have no idea even where to begin looking into making this work properly.

Gregorio Litenstein
  • 598
  • 2
  • 21
  • From what I have been reading, the boxes are the unicode codes for the missing glyphs. So that makes it more certain that the issue is with the fonts, then. What I don't understand, is how(or if it's possible) to get Windows to behave in the same way as Unix in this respect: i.e. Missing glyphs? use another font. I even tried manually adding MS Gothic and a couple others to the FontLink key in regedit, but nothing changed. – Gregorio Litenstein Jul 13 '17 at 12:30

2 Answers2

3

Turns out the issue is simpler than expected, but not very well documented anywhere. Fontconfig needs its config files (fonts.conf and the secondary configs found under conf.d). In linux it's never an issue because most (if not all) distros use fontconfig by default so even if one botches it, there's still a system config to fall back on.

By contrast, windows doesn't normally use fontconfig, so unless devs ship out a set of fontconfig configuration files, it will at most load the specified fonts but it won't be able to do anything else (like font fallback).

The solution to this is to ship out a "fonts" folder containing at least fonts.conf and also any appropriate definitions from conf.d, usually the folder should be in the same folder as the fontconfig library. (and if that doesn't work you can set FONTCONFIG_PATH to ".")

Finally, unless you actually made any special changes to the config, you can just copy the default config files from /etc/ to ship out with your app.

Gregorio Litenstein
  • 598
  • 2
  • 21
2

Linux systems are built around fontconfig and font substitution, so fonts available under Linux are curated to work well in that scenario.

It is very common to encounter in other systems fonts that do stupid stuff like mapping all the glyphs the font designer has not drawn yet to a placeholder symbol (typically squarish). When fontconfig encounters such a font it won't replace the missing glyphs with material from other fonts, since the font already declares something to display for those codepoints.

Another common case is non-latin fonts shipping quick and dirty latin glyphs so software that can not substitute fonts still displays errors in English. They require specific rules in fontconfig, to promote the useful part of the font, but not the fill-in one.

Community
  • 1
  • 1
nim
  • 2,345
  • 14
  • 13
  • In my particular case, I was seeing squares with the utf8 code for that particular character. In the end, what I did to fix it was to include the config files in my release and used _putenv_s() to properly set FONTCONFIG_PATH if running on windows. – Gregorio Litenstein Sep 28 '17 at 18:44