At 01:21 25.05.03 +0000, Tor Lillqvist wrote: >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. > Yeah I know. But still think it is a library to solve X design problems: Linking font files to list fonts selectable by feature. This sure is (almost) solved on win32 for years. BTW: just tried to compile fontconfig with msvc. It does _not_ build out of the box. And although it certainly can be ported I'm pretty sure I dislike the 'give me another config file'-approach Also my motivation to solve problems again which are solved by GLib already is rather low ... > > > 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. > It strikes me odd to have to use two font backends (with diverging configurations) if one would be enough. As Linux will never use the pangowin32 backend it is common to throw in the pangoft2 dependency and don't see or accept the need f abstractions ... > > 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. > Something like that ? http://mail.gnome.org/archives/gtk-devel-list/2001-August/msg00612.html I'm not sure :) The results of that discussion where : "Having a pango_give_me_a_random_unknown_context_so_my_app_can_break() function sounds like a bad idea." It's fine with me to build my own private GIMP which _has_ text support. See: http://bugzilla.gnome.org/show_bug.cgi?id=113681 > > - 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. > The dirty patch to make it work is attached to the bug report now. Though I'm pretty sure the current cvs glib does not work, I haven't tested it again. Hans -------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert
