11:14 a.m.
Hi,
ads.pheedo.com serves 1x1 gif images that are not 100% correct,
resulting in the following type of error when using gnus:
(3) (image/warning) error: (image-conversion-error (GIF error: read
failed [gif :data GIF89aÿÀÀÀ!ù,D]))
and a very long and verbose *Warnings* backtrace, which messes up
article display.
Should we not bail out much earlier when we actually read in the gif
(and silently)?
GIF attached.
Robert
PS Emacs has a similar issue, vide
http://news.gmane.org/find-root.php?message_id=%3cm3hbidtph4.fsf%40quimbi...
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:58 p.m.
Robert Pluim writes:
Should we not bail out much earlier when we actually read in the gif
(and silently)?
For now, issue822.
XEmacs knows nothing about GIF (any more; 21.4 does use an ancient
giflib which is included as source in our distribution, but I am
certainly not willing to learn enough about GIF and that code to fix
it -- patches welcome, of course). I have read the emacs-devel
thread, and will take a look at better handling of errors from
DGifSlurp as cyd mentions, but I don't know yet if we use that or a
higher-level function.
If you have an alternative suggestion for how to recognize broken GIF
files without reimplementing the GIF decoding process, I'd be willing
to investigate that.
One possibility would be to revive the ImageMagick/GraphicsMagick
strategy of linking to one of the omnibus image-handling packages, but
that's pretty expensive compared to waiting for a fix from libgif.
BTW, this looks similar to
http://list-archive.xemacs.org/pipermail/xemacs-beta/2010-August/019895.html
at least as far as having a very small GIF file involved.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:52 p.m.
On Sat, Dec 31, 2011 at 2:58 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Robert Pluim writes:
> Should we not bail out much earlier when we actually read in the gif
> (and silently)?
For now, issue822.
XEmacs knows nothing about GIF (any more; 21.4 does use an ancient
giflib which is included as source in our distribution, but I am
certainly not willing to learn enough about GIF and that code to fix
it -- patches welcome, of course). I have read the emacs-devel
thread, and will take a look at better handling of errors from
DGifSlurp as cyd mentions, but I don't know yet if we use that or a
higher-level function.
We do use DGifSlurp, and that's what's telling us that the GIF file is
invalid, causing us to signal an error. I'd expect us to then return
'nil', but it appears that somehow a literal '0' is escaping to lisp.
I'm currently lost in a maze of unwind-protect and
call_with_suspended_errors to see how this could be fixed.
If you have an alternative suggestion for how to recognize broken
GIF
files without reimplementing the GIF decoding process, I'd be willing
to investigate that.
One possibility would be to revive the ImageMagick/GraphicsMagick
strategy of linking to one of the omnibus image-handling packages, but
that's pretty expensive compared to waiting for a fix from libgif.
I don't think we need look into that just yet.
BTW, this looks similar to
http://list-archive.xemacs.org/pipermail/xemacs-beta/2010-August/019895.html
at least as far as having a very small GIF file involved.
Yes, it's similar, except that now we don't crash.
Robert
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:40 p.m.
On Sat, 31 Dec 2011 12:14:39 +0100
Robert Pluim <rpluim(a)gmail.com> wrote:
Hi,
ads.pheedo.com serves 1x1 gif images that are not 100% correct,
resulting in the following type of error when using gnus:
It looks like the gif image is good... except it is missing the
terminator byte (0x3b). It is such a HUGE gif, they are probably trying
to save space ;)
All the readers I tried handled this gracefully, except XEmacs. Even
Emacs handled it.
I looked quickly at XEmacs 21.4 and DGifSlurp basically does this:
do {
GetRecordType
switch (type)
process
} while (RecordType != TERMINATE_RECORD_TYPE);
Since there is no terminate byte, GetRecordType tries to read the next
byte and fails.
I have some gif knowledge, but I am no expert so take this with a
lump of salt (unless you are on a salt reduced diet). But it looks like
this is done to get around not keeping track of the gif version. So
instead of doing what I would consider normal:
read header
if gif89a
read extension header
read image block header
read image blocks
read terminator
XEmacs does this:
read header
Slurp (as shown above)
It seems that the loop is only to handle the fact that the extension
header may or may not exist.
One solution is to check for EOF before calling GetRecordType, since it
looks like the lack of a terminator is not considered fatal in practice.
Cheers,
Sean
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:25 p.m.
On Sat, Dec 31, 2011 at 8:40 PM, Sean MacLennan <seanm(a)seanm.ca> wrote:
On Sat, 31 Dec 2011 12:14:39 +0100
Robert Pluim <rpluim(a)gmail.com> wrote:
> Hi,
>
> ads.pheedo.com serves 1x1 gif images that are not 100% correct,
> resulting in the following type of error when using gnus:
It looks like the gif image is good... except it is missing the
terminator byte (0x3b). It is such a HUGE gif, they are probably trying
to save space ;)
:)
All the readers I tried handled this gracefully, except XEmacs. Even
Emacs handled it.
I looked quickly at XEmacs 21.4 and DGifSlurp basically does this:
do {
GetRecordType
switch (type)
process
} while (RecordType != TERMINATE_RECORD_TYPE);
Since there is no terminate byte, GetRecordType tries to read the next
byte and fails.
I have some gif knowledge, but I am no expert so take this with a
lump of salt (unless you are on a salt reduced diet). But it looks like
this is done to get around not keeping track of the gif version. So
instead of doing what I would consider normal:
read header
if gif89a
read extension header
read image block header
read image blocks
read terminator
XEmacs does this:
read header
Slurp (as shown above)
It seems that the loop is only to handle the fact that the extension
header may or may not exist.
One solution is to check for EOF before calling GetRecordType, since it
looks like the lack of a terminator is not considered fatal in practice.
In 21.5, we use an external giflib, so we'd have to move the guts of
Slurp into our codebase, with the modification you suggest. I'm not
sure how desirable that is.
Robert
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:37 p.m.
On Sun, 1 Jan 2012 13:25:55 +0100
Robert Pluim <rpluim(a)gmail.com> wrote:
In 21.5, we use an external giflib, so we'd have to move the guts
of
Slurp into our codebase, with the modification you suggest. I'm not
sure how desirable that is.
Ok, here is another idea. I tested with with XEmacs 21.5.31. We change
gif_read_from_memory to handle this specific case:
static int
gif_read_from_memory (GifFileType *gif, GifByteType *buf, int size)
{
gif_memory_storage *mem = (gif_memory_storage *) gif->UserData;
if (size > (mem->len - mem->index)) {
/* Hack to handle a gif file that is missing the terminator byte. */
if (size == 1 && mem->len > 1 && mem->bytes[mem->len - 1]
!= 0x3b) {
*buf = 0x3b;
mem->len = 0;
return 1;
} else
return -1;
}
memcpy (buf, mem->bytes + mem->index, size);
mem->index = mem->index + size;
return size;
}
Since it is short, I added the entire routine. I just added the if
block. Since the UserData is setup once in gif_instantiate and only
used in gif_read_from_memory, it is safe to mess with the len.
I did a quick check to see that it handled the case where the
terminator was missing, but still caught some other random truncations
as errors.
Cheers,
Sean
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:01 a.m.
On Sun, Jan 1, 2012 at 7:37 PM, Sean MacLennan <seanm(a)seanm.ca> wrote:
On Sun, 1 Jan 2012 13:25:55 +0100
Robert Pluim <rpluim(a)gmail.com> wrote:
> In 21.5, we use an external giflib, so we'd have to move the guts of
> Slurp into our codebase, with the modification you suggest. I'm not
> sure how desirable that is.
Ok, here is another idea. I tested with with XEmacs 21.5.31. We change
gif_read_from_memory to handle this specific case:
Ah, I'd missed that we use our own read routine for gifs. That makes
life easier for us.
static int
gif_read_from_memory (GifFileType *gif, GifByteType *buf, int size)
{
gif_memory_storage *mem = (gif_memory_storage *) gif->UserData;
if (size > (mem->len - mem->index)) {
/* Hack to handle a gif file that is missing the terminator byte. */
if (size == 1 && mem->len > 1 && mem->bytes[mem->len - 1]
!= 0x3b) {
*buf = 0x3b;
mem->len = 0;
return 1;
} else
return -1;
}
memcpy (buf, mem->bytes + mem->index, size);
mem->index = mem->index + size;
return size;
}
Since it is short, I added the entire routine. I just added the if
block. Since the UserData is setup once in gif_instantiate and only
used in gif_read_from_memory, it is safe to mess with the len.
I did a quick check to see that it handled the case where the
terminator was missing, but still caught some other random truncations
as errors.
It works for me, I'll run with it installed for a while and see if it
causes any problem (I'd be surprised if it did).
Thanks
Robert
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:53 p.m.
Robert Pluim writes:
We do use DGifSlurp, and that's what's telling us that the
GIF file is
invalid, causing us to signal an error. I'd expect us to then return
'nil', but it appears that somehow a literal '0' is escaping to
lisp.
Ouch! I'm afraid I don't have much expertise there.
I'm currently lost in a maze of unwind-protect and
call_with_suspended_errors to see how this could be fixed.
Eh? Why are there call_with_suspended_errors there? Do you mean you
can't get it to crash with just (make-glyph [gif :file "img.gif"])?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:06 p.m.
On Mon, Jan 2, 2012 at 3:53 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Robert Pluim writes:
> We do use DGifSlurp, and that's what's telling us that the GIF file is
> invalid, causing us to signal an error. I'd expect us to then return
> 'nil', but it appears that somehow a literal '0' is escaping to
> lisp.
Ouch! I'm afraid I don't have much expertise there.
> I'm currently lost in a maze of unwind-protect and
> call_with_suspended_errors to see how this could be fixed.
Eh? Why are there call_with_suspended_errors there?
They're from when you call the _instantiate routine.
Do you mean you
can't get it to crash with just (make-glyph [gif :file "img.gif"])?
No. That works fine (and there's no crash when it does fail, just an
error). I don't think make-glyph actually causes the gif to be read
until later.
Robert
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:29 p.m.
Robert Pluim writes:
> One solution is to check for EOF before calling GetRecordType,
since it
> looks like the lack of a terminator is not considered fatal in practice.
In 21.5, we use an external giflib, so we'd have to move the guts of
Slurp into our codebase, with the modification you suggest. I'm not
sure how desirable that is.
I'll veto that. Does that answer the implied question?
(1) AFAIK, GIF is obsolete but well-defined technology. People who
distribute broken GIFs should be considered a hazard to the health
of the Internet.
(2) I've only ever heard of this particular bug with respect to this
pheedo situation. Let's remember what this is for: to provide an
invisible place to attach privacy-invading stuff to a web page. I
see no need to do anything to pander to them.
Show me some legitimate GIFs broken in this way that people actually
*want*, and I'll reconsider.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:46 p.m.
On Mon, Jan 2, 2012 at 4:29 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Robert Pluim writes:
> > One solution is to check for EOF before calling GetRecordType, since it
> > looks like the lack of a terminator is not considered fatal in practice.
>
> In 21.5, we use an external giflib, so we'd have to move the guts of
> Slurp into our codebase, with the modification you suggest. I'm not
> sure how desirable that is.
I'll veto that. Does that answer the implied question?
Yes. I'll be more direct next time :-)
(1) AFAIK, GIF is obsolete but well-defined technology. People who
distribute broken GIFs should be considered a hazard to the health
of the Internet.
(2) I've only ever heard of this particular bug with respect to this
pheedo situation. Let's remember what this is for: to provide an
invisible place to attach privacy-invading stuff to a web page. I
see no need to do anything to pander to them.
Show me some legitimate GIFs broken in this way that people actually
*want*, and I'll reconsider.
OK. Images from pheedo.com are easy enough to block in Gnus in any case.
Robert
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:54 p.m.
Robert Pluim writes:
On Sun, Jan 1, 2012 at 7:37 PM, Sean MacLennan <seanm(a)seanm.ca>
wrote:
> static int
> gif_read_from_memory (GifFileType *gif, GifByteType *buf, int size)
> {
> gif_memory_storage *mem = (gif_memory_storage *) gif->UserData;
>
> if (size > (mem->len - mem->index)) {
> /* Hack to handle a gif file that is missing the terminator byte. */
> if (size == 1 && mem->len > 1 && mem->bytes[mem->len
- 1] != 0x3b) {
> *buf = 0x3b;
> mem->len = 0;
> return 1;
> } else
> return -1;
> }
> memcpy (buf, mem->bytes + mem->index, size);
> mem->index = mem->index + size;
> return size;
> }
It works for me, I'll run with it installed for a while and see
if it
causes any problem (I'd be surprised if it did).
Are you guys seriously proposing that we special-case this one
particular bogus file? By simply silently ignoring the error?
(AFAICS the statement "mem->len = 0;" tells giflib that there's no
data there, no?)
We really need to fix the error stuff that Robert mentioned (which
should give the same result, or perhaps the calling code will need to
do a condition-case to ignore the GIF error). Presumably that could
happen on a real corrupted GIF.
I wonder if this comment at the top of gif_instantiate() might not
have something to do with it:
/* It is OK for the unwind data to be local to this function,
because the unwind-protect is always executed when this
stack frame is still valid. */
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:09 p.m.
Robert Pluim writes:
> Do you mean you can't get it to crash with just (make-glyph
[gif
> :file "img.gif"])?
No. That works fine (and there's no crash when it does fail, just an
error). I don't think make-glyph actually causes the gif to be read
until later.
Oops, not thinking. Of course it doesn't. Something like
(set-extent-begin-glyph (make-extent 1 1) (make-glyph [git :file "img.gif]))
I'll see if I can get it to crash for me tomorrow.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:26 p.m.
On Mon, Jan 2, 2012 at 4:54 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Robert Pluim writes:
> On Sun, Jan 1, 2012 at 7:37 PM, Sean MacLennan <seanm(a)seanm.ca> wrote:
> > static int
> > gif_read_from_memory (GifFileType *gif, GifByteType *buf, int size)
> > {
> > gif_memory_storage *mem = (gif_memory_storage *) gif->UserData;
> >
> > if (size > (mem->len - mem->index)) {
> > /* Hack to handle a gif file that is missing the terminator byte. */
> > if (size == 1 && mem->len > 1 &&
mem->bytes[mem->len - 1] != 0x3b) {
> > *buf = 0x3b;
> > mem->len = 0;
> > return 1;
> > } else
> > return -1;
> > }
> > memcpy (buf, mem->bytes + mem->index, size);
> > mem->index = mem->index + size;
> > return size;
> > }
> It works for me, I'll run with it installed for a while and see if it
> causes any problem (I'd be surprised if it did).
Are you guys seriously proposing that we special-case this one
particular bogus file? By simply silently ignoring the error?
(AFAICS the statement "mem->len = 0;" tells giflib that there's no
data there, no?)
I consider it a temporary local workaround, which we can discard now
I've discovered the appropriate Gnus variable. I don't think we should
install it.
We really need to fix the error stuff that Robert mentioned (which
should give the same result, or perhaps the calling code will need to
do a condition-case to ignore the GIF error). Presumably that could
happen on a real corrupted GIF.
The thing is, the current code is sort-of doing the right thing: it's
signalling an error when the gif turns out to be invalid, it's just
that the end-result of that is 293 lines of backtrace.
If I could figure out a way to return something valid-but-empty from
gif_instantiate I would, but understanding is eluding me for now.
Also, having just tested this for other image types, the same problem
exists in at least {jpeg, png}_instantiate as well. Perhaps we should
catch that error in make-image-instance?
I wonder if this comment at the top of gif_instantiate() might not
have something to do with it:
/* It is OK for the unwind data to be local to this function,
because the unwind-protect is always executed when this
stack frame is still valid. */
I'll make the unwind data non-local as see what happens, but I don't
have great hopes (but then again, I don't understand the code either
;) )
Robert
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:06 p.m.
On Mon, Jan 2, 2012 at 5:26 PM, Robert Pluim <rpluim(a)gmail.com> wrote:
Also, having just tested this for other image types, the same problem
exists in at least {jpeg, png}_instantiate as well. Perhaps we should
catch that error in make-image-instance?
In fact, text-modes/image-mode.el probably should be patched like
this, since it matches the expressed intent. (did make-image-instance
change signature?)
diff --git a/image-mode.el b/image-mode.el
index e9dd55a..a6959dd 100644
--- a/image-mode.el
+++ b/image-mode.el
＠＠ -82,11 +82,11 ＠＠
(let ((image (and type
(make-image-instance
(vector type :data (buffer-string start end))
- nil nil 'no-error))))
+ nil nil 't))))
(unless image
(setq image (make-image-instance
(vector 'string :data "format is not supported!\n")
- nil nil 'no-error)))
+ nil nil 't)))
(set-extent-property (make-extent start end) 'invisible t)
(let ((glyph (make-glyph image)))
(set-extent-end-glyph (make-extent end end) glyph))
It does mask a bug though, I think.
Robert
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:32 p.m.
Robert Pluim writes:
I consider it a temporary local workaround, which we can discard now
I've discovered the appropriate Gnus variable. I don't think we should
install it.
OK. I'm happy to hear that. :-)
The thing is, the current code is sort-of doing the right thing:
it's
signalling an error when the gif turns out to be invalid, it's just
that the end-result of that is 293 lines of backtrace.
Hm. I just got around to trying it, and I only get 43 lines. Maybe
we should blame larsi for the other 250 lines you get? ;-)
If I could figure out a way to return something valid-but-empty from
gif_instantiate I would, but understanding is eluding me for now.
I don't think returning is the right thing to do:
Errors should never pass silently.
Unless explicitly silenced.
The obvious application of the Zen is for the calling code to do the
explicit silencing. In the case of VM,
(condition-case nil
(set-extent-begin-glyph (make-extent (point) (point))
(make-glyph (vector 'gif :data data)))
(image-conversion-error (insert "[invalid GIF: " file "]\n")))
or similar.
Also, having just tested this for other image types, the same
problem
exists in at least {jpeg, png}_instantiate as well. Perhaps we should
catch that error in make-image-instance?
Unfortunately, there are times when we do want to see such errors. It
would be horrible for somebody to spend a few days trying to track
down why some image doesn't appear, only to find out that the image is
broken (according to giflib) and got swallowed in make-image-instance.
I agree that we do *not* (normally) want to see a backtrace for a
problem that XEmacs thinks is external. `make-image-instance' seems
to agree, it has a fourth argument NOERROR with this documentation:
NOERROR controls what happens with the image cannot be generated.
If nil, an error message is generated. If t, no messages are
generated and this function returns nil. If anything else, a
warning message is generated and this function returns nil.
But callers of make-image-instance don't generally seem to have a way
to control that. :-(
It doesn't say what's in the error message. Maybe we can suppress the
backtrace part in make-image-instance.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:46 p.m.
*sigh* I really should relearn to use IRC. Replies keep crossing in
the mail.
Robert Pluim writes:
diff --git a/image-mode.el b/image-mode.el
index e9dd55a..a6959dd 100644
--- a/image-mode.el
+++ b/image-mode.el
＠＠ -82,11 +82,11 ＠＠
(let ((image (and type
(make-image-instance
(vector type :data (buffer-string start end))
- nil nil 'no-error))))
+ nil nil 't))))
<barf/> You're right, this matches the design, but something called
"image-mode" should be prepared for this and do something useful with
the error, rather than silence it and return nil.
(unless image
(setq image (make-image-instance
(vector 'string :data "format is not supported!\n")
This should be "image conversion failed!", because it can easily
happen for supported formats, as you know.
- nil nil 'no-error)))
+ nil nil 't)))
No, here it should be "... nil nil nil)))". If an image instance of
type 'string isn't support, XEmacs is in *big* trouble. (Maybe an
XEmacs that doesn't support any consoles at all? :-)
It does mask a bug though, I think.
Heh. I know that author .... :-P
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:57 p.m.
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.
At a very high level, the format on an image gif is:
headers
image block(s)
0x00 terminator
0x3b terminator
Basically, you loop through the image blocks until you get a size of 0.
If you see the 0, the image is done. The 0x3b just confirms that.
(AFAICS the statement "mem->len = 0;" tells giflib that
there's no
data there, no?)
No. The UserData is not used in giflib. That struct is for
gif_read_from_memory only. I set the len to 0 so that we don't
provide 0x3b more than once. I don't think it would happen, but I am
paranoid that way ;) I believe it could be safely left out.
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.
And I was wrong about emacs. It just handles the error differently, it
will not display a gif without a terminator. It looks like it draws an
empty square.
Cheers,
Sean
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:19 a.m.
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
2:54 p.m.
On Tue, Jan 3, 2012 at 12:19 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
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! :-)
Ow! Get off me!
Seriously, though, I'll help if somebody wants to decide what external
libraries to modularize. Also, Stephen, I believe you mentioned
wanting an openssl module a few months back. Is that right?
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:03 p.m.
Jerry James writes:
Seriously, though, I'll help if somebody wants to decide what
external
libraries to modularize.
AFA image libraries go, according to what I've read, GraphicsMagick
has a more stable API than ImageMagick. OTOH, I'm not sure we care
about that since we have no backwards to compat. Besides, Emacs is
using ImageMagick, so we can get some useful tips and possibly apps
from them. I don't know if there are other libraries around.
Actually, basic modularization isn't all that hard. I've done a bunch
(both from former core code -- Canna -- and from scratch). But there
are some tricky aspects I haven't mastered (I'd like some help with
modules that need to load other modules and/or Lisp libraries as
prerequisites, but I'll get back to you on that), and if we're going
to hand GIF to Imagemagick, it *really* should be usable on Windows
(where GIF is a lot more prevalent than on Linux) which I know nothing
about modularizing beyond depending on ellcc.
There may also be some tricky aspects to image processing since it's
low-level and maybe gets called from redisplay?
Also, Stephen, I believe you mentioned wanting an openssl module a
few months back. Is that right?
Actually, I think it's Gnusies who want gnutls, which is going to be
pretty pervasive in Emacs 24. I suspect VM would be happy if we went
with the same TLS implementation as GNU, too. (If I had my druthers,
I think I'd go with openssl as the Gnubies have been through a fair
amount of pain with gnutls, especially w.r.t. Windows.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:14 p.m.
Stephen J. Turnbull wrote:
Actually, I think it's Gnusies who want gnutls,
yep.
If I had my druthers, I think I'd go with openssl as the Gnubies
have
been through a fair amount of pain with gnutls, especially w.r.t.
Windows.
There are places in which gnutls is a better alternative, although I
don't remember exactly why. Some time ago, I had to switch from openssl
to gnutls for properly interfacing with gmail (I think).
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:42 p.m.
On Tue, Jan 3, 2012 at 9:03 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Actually, basic modularization isn't all that hard. I've
done a bunch
(both from former core code -- Canna -- and from scratch). But there
are some tricky aspects I haven't mastered (I'd like some help with
modules that need to load other modules and/or Lisp libraries as
prerequisites, but I'll get back to you on that), and if we're going
to hand GIF to Imagemagick, it *really* should be usable on Windows
(where GIF is a lot more prevalent than on Linux) which I know nothing
about modularizing beyond depending on ellcc.
Ugh. Windows. I'm nearly a complete ignoramus when it comes to
Windows. My work and home machines have all been running Linux since
1999. And prior to that, I was a grad student working in a lab with
Solaris and Irix machines (and with a Linux machine at home starting
in ... 1996?).
There may also be some tricky aspects to image processing since
it's
low-level and maybe gets called from redisplay?
In that case, calls into the module will have to be wrapped with the
appropriate protecting calls.
Actually, I think it's Gnusies who want gnutls, which is going to
be
pretty pervasive in Emacs 24. I suspect VM would be happy if we went
with the same TLS implementation as GNU, too. (If I had my druthers,
I think I'd go with openssl as the Gnubies have been through a fair
amount of pain with gnutls, especially w.r.t. Windows.)
OK, I'll take a look at the gnutls interface sometime soonish.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:57 p.m.
Didier Verna writes:
There are places in which gnutls is a better alternative, although
I
don't remember exactly why. Some time ago, I had to switch from openssl
to gnutls for properly interfacing with gmail (I think).
Erm, that's precisely where a lot of the pain with gnutls was! It
didn't work with Gmail at first. ISTR they fixed it by requiring an
unreleased version of gnutls, which presumably will be released before
Emacs 24 is.
There were other problems, too, but I don't remember exactly what.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:15 p.m.
Stephen J. Turnbull wrote:
Erm, that's precisely where a lot of the pain with gnutls was!
Maybe it was a question of running it on Macs then, not sure anymore.
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:42 p.m.
Sean MacLennan <seanm(a)seanm.ca> writes:
It looks like the gif image is good... except it is missing the
terminator byte (0x3b). It is such a HUGE gif, they are probably trying
to save space ;)
These are tracker images. Someone claimed that they were constructed
that way because (some) browsers would keep the TCP socket open until
they received the complete image, which they never would, of course.
But this allows the tracker company to see how long time each user
spends reading the page.
I don't know whether this is true, though...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:03 p.m.
On Tue, Jan 3, 2012 at 9:42 PM, Lars Magne Ingebrigtsen <larsi(a)gnus.org> wrote:
Sean MacLennan <seanm(a)seanm.ca> writes:
> It looks like the gif image is good... except it is missing the
> terminator byte (0x3b). It is such a HUGE gif, they are probably trying
> to save space ;)
These are tracker images. Someone claimed that they were constructed
that way because (some) browsers would keep the TCP socket open until
they received the complete image, which they never would, of course.
But this allows the tracker company to see how long time each user
spends reading the page.
I don't know whether this is true, though...
You mean they're *deliberately* broken. I vote for:
(setq gnus-blocked-images "pheedo\.com")
as the default in Gnus, and let's stop faffing around with our GIF handling.
Robert
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:56 a.m.
Didier Verna writes:
Stephen J. Turnbull wrote:
> Erm, that's precisely where a lot of the pain with gnutls was!
Maybe it was a question of running it on Macs then, not sure anymore.
OK, we'll take it on faith that gnutls has its advantages.
It doesn't really matter; Emacs is using gnutls (for political
reasons, but there's nothing we can do about that), so that's where we
should start. gnutls has an OpenSSL compatibility API, and if that's
not good enough for somebody's OpenSSL-based application, they can
implement an OpenSSL module or configure option, with the advantage of
having a (hopefully mostly working) OpenSSL API already integrated and
with a Lisp API as reference for design.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4489
days inactive
4493
days old
27 comments
6 participants
participants (6)
-
Didier Verna -
Jerry James -
Lars Magne Ingebrigtsen -
Robert Pluim -
Sean MacLennan -
Stephen J. Turnbull