Hans Breuer writes: > IMO fontconfig is a X-only library No it isn't. Its sources don't require any X headers, so in what way could it be an X-only library? On the contrary, when fontconfig is used on X11 (by Xft), this is precisely in order to *avoid* using the (core) X font technology, and instead use client-side fonts. > Why should one want to inherit the mess which X fonts are I assume you refer to the core X font mechanisms, with XLFDs etc, here? Nothing of that is "inherited" by fontconfig. > on a platform with better font support built-in ? Better than core X fonts? Maybe so, in a way. (But at least the X11 protocol is precisely defined, which is more than you can say about MS's vague documentation, and Win9x/NT/2k/XP differences.) But then, fontconfig doesn't have anything to do with core X fonts. > I'm still convinced that the native pangowin32 backend should be > the first class citizen on win32, but I appear to be the only one: What gives you the impression that pangowin32 isn't a first-class citizen? If I recall correctly, I once wondered aloud whether pangoft2 should replace pangowin32 on Win32 (mainly because of the lack of resources to maintain/optimise pangowin32), but Owen said that in his opinion pangowin32 should stay. > http://bugzilla.gnome.org/show_bug.cgi?id=94791 has the rotten bits In order to get any progress with that, you probably should propose a backend-independent API instead of new pangowin32-only API, which then would be implemented by the Pango backends. > - Some brokeness of glib::g_spawn_async on win32 Without patching > it The Gimp can't talk to it's plug-ins anymore. Although I have a > patch it is probably too dirty to be included in GLib ... Please open a bug for this, including a description of what is happening, and attach the patch even if dirty. Or would you just want to get rid of the gspawn-win32-helper process whenever possible? I would, too... If so, just add comments to bug #98737. --tml
