pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pan-users] Re: Error saving large JPEG image


From: walt
Subject: [Pan-users] Re: Error saving large JPEG image
Date: Thu, 13 Aug 2009 09:34:44 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3pre) Gecko/20090813 Shredder/3.0b4pre

On 08/13/2009 08:41 AM, Paul Crawford (at UoD) wrote:
Per Hedeland wrote:
The decode-for-viewing is in pan/usenet-utils/mime-utils.cc (relies
heavily on gmime), decode-for-saving (or maybe it's actually
decode-after-saving) seems to be in the uulib directory (driven by
pan/tasks/decoder.cc).

Thanks, that is useful to know and I can take a look later.

Rhialto wrote:
An easy check is to see if the line has the correct number of characters
on it.

In fact it may have one more: some versions of uuencode add an extra
checksum character at the end of the line. But then it should match, of
course.

And fractional numbers of characters are not possible :)

The problem, as I see now, is that many ASCII characters generate those
fractions when decoding.  There is no character other than 'E' to encode
the integer 49 :(


Thanks. I had not clocked that it was UUencoded than yEnc.

I guess the whole newsgroup area is littered with half-baked
applications that are not to one common standard (presuming that it
could exist in the first place)!

Well, I fixed it, sorta but not really.  Take a look at uulib/uunconc.c
line 476:
/*  suspicious = 1;    we're careful here REMOVED 0.4.15 __FP__ */

The HISTORY file says this about version 0.4.15:
- in previous versions, I have very much relaxed the checking for uudecoded
  lines (valid_data()). Now I only allow the less strong code (meaning,
  allow the data look more weird, more off the specs) if I'm sure it actually
  _is_ uuencoded data. This should work in all cases because it was usually
  only the last line with was "erroneous"

Adding that commented line back in fixes the breakage at least for
*this* particular example jpeg, but WTF knows what else it might break.

I also see comments in the code that this line probably broke xxdecoding
and that's why Frank commented it out.  Wikipedia says xxencode is now
obsolete, so I'd rather have it broken than uuencode.

Anyway, this change obviously is a matter of taste unless someone can
find a better fix for it.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]