Re: [Pan-users] Re: Previews gone screwy

[Per Hedeland]

"walter s" <address@hidden> wrote:
>
>On 10/6/07, Greg Lee <address@hidden> 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