Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font set.'

[Tim Mann]

I didn't try the new dialog, so I'm not sure how much better it looks. I
agree the GhostView one is kind of sucky. It reflects ideas people had about
file browser dialogs a long time ago and looks rather strange and confusing
today.

However, I did get the GhostView one working again, with full
internationalization. So we could keep it, unless you really want to put
more work into the new one to fix up all the cosmetic problems, etc.
Presumably the future will be the GTK file chooser dialog, though, so there
doesn't seem much benefit in working on a new one in Xaw.

On Fri, Jun 10, 2011 at 12:13 AM, h.g. muller  wrote:

> OK, the new browser dialog seems to work now. I added path browsing to it.
> The reason it crashed before was that I had broken the comment popup,
> which I moved to another dialog number to 'make space' for a second
> transient dialog (so that 0 and 1 could be transient), which was needed
> because the browser has to be up at the same time as other transient
> dialogs calling it through their 'browse' buttons. So the browser worked
> fine, but as soon as I had loaded games, and they had comments in them,
> the -autoDisplayComment caused XBoard to crash at te first commented
> move. I guess such is the risk of the bad practice of using hard-coded
> numbers rather than macos/enums. (But it was not designed for ever
> changing it...)
>
> Anyway, it works now, both for filling filename and path fields in the
> other dialogs, and directly from the File menu for Load Game/Position etc.
> There are some minor cosmetic problems:
> *) It does not sort the files in the dir listing
> *) clicking a file or folder in the listing to select it / move there,
> sometimes causes spurious selection of a group of characters there.
> *) For reasons I don't understand the window manager wants to
> give focus back to the main XBoard window after you close the
> browse dialog, rather than the dialog that called it, even though I
> do give focus to a field in the latter on closing the browser window.
> (And that field does get the cursor, so I assume it worked.)
> *) What I also don't understand is that when I use the browser a second
> time, it pops up _behind_ the dialog where I operated the 'browse' button
> from to summon it. Again, popping it up involves focus to a text widget
> in the browser dialog.
> *) I actually had to change focus to another widget than that was initially
> put in focus during popup, (namely the extension-filter field, being the
> lower-most text widget), or the event handler I added to that widget
> (for reacting to  and ) was not initially operational.
> Fishy...
> *) I did not add yet the responses to  and  (for OK and
> cancel)
> in the filename field that I had added to the old browser. In fact I want
> to
> check if I cannot make that a general feature of all single-line text
> widgets
> in the dialogs. And then perhaps also add  to move focus the next
> text widget in the dialog.
> *) I also did not implement double-clicking a file in the listing as an OK
> equivalent, or use of the mousewheel to scroll the listing. I felt less
> need
> for that here, as the OK button is not in such an awkward place as it was
> in the GhostView dialog, and the scroll bars seem to work much less
> erratic too (perhaps because the Xaw implementation of them is better).
>
> Please tell me what you think! Is this an improvement over the GhostView
> browser, or do we better stick with the latter?
>
>
> ___
> Bug-XBoard mailing list
> Bug-XBoard@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-xboard
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font set.'

[h.g. muller]

OK, the new browser dialog seems to work now. I added path browsing to it.
The reason it crashed before was that I had broken the comment popup,
which I moved to another dialog number to 'make space' for a second
transient dialog (so that 0 and 1 could be transient), which was needed
because the browser has to be up at the same time as other transient
dialogs calling it through their 'browse' buttons. So the browser worked
fine, but as soon as I had loaded games, and they had comments in them,
the -autoDisplayComment caused XBoard to crash at te first commented
move. I guess such is the risk of the bad practice of using hard-coded
numbers rather than macos/enums. (But it was not designed for ever
changing it...)

Anyway, it works now, both for filling filename and path fields in the
other dialogs, and directly from the File menu for Load Game/Position etc.
There are some minor cosmetic problems:
*) It does not sort the files in the dir listing
*) clicking a file or folder in the listing to select it / move there,
sometimes causes spurious selection of a group of characters there.
*) For reasons I don't understand the window manager wants to
give focus back to the main XBoard window after you close the
browse dialog, rather than the dialog that called it, even though I
do give focus to a field in the latter on closing the browser window.
(And that field does get the cursor, so I assume it worked.)
*) What I also don't understand is that when I use the browser a second
time, it pops up _behind_ the dialog where I operated the 'browse' button
from to summon it. Again, popping it up involves focus to a text widget
in the browser dialog.
*) I actually had to change focus to another widget than that was initially
put in focus during popup, (namely the extension-filter field, being the
lower-most text widget), or the event handler I added to that widget
(for reacting to  and ) was not initially operational. Fishy...
*) I did not add yet the responses to  and  (for OK and cancel)
in the filename field that I had added to the old browser. In fact I want to
check if I cannot make that a general feature of all single-line text widgets
in the dialogs. And then perhaps also add  to move focus the next
text widget in the dialog.
*) I also did not implement double-clicking a file in the listing as an OK
equivalent, or use of the mousewheel to scroll the listing. I felt less need
for that here, as the OK button is not in such an awkward place as it was
in the GhostView dialog, and the scroll bars seem to work much less
erratic too (perhaps because the Xaw implementation of them is better).

Please tell me what you think! Is this an improvement over the GhostView
browser, or do we better stick with the latter?

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font set.'

[Tim Mann]

On Thu, Jun 9, 2011 at 4:51 PM, Tim Mann  wrote:

> On Thu, Jun 9, 2011 at 4:04 AM, h.g. muller  wrote:
>
>> It is very inconvenient that the browser now doesn't work at all, though.
>> Perhaps we can overrule the resource-database setting for this single
>> useStringInPlace widget, and set international = False there, for the time
>> being.
>>
>
> Agreed, it's not acceptable for the browser to be completely broken. The
> approach you mention should work. I didn't get it to work last night, but I
> think I know what I was doing wrong. I'll try again probably tonight (in my
> time zone).
>

I couldn't get the approach of setting international = False only in the
browser widget tree to work. I kept getting segfaults deep inside Xlib. I
think Xlib gets confused by the mixture of internationalized and
non-internationalized widgets and ends up smashing memory somewhere by
confusing a char* with a w_char*. But I didn't really dig into it.

Instead I went ahead and internationalized the file browser. It seems to
work fine now, though I only tested it on a filename with German characters
in it. The diffs were surprisingly small.

I've pushed the change into savannah.

  --Tim
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font set.'

[Tim Mann]

On Thu, Jun 9, 2011 at 4:04 AM, h.g. muller  wrote:

> It is very inconvenient that the browser now doesn't work at all, though.
> Perhaps we can overrule the resource-database setting for this single
> useStringInPlace widget, and set international = False there, for the time
> being.
>

Agreed, it's not acceptable for the browser to be completely broken. The
approach you mention should work. I didn't get it to work last night, but I
think I know what I was doing wrong. I'll try again probably tonight (in my
time zone).
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font set.'

[h.g. muller]

I did take a stab at rewriting the filebrowser. The first attempt
is in a new branch ('browser') of the hgm.nubati.net repository.
It is mainly to get an impression of how it would come to look,
although it sort of works. It behaves a bit weird w.r.t. giving
focus to the windows, and I did not implement sorting of the
files (except that directories go first). Browsing for a path name
still does not work. I can use it for loading files and got a good
game list, but crashed after one move when I selected a game.
(Not sure if this is because of a defect in the file.)

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font set.'

[h.g. muller]

At 00:09 9-6-2011 -0700, Tim Mann wrote:
* The file browser uses a somewhat kludgey feature (useStringInPlace) that 
doesn't work the way it's expecting if its widgets inherit international = 
True from the resource database. In the international case, the AsciiText 
widget keeps its internal string representation in UCS-4 (32-bit wide 
character) format. Normally that doesn't matter, but if you say 
useStringInPlace, the in-place string you are looking at is also in 32-bit 
wide character format. The existing code is expecting null-terminated 
strings of 8-bit bytes.


It should be possible to fix the above temporarily by turning off 
international for just the affected widget(s) in the file browser, but I 
don't have that working yet for some reason.


This isn't a good permanent solution because it means the file browser 
(still) won't be able to handle filenames with characters above 0x7f. 
Well, or maybe it can handle ISO8859-1 characters up to 0xff -- I'm not 
sure -- but definitely not general Unicode utf8 filenames.


* The fixed-width font in the directory lists happens because draw.c looks 
for the "font" resource and falls back to 9x15 is there is none. Since we 
are only setting fontSet now and not font, it uses the fallback now. We 
could probably improve this by taking the first font out of the 
messageFont fontset and setting it as "font", similarly to what I did with 
coordFont. That still leaves the code not handling international 
characters in directory names.


The lists look like more work to internationalize properly because of the 
explicit character drawing in draw.c -- they don't use Xaw text widgets 
for some reason. Maybe doing it this way is more efficient and that 
mattered on the slow computers years ago when this code was written.


  --Tim


OK, so the file browser sucks in multiple ways, and we should probably not 
waste too much time on it. It is not really part of XBoard, and I did not 
like the user interface of it very much anyway. GTK will come with its own 
file browser, I suppose.


It is very inconvenient that the browser now doesn't work at all, though. 
Perhaps we can overrule the resource-database setting for this single 
useStringInPlace widget, and set international = False there, for the time 
being. I don't mind the fixed-width fonts so much, that is still workable, 
so we can ignore the font problem.


The way the XBoard front-end has evolved by now, it shouldn't be very 
difficult to provide our own browser dialog from scratch, using the 
GenericPopup routine. I could define a dialog with two single-line text 
widgets for the file name and the extension filter, a large multi-line text 
widget for the (filtered) directory contents, and the standard OK & cancel 
buttons. The only thing that would really have to be programmed is a 
callback for clicking in the contents widget, which should either transfer 
the clicked name to the filename widget (if it is a file), or change to the 
clicked directory (possibly "..") and refresh the list. 
Internationalization should then automatically work, like in all other 
dialogs. I will have a look into it next week.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font set.'

[Tim Mann]

Thanks. Obviously I didn't test enough parts of xboard. The file browser
must be doing some things that are a little different from the older code.
I'll take a look when I get a chance.

I didn't do anything that was supposed to change the background anywhere.

On Wed, Jun 8, 2011 at 11:55 AM, h.g. muller  wrote:

> OK, I am back from Greece, so I had access to my Linux system again.
> I started pushing all the WinBoard fixes I had accumulated in the mean time
> to hgm.nubati.net (hgmaster branch), after syncing with Savannah.
>
> There seems to e a problem, though, with the file browser. I suspect this
> is a side effect of some of the general changes of the text widget settings
> done for the internationalization, as the git log shows now changes in the
> browser file, and the probem is definitely new:
>
> If I use the browser through a browse button in another popup, (e.g. the
> for setting the tournament file in the Match Options dialog), it seems to
> only
> copy the first character of the selected file name to the file-name field.
> I put some debug prints in the browser, and it seems the problem occurs
> in SFsetText() in path.c, in this piece of code:
>
> text.firstPos = 0;
> text.length = strlen(path);
> text.ptr = path;
> text.format = FMT8BIT;
>
> XawTextReplace(selFileField, 0, strlen(SFtextBuffer), &text);
> XawTextSetInsertionPoint(selFileField, strlen(SFtextBuffer));
>
> This code is called when one clicks a filename in the lists in the browser
> window,
> the clicked text being passed to it as 'path'. selFileField is the
> uppermost text widget
> in the browser window, and the purpose is to load it with the clicked text.
> Now what happens is that 'path' is OK: when I print it, it prints the
> complete clicked text,
> and acknowledges the correct length of it in text.length. However, when I
> print the
> contents of SFtextBuffer after the XawTextReplace, it only prints the first
> character.
> Now SFtextBuffer is the 'use-in-place' string that is supposed to be in
> selFileField.
> On the display I see that the selFileField widget contains the complete
> filename,
> but it seems to be stored in the provided buffer array in a format that the
> rest of the
> code no longer understands. The InsertionPoint is set after the first
> character, which is
> aready suspicious. It seems like the buffer does not store the text in an
> 8-bit encoding,
> leading to null bytes in between the characters, which the rest of the code
> interprets as
> end-of-string.
>
> Other minor weirdnesses I observed are:
> *) The browser seems to use a fixed-width font in its lists (but not in the
> text widgets).
> *) The background of the font in all text widgets of al dialogs is now
> light gray. (I don't know
> if this was intentional or even if it is desirable; I just noticed that it
> was different than before.)
>
> ___
> Bug-XBoard mailing list
> Bug-XBoard@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-xboard
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font set.'

[h.g. muller]

OK, I am back from Greece, so I had access to my Linux system again.
I started pushing all the WinBoard fixes I had accumulated in the mean time
to hgm.nubati.net (hgmaster branch), after syncing with Savannah.

There seems to e a problem, though, with the file browser. I suspect this
is a side effect of some of the general changes of the text widget settings
done for the internationalization, as the git log shows now changes in the
browser file, and the probem is definitely new:

If I use the browser through a browse button in another popup, (e.g. the
for setting the tournament file in the Match Options dialog), it seems to only
copy the first character of the selected file name to the file-name field.
I put some debug prints in the browser, and it seems the problem occurs
in SFsetText() in path.c, in this piece of code:

text.firstPos = 0;
text.length = strlen(path);
text.ptr = path;
text.format = FMT8BIT;

XawTextReplace(selFileField, 0, strlen(SFtextBuffer), &text);
XawTextSetInsertionPoint(selFileField, strlen(SFtextBuffer));

This code is called when one clicks a filename in the lists in the browser 
window,
the clicked text being passed to it as 'path'. selFileField is the 
uppermost text widget

