"walter s" <[EMAIL PROTECTED]> wrote: > >On 10/6/07, Greg Lee <[EMAIL PROTECTED]> wrote: >> On Sat, 06 Oct 2007 02:52:10 +0000, walt wrote: >> > ....something >> > in pan or gtk is being too fussy about decoding. I'll see if I can find >> > the cause -- eventually :o) >> >> Is it the decoding? When I save the decoded jpeg files with Pan >> and view them with a different viewer program, they seem perfectly okay.
[snip] >The part that's still confusing me is that pan doesn't save the jpeg to >disk and then display it from there -- instead it seems to load the jpeg >into RAM and then calls pixbufloader-jpeg to render it from there. I dug around in this code quite a bit when fixing the earlier bug with the same symptom (in 0.106 and earlier, which only affected pics split across multiple posts, and "only" uuencoded ones IIRC), and I remember being somewhat surprised to find that the decode-for-save and decode-for-display procedures were completely separate, using different methods (which explains Greg's observation above - the earlier bug was the same in this respect, saved pics were fine). But after a while it seemed to make sense:-) - the gmime/gtk functions were clearly aimed at doing precisely what Pan was using them for, displaying images from a message that is already in memory - I don't remember if they provided a way to save the result to disk, but I don't think so, and even if they did, the method would probably be suboptimal when *only* saving to disk. Doing it the other way around, i.e. using the decode-for-save and then loading and displaying the result, might have been an option, but I guess that would have required some additional code to be written - you can't just throw the file contents at the screen. Hm, of course occasionally the messages have text that should be displayed along with the pics, and this might actually be the main reason for the separate methods - the fast-and-simple decode-to-disk just throws away the text, and there is no way to correlate the resulting pics with the text for display - at least in principle, an "article" can have multiple pictures with interleaved text (though I've never seen one like that:-). >How pan converts attachment(s) to a jpeg and loads it to RAM is still >confusing me -- but that seems to be the step which is failing somehow. That's the gmime part, where IIRC Pan abuses the gmime functions a bit - as the name implies, they are intended to handle MIME messages, but News postings with pics are rarely MIME, so Pan has to "simulate" that part, directly feeding them e.g. chunks of uuencoded data picked up from different posts, while keeping track of these in some data structures w/o the help of MIME multipart headers etc. I remember that I had to go and read the gmime code (and I remember being rather un-impressed by it) to figure out what the problem was, and after some digging in old email it seems unlikely that it's the same thing happening in this case, unfortunately. But just in case, here's what I wrote about that (and it will make no sense until you have figured out the Pan code:-) - [...] The problem was that the handling of invalid uu lines was broken (the troublesome posts that I've come across had an extra empty line between the article header and the uu stuff): Since the gmime filter wants to see the "begin" line, it doesn't work to create a new filter for each chunk-between-invalid-lines. Fixed by having a "persistent" filter, which then needs to be attached to the output stream instead of the input. >> ... >> I looked at some other 1 part images in this same newsgroup and >> found that all those with byte size <= 369052 displayed correctly, >> but all those with byte size >= 369361 displayed incorrectly. Of >> the two dozen or so that I tried. > >An interesting observation. I'll keep it mind while I study this bug. >And while we all wait for Charles to fix it ;o) Good luck - as I have an older version of gtk on the box where I use pan, and no immediate plans on upgrading that, I'm not seeing this bug and won't be able to help (or at least I don't have motivation enough to help:-). --Per Hedeland _______________________________________________ Pan-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/pan-users
