Sean MacLennan writes:
On Tue, 03 Jan 2012 00:54:09 +0900
"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
> Are you guys seriously proposing that we special-case this one
> particular bogus file? By simply silently ignoring the error?
Correct. Because of the design of image gifs (I don't want to get into
text gifs and other weird types) the terminator char is really just a
warm fuzzy. It is required by the spec, but not required to properly
display the gif.
Sure. Lots of standards have redundancy. Allowing nonstandard, less
redundant formats makes things more fragile. While you can probably
prove that there is no risk to your change if giflib is perfectly
implemented, all of the image libraries have suffered from critical
bugs in recent memory, and I suppose they have their share of minor
bugs that only show up if the app that calls them is buggy or lax,
too. I personally don't want additional fragility in my mission-
critical application, and I would argue XEmacs core (which for this
purpose includes xemacs-base and xemacs-devel but not the loadable
modules) should push for more simplicity and strictness in base
functionality that all XEmacs depends on, while providing hooks that
allow Lisp or modules to provide more powerful functionality.
If you could tell me that Wikipedia distributes and the GIMP produces
such GIFs (of course I'm exaggerating, but you get the flavor), I
might hold my nose and let it pass. But seriously, what do we lose by
fixing make-image-instance to warn less obtrusively, instead of going
out of our way to display something that's invisible anyway? (I
wouldn't be surprised to find out that single pixel is transparent!)
I was actually quite surprised that the image viewers and browsers I
tried handled the broken gif. But I guess that is why they get away
with it.
From what you say, it's not hard to handle, and if I were an image
viewer developer I would find your arguments attractive.
Nevertheless, XEmacs is neither an image viewer nor a browser. The
dedicated image viewers and editors mostly provide libraries we could
link to. If you want to go that direction, especially if it were
modularized (and therefore optional at runtime), that would be great.
Really! Heck, I'll even go find Jerry and physically lean on him
until he agrees to help with the modularization! :-)
But I don't see a need for repairing broken GIFs in core XEmacs, and
dealing with the stupid backtrace from the error is far more
important, because I think that's wrong even with genuinely busted
images.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta