Yes, this method plus a few others are not properly implemented for font
descriptors. Doing this correctly will require a bunch of changes in the back
end as well.
There is a proper mapping from the font descriptor to the concept of a font
config pattern, this could be used for the backends that support font config
(cairo and xlib on modern systems). For the other backends we could just try
to replace our self defined font information array, which we also call font
descriptor, with Apples new class.
This will require changes in NSFont, NSFontDescriptor and NSFontManager as
well as changes in all four backends (and as the xlib backend allows for
different font mechanisms we will need multiple implementations for these as
I am willing to work on that after the next GNUstep release, but help surely
is welcome here.
I just added a better support for font descriptors to GNUstep in SVN. Could
you please give this a try?
I also looked at the code of Emacs to see, which parts of font descriptors
actually get used there and noticed that it doesn't rely on the glyph
generation in GNUstep. This part has been added about a year ago, is there any
problem with our code, or did somebody forget to adjust to this feature?
Also line 500 in nsfont.m of emacs seems to be leaking font descriptors.