in the browser window, and the purpose is to load it with the clicked text.
Now what happens is that 'path' is OK: when I print it, it prints the 
complete clicked text,
and acknowledges the correct length of it in text.length. However, when I 
print the
contents of SFtextBuffer after the XawTextReplace, it only prints the first 
character.
Now SFtextBuffer is the 'use-in-place' string that is supposed to be in 
selFileField.
On the display I see that the selFileField widget contains the complete 
filename,
but it seems to be stored in the provided buffer array in a format that the 
rest of the
code no longer understands. The InsertionPoint is set after the first 
character, which is
aready suspicious. It seems like the buffer does not store the text in an 
8-bit encoding,
leading to null bytes in between the characters, which the rest of the code 
interprets as

end-of-string.

Other minor weirdnesses I observed are:
*) The browser seems to use a fixed-width font in its lists (but not in the 
text widgets).
*) The background of the font in all text widgets of al dialogs is now 
light gray. (I don't know
if this was intentional or even if it is desirable; I just noticed that it 
was different than before.)
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font set.'

[Tim Mann]

Good point. Maybe you could have modified the code a little to keep the
patterns around and save them  instead of the fully-specified font name, but
it's better to be more like WinBoard anyway.

With the changes I made, in the NLS case we end up saving the pattern lists
with just the desired pixel size filled in, not a fully-specified font name,
since there are multiple fonts in a FontSet (several if not all of which Xaw
may be using) and there isn't really a way to save all those names and
rebuild the FontSet from them. Normally XCreateFontSet will create the same
FontSet next time anyway.

On Tue, May 31, 2011 at 10:49 AM,  wrote:

> >
> > That's a feature that HG ported from winboard. The "sizeNNN:" in front
> > says "use this font only for square size NNN".  If you don't have the
> > "sizeNNN:"
> > there, xboard will use the font for whatever the current square size is.
> > But
> > when it saves settings, it saves the fonts only for the current square
> > size. This feature is more important in WinBoard where there is a font
> > selection dialog and you can change the fonts (and the square size too)
> > without exiting and restarting the program.
> >
>
> Short comment from the Ionian isle of Kefalonia:
>
> This turned out to be pretty essential when we started saving settings. At
> first I naively saved the font variables from appData. But it was the
> matched font that would be saved, not the template with all the
> wild-cards, meaning that it would have a specific point size. If you would
> then later start XBoard with another -size, you would get totally
> non-fitting characters with it, because the full specification would
> basically disable the entire font-selection process.
>
> So at first I just refrained from saving the -font options altogether.
>
> Then I tried this WinBoard-inspired solution of saving the matched fonts
> per size, so that they would not affect any other board size than the one
> in force during the original selection process.
>
>
> ___
> Bug-XBoard mailing list
> Bug-XBoard@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-xboard
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[Arun Persaud]

Hi

> BTW: I am thinking we should remove the _( ) from strings that are just
> debug messages that get printed to debugFP (the xboard.debug file). Two
> reasons for that: (1) reduce the burden on the translation team -- let
> them focus on the messages that users really see, (2) xboard.debug is
> mostly to help us debug problems and it will be easier for us to read
> files people send us if they are in English.

agreed

thanks also for looking into all the other issues...

Arun


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font set.'

[h . g . muller]

>
> That's a feature that HG ported from winboard. The "sizeNNN:" in front
> says "use this font only for square size NNN".  If you don't have the
> "sizeNNN:"
> there, xboard will use the font for whatever the current square size is.
> But
> when it saves settings, it saves the fonts only for the current square
> size. This feature is more important in WinBoard where there is a font
> selection dialog and you can change the fonts (and the square size too)
> without exiting and restarting the program.
>

Short comment from the Ionian isle of Kefalonia:

This turned out to be pretty essential when we started saving settings. At
first I naively saved the font variables from appData. But it was the
matched font that would be saved, not the template with all the
wild-cards, meaning that it would have a specific point size. If you would
then later start XBoard with another -size, you would get totally
non-fitting characters with it, because the full specification would
basically disable the entire font-selection process.

So at first I just refrained from saving the -font options altogether.

Then I tried this WinBoard-inspired solution of saving the matched fonts
per size, so that they would not affect any other board size than the one
in force during the original selection process.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[Tim Mann]

Thanks for the replies.

The first thing to realize here is that because we're using old Xaw widgets
and the old X core fonts mechanism, nothing is going to work great.
Everyone's effort for years has been to make the new Xft font mechanism work
well, convert programs to use it, and make nice fonts that work with it.
(BTW, I don't think it's worthwhile thinking about converting the Xaw-based
xboard to use Xft. It would require drawing all text to be done in a
completely different way and I doubt it's even feasible to do with Xaw
widgets. Efforts are better spent on the GTK branch.)

Next... XCreateFontSet is meant to do the kind of thing you've being trying
to do by hand or suggesting we write our own code to do. A little
background: the "iso8859-n" (for some n) or "iso10646-1" or "koi8-r" etc. at
the end of a font name is just an encoding -- it says how character numbers
map to glyphs. iso10646-1 means Unicode, while iso8859-n is one of several
different 8-bit extensions of ASCII that were invented before Unicode.
koi8-r and koi8-u are encodings that were commonly used for Russian and
Ukrainian before Unicode. The encoding doesn't tell you for sure what
characters are actually in the font, but it's a good guess that (for
instance) a font that is encoded in koi8-u will have all the characters you
need for basic Ukrainian. iso10646-1 doesn't tell you a lot because the font
is always only a subset of Unicode, and you don't know how big a subset it
is. In the early days when XCreateFontSet was invented, a lot of X
installations didn't have any iso10646-1 fonts, or the ones they had were
missing a lot of characters that you could find in some of the other fonts.
So XCreateFontSet follows some rules that are encoded in the XLC_LOCALE file
for the locale and tries to find a bunch of fonts that will, collectively
(and hopefully), have all the characters that you may need in your current
locale.

Even though XCreateFontSet doesn't always do a great job, I think it's going
to be futile for us to try to hack around it to do something smarter. There
are too many languages, too many fonts each with their own set of missing
characters and peculiarities, and too many distros that each package the old
X core fonts in different ways and let users install different subsets.

With that preface I'll add some point by point comments.

On Mon, May 30, 2011 at 10:39 AM, Arun Persaud  wrote:

> Hi
>
> On 05/29/2011 02:04 PM, Tim Mann wrote:
> > What does the garbage look like?
>
> screenshot attached
>
> > I think it might be just that you don't
> > have a font with the necessary characters.
>
> yes, I think that's the problem...
>

I think it's an Xaw or Xt bug that it puts up garbage characters instead of
the box character. It should "know" that it couldn't find the character it
wanted in any of the fonts in the font set.


>
> > With the change I pushed, we
> > don't show any error messages when XCreateFontSet can't find all the
> > font charsets it wants, because for some reason it seems to want a lot
> > more than it really needs. (You can see the charsets that are missing
> > listed in the xboard.debug file if you run with the -debug flag.)
> > Though if you have the
> > -adobe-helvetica-medium-r-normal--*-*-*-*-*-*-iso10646-1series, I would
> > have expected them to have Ukranian characters.
>

