On Mon, 10 Sep 2018 11:31:42 +0200 Bastien Nocera <had...@hadess.net> wrote:
> > I've written loader for GIF that simply wraps abydos. In lines of > > code it's about a quarter the size of the current loader, even > > including > > the GIF plugin for abydos. It might even be slightly smaller with > > the whole of abydos included in the equation. On the downside it > > probably doesn't pass the test suite since I haven't tried it. But > > I will, and hopefully publish the whole thing in a couple of days. > > That's unfortunately not mergeable, and unless you use a library for > your GIF plugin in abydos, would just be shifting the potential bugs > to the abydos code base. I do use a library (or two). I've written one plugin that uses giflib and one that uses ImageMagick. I assumed using giflib would be a straighter path, but it wasn't. Firstly it only supports reading images from disk (but abydos automatically creates temporary files then needed so that didn't add any extra code at least). Secondly it doesn't do much more than unpacking the pixels. How to interpret what comes out is left as an exercise for the user, and requires a bit of knowledge about the GIF formats and it's quirks. So that plugin isn't built by default. ImageMagick on the other hand did much more to be of help, and required far less code to use. So shifting the responsibility to ImageMagick seems reasonable, I think. I tested them both on all the GIF images included in the gdk-pixbuf test suit. Both plugins mostly work, but to varying degree. The one based on giflib segfaults with 1_partyanimsm2.gif (because the allocation containing the pixels which giflib provides is less than the images width x height, I haven't yet looked deeper into it). The ImageMagick based plugin on the other doesn't crash at least, and all the invalid images are correctly classified as invalid. The image 1_partyanimsm2.gif still shows as garbage except the first frame. The image aero.gif has the frame delay set to zero for every frame but the first. I'm not sure how that should be interpreted, so I simply exchanged zero values for a small delay (0.02 seconds). I will read up on the GIF format and hopefully get things working better. It's available here if you want to try it out: http://snisurset.net/code/abydos/ > > > - we disable every loader by default except the ones that the core > > > desktop needs > > > - image viewers that rely on gdk-pixbuf ship their additional > > > loaders > > > in the app's Flatpak[1]. > > > > I don't care much for Flatpak in particular. But generalised and > > rephrased as, leave it to the distributors to decide, I agree that > > this is absolutely the best approach. > > Without Flatpak, you're just removing image format support from image > viewers, as many packaging guidelines in distributions forbid the > bundling of libraries. They'd want to ship a single copy of the gdk- > pixbuf loaders, and the applications wouldn't have any protection from > files that the loaders would trip over. I'm not arguing against that. I just think it's an issue best left entirely to distributors (including the choice between bundling and dependencies). How and where to implement sandboxing is an interesting question still. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list