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 ever. The trick we use for cairo (and opal) is to leave this hard task to fontconfig. 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: <http://savannah.gnu.org/bugs/?53060> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep