> * The loader's "create by type" function uses the module's name (i.e. > "gdi+" or "png"), rather than a mime-type. Lots of programs assume a > 1:1 relationship (eg. "give me the 'wmf' loader").
OK, so the internal interface between the gdk-pixbuf "main" code and built-in loaders could then be enhanced (without affecting the public API) so that gdk-pixbuf upper level code creates as many "pseudo-loaders/savers" as needed when a built-in loader/saver tells that it actually supports multiple formats. That way to the user programs it would still be a 1:1 relationship between "pseudo-" loader name and image types. > * The query-loaders mechanism requires that the supported formats be > known ahead of time With built-in GDI+ (and ani, pnm, ras, xpm etc) loaders, no gdk-pixbuf.loaders file is needed. > * There is no way that I know of to distinguish between a > metafile/vector format and a raster format, except maybe to try > loading everything as a metafile and see if something fails. Hmm, there are the ImageCodecFlagsSupportBitmap and ImageCodecFlagsSupportVector bits in the ImageCodecInfo::Flags field, is that enough? > * The functions that enumerate GDI+'s loaders simply don't exist in > the 1.0 version of the GDI+ DLL. Are you sure? The sample program from the GDI+ documentation in the Platform SDK that lists encoders using GetImageDecodersSize() and GetImageDecoders() works fine for me on XP. The version of the GdiPlus.dlls I find in the WinSxS folders is 5.1.3102.2180. I really would love to be able to have the GDI+ loader as a built-in... --tml _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list