Re: [Pan-users] yenc preview v. saving attachments

[Duncan]

DLSauers posted on Sat, 23 Jun 2012 04:04:31 +0000 as excerpted:

> On Fri, 22 Jun 2012 15:32:18 -0700, walt wrote:
> 
>> I can't answer the question you asked, sorry, but I've had pretty good
>> luck with uudeview over the years (I have little experience with
>> yydecode).
> 
> No joy, same thing... corrupt files, yet Pan displays fine.
> 
>> If you can give an example of one of the corrupted posts I can try
> 
> Email me for the info on the group(s) for the posts.
> 
>> uudeview at my end, or maybe you also have access to uudeview? It has a
>> -d flag (stands for desperate :) but maybe that will save only half the
>> file too.  Worth a try, anyway, while we wait for a better reply.
> 
> No joy with -d or via xdeview just puts out similar messages to the pan
> logs...

Unfortunately, uudeview was my suggestion too.  Some time ago, pan was 
screwing up segment order when decoding (IIRC that's one thing HM noticed 
and fixed fairly early, but I've not done binaries except for the 
occasional posting to a mailing list via gmane, for years...), and 
uudeview was what I sometimes used to fix it.

However, I guess it wasn't actually corrupt data... either that or either 
you or the poster did something not quite correct with the raw messages 
you ultimately fed to uudeview.

Could you describe the process you used to get the files you ran uudeview 
on?  I guess walt will be testing from his end and we don't have that 
result yet, but as you didn't yet describe the process of getting the 
files for uudeview to run on, that's one place things might be going 
wrong.

(FWIW, I used to use save message text, which effectively copies the raw 
message files out of cache to wherever you have it set to copy them to.  
Those raw message files were what I'd then feed to uudeview.)


One other possibility would be copying the raw message files out, then 
manually combining the yenc bits of each one (minus the checksums, etc).  
Obviously the final combined yencoded file will have the wrong checksum, 
but perhaps the -d option will work on that?

>>> Yet, the preview in Pan is PERFECT. The image is too large to capture
>>> at full resolution via KSnapshot, xwvd, gimp, etc.. been through
>>> those ideas already. :(

What's the error?  Out of memory, or something else?  How much memory do 
you have and (I'm assuming Linux, x86 or amd64) 32-bit or 64-bit system?

AFAIK there's a way via ksnapshot to capture the WINDOW, not the 
displayed screen.   If you manually resize the pan window to an 
appropriate size so it's showing the full-res image, even without the 
whole thing shown on screen, PROVIDED you don't run out of memory, it 
SHOULD be possible to snap the larger-than-screen window, then open that 
in gimp or kolourpaint or whatever and trim it down to just the desired 
image.  When you're as desperate as you seem to be...  (Been there...)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman