On 08/09/2009 10:50 AM, Paul Crawford wrote: > ...
This is a 2667 x 4000 pixel image, 1.8MB in size that renders correctly in pan's viewer, but the image is then corrupted (used here in the technical, rather than moral, sense) in 3 banded regions if saved to disk...
I think I've figured out what the problem is. Now, what to do about it. The example you cited is not yencoded, it's uuencoded. After perusing wikipedia's article on uuencoding I think I can explain this much: Here are the last few encoded lines from part 1 of the 3-part post: M2;>A=K&CJ^W2(%G1]S`?)@]&KDM8UJ?5K-%EA`*-]\=Z2]:ZU)XTV$1LQQ\V M<'N:N6VFR1PO;D9=?F!![5JK)"W-_0;>"WTR%50;F`W9ZU?-M!!O<$':00N< M8^E9&G,\B9VC*]CZC^M17KSD3329"1XR1P?H*CEN[EQ5RYJ%RP\QE8C`^7G. END ----- CUT HERE --- CUT HERE --- femjoy_111637_061.jpg Note that every line begins with 'M' except that last one. The first character in a uuencoded line encodes the number of bytes from the original binary file that are represented in that particular line. That number is decoded by finding the ascii value of 'M' and subtracting 32, i.e. 77 - 32 = 45, the number of bytes from the original jpeg encoded in a single line of the posted file. There are 4 uuencoded characters for every 3 binary bytes, so the number of ascii characters in the uuencoded line is (45*4)/3, or 60. If you count the number of chars in each encoded line you will get 60. Cool, eh? Now, that last line begins with 'E', so uudeview figures that this line of code should contain (69-32)*4/3 characters, which is 49.3. It then reads the next 49 chars from that line and proceeds to uudecode them, even though it produces garbage. Seems like it should be simple to add a test for the word 'END', and maybe when I'm more awake I can manage it. _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
