GNOME Bugzilla – Bug 426377
Articles more than 2 parts - jpeg/picture not displayed
Last modified: 2007-05-20 04:55:27 UTC
I am using v0.125 - not in the pick list above If i open an article that contains a jpg or any other picture format, and that article has more than 2 parts, the image will never display in the body pane. Note that the body pane is displayed, but it is blank. If the article has 2 or less parts, then the body pane displays the image. Article size does not appear to be an issue, but as soon as 3 or more parts are needed for the image, it seems to choke. Saving these articles works just fine. No crashes or errors appear.
I can't reproduce this, and my first guess is that it's another manifestation of the bug that caused bug #427230, which was fixed in 0.127. Could you give that version a spin and let me know what happens?
I tried v0.127 on Windows - still no go for 3 or more article parts. NOTE: I can only produce this odd behavior on the Windows version; the Linux version has always works correctly for me (using since v0.125)
Hi, I'm experiencing this bug, too. :( Eckythump (SVNr235; powerpc-apple-darwin8.9.0) Try it on some big artwork scans in the FLAC newsgroups (300dpi). But it does occur on small multipart .jpgs as well. btw a couple other Mac news-readers seem to behave this way, too, most notably Unison 1.7.9 and Thoth 1.7.2. I wonder if they've borrowed code from open projects ... nah, those shareware authors wouldn't outright violate licenses now would they ... ;)
This also occurs in 0.129. What other info would be useful to help track down the cause? On a random 3 part jpg, selecting Articles->Show Article Information, "... Lines: 4401 Bytes: 574261 This article has all 3 parts." GTK+ version is 2.10.6-1 pcre3.dll version is 6.4.2194.685
david: what os are you using, and what version of GMime do you have installed?
Having this multi-part problem in v0.129 as well. Debian OS using debian's packaged libgmime 2.2.6.
Finally got this one tracked down; it's a GMime bug.
*** This bug has been marked as a duplicate of 439841 ***
I've checked in a workaround into Pan in svn r291 to load the picture into memory instead of using the file streams at issue in bug 439841.