Update of bug #53060 (project gnustep):

                  Status:                    None => Confirmed              
             Assigned to:                    None => FredKiefer             


Follow-up Comment #1:

Normally I wouldn't want to support the xlib backend. We really don't want it
to be used by anybody any more. I did look into this issue just because of you
and your excellent patches and bug reports. I would be very thankful if you
wont provide a package for xlib and also for art in the future. Or at least
mark them as unsupported.

The problem here is that the applications you listed use special characters to
depict key equivalents in their menus. These characters aren't present in the
standard font that the xlib backend is using when trying to display this
string. So the NSAttributedString class tries to find a replacement font for
each of these characters. I tried this myself with the xlib backend and for
PikoPixel this fails for most of the special characters. IN that process the
code has to try every font available for this backend. For the cairo backend
with FT fonts this is a rather fast process. For xlib this takes almost for
The trick we use for cairo (and opal) is to leave this hard task to
With your changes it will be a bit faster and more reliable but this wont
resolve the general problem. The only thing that is supportable and could
resolve this issues that I see is to reuse the fontconfig/FCFontEnumerator
class for GSXFT. This is actually not that hard to do, FCFontEnumerator was
extracted from GSXFT.

I am still a bit tiered from FOSDEM and the journey back. So please be
patient, I hope to come up with something usable in the next few days.


Reply to this item at:


  Message sent via/by Savannah

Bug-gnustep mailing list

Reply via email to