[Xastir] Print and/or screen dump

[Tom Russo]

On Tue, Dec 28, 2004 at 01:35:04AM -0500, we recorded a bogon-computron collision of the <kd1yv at arrl.net> flavor, containing:
> Tom Russo wrote:
> 
> >On Sun, Dec 26, 2004 at 05:18:59PM -0500, we recorded a bogon-computron 
> >collision of the <kd1yv at arrl.net> flavor, containing:
> >
> >>happens at that point.  From the documentation, I believe that a gv 
> >>window is supposed to appear with the image for further manipulation 
> >>before trying to actually print, but it does not.
> >>
> >
> >Yes, when you click "preview" it should create a .ps file in ~/.xastir/tmp
> >and run gv on it.
> >
> The evidence is that is does neither.

Nod.  From what you say below, it never gets to the point where it could
create a .ps file.

> >>I tried setting the debug level to 512 and printing.  However, I cannot 
> >>see where the console output is.  I looked in /var/logs and ~/.xastir 
> >>and all of the directories and files below them, but none have been 
> >>updated in accordance with the debug settings.  Is there somewhere else 
> >>that I should look for the console output?
> >>   
> >
> >It should show up in the shell window where you started xastir, just dumped
> >to the screen. 
> > 
> Based on your suggestion, I am running it from a shell. 
> 
> The only message that I am seeing is: 
> "Creating /home/kd1yv8/.xastir/tmp/print.xpm  
> ERROR writing /home/kd1yv8/.xastir/tmp/print.xpm". 

That's pretty clear where the problem is, then.  It can't write the pixmap,
and that's the very first step in the printing process --- so it doesn't go 
on to create postscript.

*Why* it can't write the pixmap is another matter.

The call that creates the xpm file is XpmWriteFileFromPixmap.  If that call
fails, you get that ERROR writing message.  There are no shades of grey
to the error report --- either it creates the file successfully or it prints 
that error message.

> It doesn't matter if the debug level is 512 or 0, the message is the same. 

Nod.  That's not a debugging output message, it's an error telling you it
couldn't do what you asked.

> At first, I thought the obvious was that the permissions must be wrong 
> on that directory.  They were 0700 with kd1yv8/users.  I chmod them to 
> 0777, but still get the exact same error.  I tried the same on all of 
> the directories under .xastir, but still the same results.

That does seem the most obvious place to look for a problem.  

> I get the impression that the error is probably due to mis-set 
> permissions somewhere, but the error message doesn't give me any help 
> where to look.

Unfortunately, neither does the code.  XpmWriteFileFromPixmap returns an int,
and the code merely checks it against XpmSuccess.  There's no indication
of why it fails.  And on my machine xpm doesn't come with any man pages,
so I can't figure out what other values it might return and if there's any
way to coax more info out of it.

Actually, looking at xpm.h I see that one could probably extract a little more 
info by rearranging the code a tiny bit.  Look at maps.c, around line 2121.  
It looks like this:

    if ( !XpmWriteFileFromPixmap(XtDisplay(appshell),   // Display *display
            xpm_filename,                               // char *filename
            pixmap_final,                               // Pixmap pixmap
            (Pixmap)NULL,                               // Pixmap shapemask
            NULL ) == XpmSuccess ) {                    // XpmAttributes *attributes
        fprintf(stderr,"ERROR writing %s\n", xpm_filename );
    }


If instead you were to add an "int xpmretval;" at around line 2096 (up where
the other variable declarations are), and do:

   xpmretval=XpmWriteFileFromPixmap(XtDisplay(appshell),   // Display *display
            xpm_filename,                               // char *filename
            pixmap_final,                               // Pixmap pixmap
            (Pixmap)NULL,                               // Pixmap shapemask
            NULL );
   if (xpmretval != XpmSuccess) {
       fprintf(stderr,"ERROR %d writing %s\n", xpmretval, xpm_filename );
    }

you'd get some more information.  Look in /usr/X11R6/include/X11/xpm.h (or
wherever your xpm.h lives) --- you'll see a set of possible return values.
Mine has:

#define XpmColorError    1
#define XpmSuccess       0
#define XpmOpenFailed   -1
#define XpmFileInvalid  -2
#define XpmNoMemory     -3
#define XpmColorFailed  -4

Given the return value in the fprintf, you'd be able to see why it says it's 
failing.  That might not tell you how to make it succeed, but if it's 
OpenFailed or FileInvalid it might point the way.  If it's ColorError, NoMemory 
or ColorFailed I don't know how to fix it.

I'm thinking that perhaps this change is something that should be in the code
anyway --- the write function reports why it fails, we should probably
toss the user a bone and tell what we can about the nature of the failure.

Obvious (too obvious) other things to look at: does the exact directory
that is reported in the error message actually exist?  Is there a print.xpm
file in there that doesn't allow you to overwrite it?  Is there enough disk 
space to allow the file to be created?  Like I said, these are really obvious 
things, but one has to grasp at straws sometimes.

-- 
Tom Russo    KM5VY     SAR502  DM64ux         http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://www.qsl.net/~km5vy/
 "When life gives you lemons, find someone with a paper cut."