Unfortunately they just don't. Nobody ever extended Adobe Helvetica to have
Cyrillic characters. That's why there is no iso8859-5, koi8-r, koi8-u
encoding of helvetica (because they would be missing all the important
characters for those encodings) and why the iso10646-1 encoding doesn't have
those characters.


>
> I tried to load this one, but in the debug file I get message that KOI8
> is not supported...


I don't understand that. Maybe that's one of several messages you got and
you just thought it was the most important?

As far as I can tell, XCreateFontSet ignores the encoding if you specify it
in your pattern, although that doesn't seem to agree with the documentation.
For example:

Requested font set for list -*-*-*-*-*-*-14-*-*-*-*-*-iso10646-1
 got list -*-*-*-*-*-*-14-*-*-*-*-*-iso10646-1, locale uk_UA.utf8
 got charset -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-1
 got charset -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-1
 got charset -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-2
 got charset -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-3
 got charset -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-4
 got charset -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-5
 got charset -misc-fixed-medium-r-normal--14-130-75-75-c-70-koi8-r
 got charset -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-7
 got charset -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-9
 got charset -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-13
 got charset -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-14
 got charset -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-15
 got chars

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

[Tim Mann]

I learned a bit more, but progress is slow.  Here are some observations:

* I was able to "fix" the slightly broken ru.po file that we have and get
the Russian translation to work. I didn't really know what I was doing; I
just did "make ru.gmo" and made likely-looking changes in places where I was
getting error messages and/or where the file header differed from the
examples that work. I notice we have some other broken translations, so
maybe those are fixable too. Maybe I should fix these and push a commit?

* Interestingly, the Russian translation is able to use the Microsoft
TrueType core fonts for the web that I have installed on my Ubuntu 10.04
system (they come from the ttf-mscorefonts-installer package). For instance,
the flags -messageFont "-*-arial-medium-r-normal--*-*-*-*-*-*-*-*"
-clockFont "-*-arial-bold-r-normal--*-*-*-*-*-*-*-*" -coordFont
"-*-arial-bold-r-normal--*-*-*-*-*-*-*-*" make that work, and the fonts look
nice, though I didn't check all the board sizes to be sure everything fits
right. This is much better than helvetica backed up by fixed.

* For some reason that isn't clear to me, the Ukrainian translation is *not*
able to use those fonts. They also cannot be used in the en_US.utf8 locale.
In both cases, XCreateFontSet always returns an error after failing to find
a font for *any* charset.

