[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-XBoard] [bug #33241] xboard quits with "Unable to create font s

From: h.g. muller
Subject: Re: [Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."
Date: Tue, 17 May 2011 11:54:16 +0200

At 01:13 17-5-2011 -0700, Tim Mann wrote:
p.s. I just tried, and editing the .xboardrc file to change the fonts from iso8846 to iso10646 did NOT fix the broken umlauts. So there is more to that problem.

I don't really know anything about X-fonts, but apparently iso10646 and such stands for an encodings, and neither encoding is apparently UTF-8.

To get it working, two conditions must be satisfied:
*) The font must define the relevant glyphs
*) The strings must be presented to the renderng agent in the encoding the latter expects (presumably defined by the selected font).

I get the impression that the fonts defining the relevant glyphs for some languages are only available in encodings different from UTF-8. This does not need to be fatal; it merely means that the po files should be adapted to use the encodings available in one of the fonts available for the target language, and that the user should be advised to specify that font with XBoard.

It should be easy enough to obtain a po file in another encoding. There are several inconveniences though: different strings in the po files will use different fonts, and thus might need different encodings. Window titles, for instance, are rendered by the window manager, which apparently is using UTF-8 (considering the screenshots of the Russian translation on WinBoard forum, http://www.open-aurec.com/wbforum/viewtopic.php?f=19&t=51772 ). So we would have to figure out which messages are window titles, and put those in different encodings in the po file. The same potentially holds for strings rendered in the clock and coords font, but there are only a handful of those.

It would be much nicer if we could select a font based on the availability of glyphs, let XBoard note what encoding it is in, and then let it apply a recoding to it before the font is rendered. I.e. redefine the _(s) macro not as gettext(s), but as recode(fromEncoding, toEncoding, gettext(s)) . Where the fromEncoding would always be UTF-8, so the po files could be maintained in UTF-8.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]