I think I have tracked the failure down to the
/usr/share/X11/locale/*/XLC_LOCALE file that gets chosen, but I don't know
what the problem with it is yet. This highly cryptic file controls how
XCreateFontSet chooses fonts for a locale. The ru_RU.utf8 locale has its own
XLC_LOCALE file, while the uk_UA.utf8 locale doesn't have one and is
configured to use the one for en_US.utf8 instead. (This is determined by
/usr/share/X11/locale/locale.dir and locale.aliases. All of this stuff is
part of X, not something we supply with xboard.) For some reason the
en_US.utf8 XLC_LOCALE file has criteria that cause XCreateFontSet to reject
all the Microsoft fonts, while the Russian one accepts them, or at least
enough of them to get the job done.

I don't know if there is any practical way for us to work around an issue in
the XLC_LOCALE file, but if I finish tracking this down I can try reporting
it upstream.

On Sun, May 29, 2011 at 8:41 PM, Tim Mann  wrote:

> I pushed a commit that uses "fixed" as a fallback font for missing
> charsets. It's ugly in large sizes (particularly the clocks), but at least
> it works.
>
> A nice (?) side effect of this commit is that "fixed" also will be used as
> a fallback when the user doesn't have helvetica installed at all. Everyone
> should have "fixed", as I understand it. The nice aspect is that the user
> without helvetica doesn't get an error message and xboard functions. There
> is also a not-nice aspect: the fixed font is ugly, so we may get complaints
> (or users who are unhappy but don't complain) about xboard having ugly
> fonts, when the real problem is just that they don't have helvetica
> installed.
>
>
> On Sun, May 29, 2011 at 6:06 PM, Tim Mann  wrote:
>
>> Basically this happens because the helvetica fonts that xboard uses by
>> default don't have Cyrillic characters, at least not the versions of those
>> fonts that you and I have on our machines. (I think we are both using some
>> release of Ubuntu, right? I'm using 10.04.)
>>
>> I don't understand why we get wrong characters instead of the "missing
>> character" glyph (which usually looks like a grayed-out open box), though.
>>
>> I am working to find a good way around this. At worst, I can tweak xboard
>> to use the "fixed" font family for charsets that it can't find in helvetica.
>> Unfortunately the fixed-width characters are a bit ugly. So far I haven't
>> found any other fonts that work with xboard and display Cyrillic in xboard
>> successfully, but I am confused about why some of the other fonts I have on
>> my system don't work. I have a number of fonts that xfontsel understands
>> (i.e., they are the X core font style of font, not the new fontconfig style
>> that xboard can't use), and which xfontsel can use to display Cyrillic text,
>> but XCreateFontSet fails and/or I still get incorrect characters with them.
>>
>> Sigh, none of this should be a problem in the GTK version of xboard since
>> gtk uses fontconfig fonts.
>>
>>   --Tim
>>
>>
>> On Sun, May 29, 2011 at 12:10 AM, Arun Persaud  wrote:
>>
>>> Hi
>>>
>>> I just pushed the new Ukrainian translation we got from the TP. When
>>> starting xboard (including your new commits) with
>>>
>>> LANG=uk_UA xboard
>>>
>>> I still get some garbage in the menu names though? I do get Umlaute and
>>> other special characters for
>>>
>>> LANG=de_DE xboard
>>>
>>> Any idea where this comes from?
>>>
>>> ARUN
>>>
>>
>>
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[Tim Mann]

I pushed a commit that uses "fixed" as a fallback font for missing charsets.
It's ugly in large sizes (particularly the clocks), but at least it works.

A nice (?) side effect of this commit is that "fixed" also will be used as a
fallback when the user doesn't have helvetica installed at all. Everyone
should have "fixed", as I understand it. The nice aspect is that the user
without helvetica doesn't get an error message and xboard functions. There
is also a not-nice aspect: the fixed font is ugly, so we may get complaints
(or users who are unhappy but don't complain) about xboard having ugly
fonts, when the real problem is just that they don't have helvetica
installed.

On Sun, May 29, 2011 at 6:06 PM, Tim Mann  wrote:

> Basically this happens because the helvetica fonts that xboard uses by
> default don't have Cyrillic characters, at least not the versions of those
> fonts that you and I have on our machines. (I think we are both using some
> release of Ubuntu, right? I'm using 10.04.)
>
> I don't understand why we get wrong characters instead of the "missing
> character" glyph (which usually looks like a grayed-out open box), though.
>
> I am working to find a good way around this. At worst, I can tweak xboard
> to use the "fixed" font family for charsets that it can't find in helvetica.
> Unfortunately the fixed-width characters are a bit ugly. So far I haven't
> found any other fonts that work with xboard and display Cyrillic in xboard
> successfully, but I am confused about why some of the other fonts I have on
> my system don't work. I have a number of fonts that xfontsel understands
> (i.e., they are the X core font style of font, not the new fontconfig style
> that xboard can't use), and which xfontsel can use to display Cyrillic text,
> but XCreateFontSet fails and/or I still get incorrect characters with them.
>
> Sigh, none of this should be a problem in the GTK version of xboard since
> gtk uses fontconfig fonts.
>
>   --Tim
>
>
> On Sun, May 29, 2011 at 12:10 AM, Arun Persaud  wrote:
>
>> Hi
>>
>> I just pushed the new Ukrainian translation we got from the TP. When
>> starting xboard (including your new commits) with
>>
>> LANG=uk_UA xboard
>>
>> I still get some garbage in the menu names though? I do get Umlaute and
>> other special characters for
>>
>> LANG=de_DE xboard
>>
>> Any idea where this comes from?
>>
>> ARUN
>>
>
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."

[Tim Mann]

Update of bug #33241 (project xboard):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."

[Tim Mann]

Update of bug #33241 (project xboard):

  Status:  Ready For Test => Fixed  

___

Follow-up Comment #12:

After some more emails, it seems that that Auguste's main issue was just that
helvetica is not installed on his system.  Hopefully the newer error messages
will make it clearer when that happens.

Auguste says he can no longer reproduce the part of the issue that I didn't
understand, so I am going to give up worrying about that part.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[Tim Mann]

Basically this happens because the helvetica fonts that xboard uses by
default don't have Cyrillic characters, at least not the versions of those
fonts that you and I have on our machines. (I think we are both using some
release of Ubuntu, right? I'm using 10.04.)

I don't understand why we get wrong characters instead of the "missing
character" glyph (which usually looks like a grayed-out open box), though.

I am working to find a good way around this. At worst, I can tweak xboard to
use the "fixed" font family for charsets that it can't find in helvetica.
Unfortunately the fixed-width characters are a bit ugly. So far I haven't
found any other fonts that work with xboard and display Cyrillic in xboard
successfully, but I am confused about why some of the other fonts I have on
my system don't work. I have a number of fonts that xfontsel understands
(i.e., they are the X core font style of font, not the new fontconfig style
that xboard can't use), and which xfontsel can use to display Cyrillic text,
but XCreateFontSet fails and/or I still get incorrect characters with them.

Sigh, none of this should be a problem in the GTK version of xboard since
gtk uses fontconfig fonts.

  --Tim

On Sun, May 29, 2011 at 12:10 AM, Arun Persaud  wrote:

> Hi
>
> I just pushed the new Ukrainian translation we got from the TP. When
> starting xboard (including your new commits) with
>
> LANG=uk_UA xboard
>
> I still get some garbage in the menu names though? I do get Umlaute and
> other special characters for
>
> LANG=de_DE xboard
>
> Any idea where this comes from?
>
> ARUN
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[Tim Mann]

Could you please do the following?

* Remove (or rename) ~/.xboardrc, start xboard with the -debug flag, and
reproduce the problem. Send us the xboard.debug file that is created. Also
send the ~/.xboardrc file that gets created.

* Do "xlsfonts > xlsfonts.txt" and send us the xlsfonts.txt file.

* Do "locale > locale.txt" and send us the locale.txt file.

* Put back your ~/.xboardrc file that you manually edited, start xboard with
the -debug flag, and confirm that you don't see the problem. Send us that
~/.xboardrc file and the xboard.debug file that is created. Be sure to label
the two .xboardrc and xboard.debug files so that we don't get confused about
which is which.

Thanks!

On Sun, May 29, 2011 at 3:05 AM, Auguste Pop wrote:

> Follow-up Comment #11, bug #33241 (project xboard):
>
> i tried the new version from git, still can not create font set. the error
> message is more verbose now. it's about failing to match helvetica.
>
> anyway, if i specify manually in ~/.xboardrc, i can start xboard. the
> difference is this time, the *'s are not all filled out in the saved
> ~/.xboardrc file. for instance, the iso8859 part is not set, it remains *.
>
> i thought maybe this is just a font problem on my machine. :P
>
>___
>
> Reply to this item at:
>
>  
>
> ___
>  Message sent via/by Savannah
>  http://savannah.gnu.org/
>
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."

[Auguste Pop]

Follow-up Comment #11, bug #33241 (project xboard):

i tried the new version from git, still can not create font set. the error
message is more verbose now. it's about failing to match helvetica.

anyway, if i specify manually in ~/.xboardrc, i can start xboard. the
difference is this time, the *'s are not all filled out in the saved
~/.xboardrc file. for instance, the iso8859 part is not set, it remains *.

i thought maybe this is just a font problem on my machine. :P

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."

[Tim Mann]

Update of bug #33241 (project xboard):

  Status: In Progress => Ready For Test 

___

Follow-up Comment #10:

I still don't fully understand the original issue in this bug report, but I
have pushed a fix into git for an internationalization problem that I do
understand: xboard was displaying garbage for any utf8 characters in its
internationalized messages that were outside the 7-bit ASCII range.  We were
failing to set the "international" and "fontSet" resources on our Xaw widgets;
instead we were using the first font returned in each font set and ignoring
the rest.

With luck maybe this change will fix Auguste's issue too.  Please let us know
and if you still have a problem, I'll take a look now that I understand this
area better.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[Tim Mann]

I've just pushed a git commit that fixes this issue. It was a few hours work
to get it all working 100% and avoid having libXt spit out "Warning: Missing
charsets in String to FontSet conversion" when xboard was started, but not
too bad.

I also fixed a couple of other tiny problems that I noticed, in separate
commits.

On Wed, May 18, 2011 at 7:13 PM, Tim Mann  wrote:

> Yes, that should do it. The default font is certainly a small change. I
> didn't look at the rest for very long, just enough to know it would take
> more time than I wanted to spend before going to bed. :-)
>
> On Wed, May 18, 2011 at 5:57 AM, h.g. muller  wrote:
>
>>  At 22:42 17-5-2011 -0700, Tim Mann wrote:
>>
>> It looks like we need to change FindFont to just return the fontset, then
>> change the rest of the code to set fontSet resources using that value
>> instead of setting font resources.  That looks like it will be a fair amount
>> of work to carry through fully. Maybe it's best to nuke all the old code in
>> the process instead of trying to carry it around and make it still work if
>> compiling without ENABLE_NLS defined.
>>
>>
>> Would this really require a lot of work? The current version uses 3 fonts:
>> clocks, board coordinates, and the rest. clockFont is used in only two
>> widgets, which explicitly mention an XtNfont arg at their creation. The
>> coordFont is only used for rendering text in the graphical board widget, for
>> which it is turned into a GC (coordGC). All the other stuff seems to be
>> handled in bulk, by the single call:
>>
>> XrmPutStringResource(&xdb, "*font", appData.font);
>>
>> Couldn't we simply change that call to
>>
>> XrmPutStringResource(&xdb, "*fontSet", fntSet);
>>
>> to acheive what we want? (And of course make sure fntSet used in FindFont
>> is a global variable.)
>> ___
>> Bug-XBoard mailing list
>> Bug-XBoard@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-xboard
>>
>
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[Tim Mann]

Yes, that should do it. The default font is certainly a small change. I
didn't look at the rest for very long, just enough to know it would take
more time than I wanted to spend before going to bed. :-)

On Wed, May 18, 2011 at 5:57 AM, h.g. muller  wrote:

> At 22:42 17-5-2011 -0700, Tim Mann wrote:
>
> It looks like we need to change FindFont to just return the fontset, then
> change the rest of the code to set fontSet resources using that value
> instead of setting font resources.  That looks like it will be a fair amount
> of work to carry through fully. Maybe it's best to nuke all the old code in
> the process instead of trying to carry it around and make it still work if
> compiling without ENABLE_NLS defined.
>
>
> Would this really require a lot of work? The current version uses 3 fonts:
> clocks, board coordinates, and the rest. clockFont is used in only two
> widgets, which explicitly mention an XtNfont arg at their creation. The
> coordFont is only used for rendering text in the graphical board widget, for
> which it is turned into a GC (coordGC). All the other stuff seems to be
> handled in bulk, by the single call:
>
> XrmPutStringResource(&xdb, "*font", appData.font);
>
> Couldn't we simply change that call to
>
> XrmPutStringResource(&xdb, "*fontSet", fntSet);
>
> to acheive what we want? (And of course make sure fntSet used in FindFont
> is a global variable.)
> ___
> Bug-XBoard mailing list
> Bug-XBoard@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-xboard
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[h.g. muller]

At 22:42 17-5-2011 -0700, Tim Mann wrote:
It looks like we need to change FindFont to just return the fontset, then 
change the rest of the code to set fontSet resources using that value 
instead of setting font resources.  That looks like it will be a fair 
amount of work to carry through fully. Maybe it's best to nuke all the old 
code in the process instead of trying to carry it around and make it still 
work if compiling without ENABLE_NLS defined.


Would this really require a lot of work? The current version uses 3 fonts: 
clocks, board coordinates, and the rest. clockFont is used in only two 
widgets, which explicitly mention an XtNfont arg at their creation. The 
coordFont is only used for rendering text in the graphical board widget, 
for which it is turned into a GC (coordGC). All the other stuff seems to be 
handled in bulk, by the single call:


XrmPutStringResource(&xdb, "*font", appData.font);

Couldn't we simply change that call to

XrmPutStringResource(&xdb, "*fontSet", fntSet);

to acheive what we want? (And of course make sure fntSet used in FindFont 
is a global variable.)___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[Tim Mann]

OK, I found out what's going on. Xaw is internationalized and supports utf8,
but on each widget we need to set the international resource to True, AND we
need to set the fontSet resource to the fontset we want to use. When
international is True, the widget's font resource is ignored and the fontSet
resource is used instead.

The current FindFont procedure (when ENABLE_NLS is defined) works by finding
a fontset, then pulling a single font out of it and returning that for use
with all the older code in xboard.c that was there prior to
internationalization and wants to deal with fonts instead of fontsets. It
looks like we need to change FindFont to just return the fontset, then
change the rest of the code to set fontSet resources using that value
instead of setting font resources.  That looks like it will be a fair amount
of work to carry through fully. Maybe it's best to nuke all the old code in
the process instead of trying to carry it around and make it still work if
compiling without ENABLE_NLS defined.

As a partial mock-up, though, you can see the fontSet resource at work just
by setting it from the command line:

LC_ALL=de_DE.utf8 ./xboard -ncp -size medium -xrm '*international: True'
-debug  -xrm '*whiteTime*fontSet:
-adobe-helvetica-bold-r-normal--34-*-*-*-*-*-*-*' -xrm '*blackTime*fontSet:
-adobe-helvetica-bold-r-normal--34-*-*-*-*-*-*-*' -xrm '*fontSet:
-adobe-helvetica-medium-r-normal--14-*-*-*-*-*-*-*'

That only sets the clock font and the default font, not the coord font, but
gives you the idea.

On Tue, May 17, 2011 at 9:14 PM, Tim Mann  wrote:

> After some more random googling and flailing, I have learned that setting
> the resource "*international: True" in Xaw widgets makes them do something
> more nearly correct.  Try this:
>
> env LANG=de_DE.utf8 xboard -xrm '*international: True'
>
> When I do that, I get correct umlauts and the ß character in Weiß (=White).
> But I don't get the right font -- it looks like all the characters are
> coming from the "fixed" font; they are all small and fixed-width.
>
>
> On Tue, May 17, 2011 at 10:24 AM, Arun Persaud  wrote:
>
>> Hi
>>
>> does anyone know of any other Xaw program that uses gettext? Perhaps we
>> can just check their code and see how they do it ;) I can't think of any
>> right now though, but will search a bit once I have some time on my
>> hands...
>>
>> Arun
>>
>
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[Tim Mann]

After some more random googling and flailing, I have learned that setting
the resource "*international: True" in Xaw widgets makes them do something
more nearly correct.  Try this:

env LANG=de_DE.utf8 xboard -xrm '*international: True'

When I do that, I get correct umlauts and the ß character in Weiß (=White).
But I don't get the right font -- it looks like all the characters are
coming from the "fixed" font; they are all small and fixed-width.

On Tue, May 17, 2011 at 10:24 AM, Arun Persaud  wrote:

> Hi
>
> does anyone know of any other Xaw program that uses gettext? Perhaps we
> can just check their code and see how they do it ;) I can't think of any
> right now though, but will search a bit once I have some time on my
> hands...
>
> Arun
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[Arun Persaud]

Hi

does anyone know of any other Xaw program that uses gettext? Perhaps we
can just check their code and see how they do it ;) I can't think of any
right now though, but will search a bit once I have some time on my hands...

Arun

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[Tim Mann]

iso10646 in the font name means Unicode. It doesn't mean utf8, since that's
just a way of compressing a sequence of 32-bit Unicode code points into a
sequence of 8-bit bytes.

What we see happening in xboard is that something (maybe Xaw, but I'm not
100% sure) does not understand that the string it is trying to display is in
utf8. So whenever there is a character in the utf8 stream that takes up more
than one byte, instead of repacking the bytes to get a single value > 127
and pulling that code point out of the font, it takes each byte separately,
pulls two code points in the range [128..255] out of the font and displays
those.

It would be better to fix this by handling the utf8 and taking characters
from the iso10646-encoded fonts instead of trying to pick an 8-bit character
set that fits the user's locale and recoding all the messages into that.
Well, except that I don't know exactly where the fix is needed.

I have been googling a bit but didn't find anything that specifically
addresses Unicode in Xaw. Here's a good FAQ on the whole topic of utf8 and
Unicode in Unix/Linux, though:  http://www.cl.cam.ac.uk/~mgk25/unicode.html

On Tue, May 17, 2011 at 2:54 AM, h.g. muller  wrote:

> 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.
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[h.g. muller]

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.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[Tim Mann]

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.

On Tue, May 17, 2011 at 1:08 AM, Tim Mann  wrote:

>
>
> On Tue, May 17, 2011 at 12:28 AM, h.g. muller wrote:
>
>>
>> I can add that so far I have not even succeded to get as far as running
>> into this
>> error message; my attempts to run a foreign language lways end in the
>> message
>> that the C library did not supports it, and then it runs fine (but in
>> English).
>
>
> I don't have an answer for the main problem, but I do have a suggestion
> about this one.
>
> Run "locale -a". If you don't see the locale for the language you are
> trying to use in the list, then you need to install more packages. I don't
> remember if you said what distro you are using. On my Ubuntu 10.04, under
> System > Administration > Language Support > Install / Remove Languages, I
> was able to install German and I could then run xboard with LANG=de_DE.utf8.
>
> This revealed a problem, though: characters with umlauts display as two
> garbage characters: Ã followed by something else. This looks like the
> typical symptom of trying to display utf8 text as if it were some
> single-byte encoding.
>
> Hmm, I bet this is related to Auguste's problem. Looking at the ~/.xboardrc
> file that was created, all the fonts have the -iso8859- suffix, which IIRC
> means single-byte encoding.  xboard wants to find iso10646 fonts instead, at
> least when using a utf8 locale. Something is probably wrong with xboard's
> NLS font selection code that lets it match fonts with any encoding instead
> of looking for iso10646. (I don't know what, though... I didn't write that
> code.)
>
>   --Tim
>
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[Tim Mann]

On Tue, May 17, 2011 at 12:28 AM, h.g. muller  wrote:

>
> I can add that so far I have not even succeded to get as far as running
> into this
> error message; my attempts to run a foreign language lways end in the
> message
> that the C library did not supports it, and then it runs fine (but in
> English).


I don't have an answer for the main problem, but I do have a suggestion
about this one.

Run "locale -a". If you don't see the locale for the language you are trying
to use in the list, then you need to install more packages. I don't remember
if you said what distro you are using. On my Ubuntu 10.04, under System >
Administration > Language Support > Install / Remove Languages, I was able
to install German and I could then run xboard with LANG=de_DE.utf8.

This revealed a problem, though: characters with umlauts display as two
garbage characters: Ã followed by something else. This looks like the
typical symptom of trying to display utf8 text as if it were some
single-byte encoding.

Hmm, I bet this is related to Auguste's problem. Looking at the ~/.xboardrc
file that was created, all the fonts have the -iso8859- suffix, which IIRC
means single-byte encoding.  xboard wants to find iso10646 fonts instead, at
least when using a utf8 locale. Something is probably wrong with xboard's
NLS font selection code that lets it match fonts with any encoding instead
of looking for iso10646. (I don't know what, though... I didn't write that
code.)

  --Tim
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."

[Auguste Pop]

Follow-up Comment #9, bug #33241 (project xboard):

after reading the strace output, which is quite cryptic to me, and considering
arun's earlier suggestion, i changed the last seven sections of all font
related specs into * in ~/.xboardrc. miraculously, xboard started.

the font were matched to -microsoft-cp1252 before, and it's now -iso8859-1

sorry for all the fuss i have created. anyway, although this seems to be
working now, removing ~/.xboardrc totally would still result in a "Unable to
create font set" error.

the new strace file is here: http://paste.pocoo.org/show/390425/

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[h.g. muller]

is there some way I can get more debug information from xboard?


To change the fonts in XBoard you wold need the options -font, -clockFont
and -coordFont, and give them that very long string as value argument.
That is a bit inconvenient on the command line (and presumably you will keep
getting the error unless you set all three of them to a valid value), so it
might be better to edit the ~/.xboardrc settings file. This will save (for 
each board

size you ever used separately) the font spec that actually matched the line
you originally gave (or was default) for the -font arguments.

The only way to get debug information from XBoard is run it with the option 
"-debug".
This puts the info on a file called xboard.debug. You can make it appear 
real-time

in the console by adding the option "-debugFile stderr".

I don't think there would be any extra info relevant for this problem, though.
The relevant code (from xboard.c) seems to be this:

char **fonts, *p, *best, *scalable, *scalableTail;
int i, j, nfonts, minerr, err, pxlSize;

#ifdef ENABLE_NLS
char **missing_list;
int missing_count;
char *def_string, *base_fnt_lst, strInt[3];
XFontSet fntSet;
XFontStruct **fnt_list;
base_fnt_lst = calloc(1, strlen(pattern) + 3);
snprintf(strInt, sizeof(strInt)/sizeof(strInt[0]), "%d", targetPxlSize);
p = strstr(pattern, "--");
strncpy(base_fnt_lst, pattern, p - pattern + 2);
strcat(base_fnt_lst, strInt);
strcat(base_fnt_lst, strchr(p + 2, '-'));

if ((fntSet = XCreateFontSet(xDisplay,
 base_fnt_lst,
 &missing_list,
 &missing_count,
 &def_string)) == NULL) {

   fprintf(stderr, _("Unable to create font set.\n"));
   exit (2);
}

nfonts = XFontsOfFontSet(fntSet, &fnt_list, &fonts);
#else
fonts = XListFonts(xDisplay, pattern, 99, &nfonts);
if (nfonts < 1) {
fprintf(stderr, _("%s: no fonts match pattern %s\n"),
programName, pattern);
exit(2);
}
#endif

Some printfs could be added here to get more info on what was actully passed
to the failing call XtCreateFontSet, and what it returned for missing_list etc.

I can add that so far I have not even succeded to get as far as running 
into this

error message; my attempts to run a foreign language lways end in the message
that the C library did not supports it, and then it runs fine (but in English).___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."

[Auguste Pop]

Follow-up Comment #8, bug #33241 (project xboard):

here is the strace result get by strace -o strace.result xboard

i don't know how to read it, just provided it for you information.

http://paste.pocoo.org/show/390407/

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."

[Auguste Pop]

Follow-up Comment #7, bug #33241 (project xboard):

i can match this font specification with xlsfonts. (see below)

my kernel is configured like
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_UTF8=m

maybe i did it wrong, because i don't know how to "give a similar FontSpec" to
xboard, so i actually did nothing.

is there some way i can get more debug information from xboard?

here is the xlsfonts outout:
$ xlsfonts -fn '-misc-fixed-*-*-*-*-*-*-*-*-*-*-iso10646-1'
-misc-fixed-bold-r-normal--0-0-100-100-c-0-iso10646-1
-misc-fixed-bold-r-normal--0-0-75-75-c-0-iso10646-1
-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso10646-1
-misc-fixed-bold-r-normal--13-120-75-75-c-80-iso10646-1
-misc-fixed-bold-r-normal--14-130-75-75-c-70-iso10646-1
-misc-fixed-bold-r-normal--15-140-75-75-c-90-iso10646-1
-misc-fixed-bold-r-normal--17-120-100-100-c-0-iso10646-1
-misc-fixed-bold-r-normal--17-120-100-100-c-0-iso10646-1
-misc-fixed-bold-r-normal--18-120-100-100-c-90-iso10646-1
-misc-fixed-bold-r-semicondensed--0-0-75-75-c-0-iso10646-1
-misc-fixed-bold-r-semicondensed--13-120-75-75-c-60-iso10646-1
-misc-fixed-bold-r-semicondensed--17-120-100-100-c-0-iso10646-1
-misc-fixed-medium-o-normal--0-0-75-75-c-0-iso10646-1
-misc-fixed-medium-o-normal--13-120-75-75-c-70-iso10646-1
-misc-fixed-medium-o-normal--13-120-75-75-c-80-iso10646-1
-misc-fixed-medium-o-normal--17-120-100-100-c-0-iso10646-1
-misc-fixed-medium-o-semicondensed--0-0-75-75-c-0-iso10646-1
-misc-fixed-medium-o-semicondensed--13-120-75-75-c-60-iso10646-1
-misc-fixed-medium-o-semicondensed--17-120-100-100-c-0-iso10646-1
-misc-fixed-medium-r-normal--0-0-100-100-c-0-iso10646-1
-misc-fixed-medium-r-normal--0-0-75-75-c-0-iso10646-1
-misc-fixed-medium-r-normal--10-100-75-75-c-60-iso10646-1
-misc-fixed-medium-r-normal--13-120-75-75-c-70-iso10646-1
-misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1
-misc-fixed-medium-r-normal--14-130-75-75-c-70-iso10646-1
-misc-fixed-medium-r-normal--15-140-75-75-c-90-iso10646-1
-misc-fixed-medium-r-normal--17-120-100-100-c-0-iso10646-1
-misc-fixed-medium-r-normal--17-120-100-100-c-0-iso10646-1
-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1
-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1
-misc-fixed-medium-r-normal--6-60-75-75-c-40-iso10646-1
-misc-fixed-medium-r-normal--7-70-75-75-c-50-iso10646-1
-misc-fixed-medium-r-normal--8-80-75-75-c-50-iso10646-1
-misc-fixed-medium-r-normal--9-90-75-75-c-60-iso10646-1
-misc-fixed-medium-r-normal-ja-0-0-100-100-c-0-iso10646-1
-misc-fixed-medium-r-normal-ja-0-0-75-75-c-0-iso10646-1
-misc-fixed-medium-r-normal-ja-13-120-75-75-c-120-iso10646-1
-misc-fixed-medium-r-normal-ja-17-120-100-100-c-0-iso10646-1
-misc-fixed-medium-r-normal-ja-17-120-100-100-c-0-iso10646-1
-misc-fixed-medium-r-normal-ja-18-120-100-100-c-180-iso10646-1
-misc-fixed-medium-r-normal-ko-0-0-100-100-c-0-iso10646-1
-misc-fixed-medium-r-normal-ko-17-120-100-100-c-0-iso10646-1
-misc-fixed-medium-r-normal-ko-18-120-100-100-c-180-iso10646-1
-misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso10646-1
-misc-fixed-medium-r-semicondensed--12-110-75-75-c-60-iso10646-1
-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
-misc-fixed-medium-r-semicondensed--17-120-100-100-c-0-iso10646-1


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."

[Arun Persaud]

Follow-up Comment #6, bug #33241 (project xboard):

found some reference on the web:

http://www.gentoo.org/doc/en/utf-8.xml

section "KDE, GNOME and Xfce". It seems that you need to use a font that
fits:

-misc-fixed-*-*-*-*-*-*-*-*-*-*-iso10646-1

that is, you need a iso10646 encoding for Xaw to work. Can you try this?

If this is it, we probably should check for this at startup, when NLS is
enabled

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."

[Arun Persaud]

Update of bug #33241 (project xboard):

Severity:  3 - Normal => 4 - Important  
  Status:None => In Progress
 Assigned to:None => apersaud   


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."

[Arun Persaud]

Follow-up Comment #5, bug #33241 (project xboard):

hmm, I just tried it again on my computer and can't reproduce this...
LANG=en_US.utf8 as well as LANG=de_DE or no LANG settings works just fine...
which will make this harder to debug :(

At the moment I think this might be a font-related problem, but I'll try to
look a bit more into it and perhaps we can add some default fallback or
something similar with a warning message instead of xboard quitting...

ARUN

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."

[Auguste Pop]

Follow-up Comment #4, bug #33241 (project xboard):

LANG is set to en_US.utf8

no warning while compiling.

i used make install, two .mo files are installed, namely
/usr/share/locale/de/LC_MESSAGES/xboard.mo and
/usr/share/locale/tr/LC_MESSAGES/xboard.mo

i tried to remove my ~/.xboardrc which specifies the font i used to use, but
still got the same error. do i have to install some x-fonts that provides
"helvetica"?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."

[Arun Persaud]

Follow-up Comment #3, bug #33241 (project xboard):

I think this error can show up, if you use a font that doesn't support all the
characters needed for the locale you are using... 

Some questions:

What language setting are you using when starting xboard with nls enabled?
Any warnings during the compilation?
Did you run "make install" do install the .po files?

Arun

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."

[Auguste Pop]

Follow-up Comment #2, bug #33241 (project xboard):

i am on archlinux. gettext is version 0.18.1.1, although gettextize --version
only reports 0.18.1

gettextize -f before ./autogen.sh does not help. i also tried to copy
/usr/share/gettext/gettext.h into xboard directory, aclocal -I m4, autoconf,
gettextize -f, and then ./autogen.sh, ./configure, make, still not helping.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

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

[h.g. muller]

At 16:35 6-5-2011 +, Tim Mann wrote:

I had a different problem: I'm on Ubuntu 10.04 with gettext-tools 0.17, but
Arun checked in stuff built with 0.18.  When trying to build, I got an error
about Makefile.in.in being the wrong version until I did this:

gettextize -f
./autogen.sh
./configure
make

I don't know if that will help you because your symptom is different from
mine.


Oh, but that will help me! Because I have exactly the same problem
(using Ubuntu 8.04). Thanks!

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."

[Tim Mann]

Follow-up Comment #1, bug #33241 (project xboard):

Presumably this worked for Arun on his system before he checked it in.  Could
you say exactly what linux (or other unix) distro you are on?  What does
"gettextize --version" say on your system?

I had a different problem: I'm on Ubuntu 10.04 with gettext-tools 0.17, but
Arun checked in stuff built with 0.18.  When trying to build, I got an error
about Makefile.in.in being the wrong version until I did this:

gettextize -f 
./autogen.sh
./configure
make

I don't know if that will help you because your symptom is different from
mine.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard

[Bug-XBoard] [bug #33241] xboard quits with "Unable to create font set."

[Auguste Pop]

URL:
  

 Summary: xboard quits with "Unable to create font set."
 Project: XBoard
Submitted by: auguste
Submitted on: Fri 06 May 2011 08:10:15 AM GMT
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

nls is enabled as default. disabling nls solves this problem.

a git bisect shows the first bad commit is
34e7a4b058c8ee6691dea2b5776459d58569840d

and when bisecting to the commit after that, there was an error about
po/POTFILES or something.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard