Frequently Asked Questions, Answered
Absolutely nothing. Originally, it could have stood for 'xview' or 'xviewer'. At that time, xv could only display a single image, at which point you'd click in the window to quit the program. I decided that since I (and everybody else) was going to be issuing this command frequently, it should be as short as possible. This was possibly the most important feature that xv had over xloadimage.
But that's all in the past. The program is called xv, and has never been officially named anything else. xv stands for xv.
Those who insist on reading meaning into the meaningless may note that it also stands for 15 in Roman numerals, could be used as an emoticon for 'dead cyclops', and given its most prevalent use could stand for "X-rated Viewer".
You don't. At least not with xv. This feature will make it into xv 4.00, but god only knows when that's going to be released. In the meantime, you can do nearly any image format conversion you'd ever want with netpbm.
When I try to view small images, they get horizontally stretched!
(Same problem.) In a design decision that I strongly regret, xv ties the viewed image size to the size of the image window. On the surface, it sounds like a good idea, since the window manager already provides methods for resizing the window - why duplicate all that? The problem comes up in cases like these. Modern X window managers enforce minimum window sizes, so that they have room to put minimize/maximize buttons (and whatnot) in the window's titlebar.
There are two workarounds: the '-nodecor' option (and X resource) can be used to request that the window manager not put a bunch of decorations on the window, which should allow xv to make the window as small as it likes.
No real reason - just a joke name that I decided to keep. Dog-wise, my tastes run more towards Basset Hounds. Not that I taste my dogs...
From a practical standpoint, it had the advantage that no one was likely to suddenly trademark the term. All the other good 'nosing around in some directories' sort of names had been taken: Finder, Browser, Explorer, Navigator, etc.
Hard to say, it's just this tradition. There's this band I'm in (The Electric Fish), it's a reference to one of the first X programs I wrote (xfish), there are 15 fish-objects (stuffed, wooden, etc) in the room where I'm typing this, etc. And I don't even own any real fish.
Because you're on some lame-o PseudoColor display, that's why. On PseudoColor displays (aka, 8-bit displays) there is a limited set of colors available at any one time. xv needs 64 colors to display the thumbnail icons in the visual schnauzer window. Since this would impact how well the current image can be displayed, xv normally uses a private colormap for the visual schnauzer. This frees up all the colors in the 'regular' colormap for the purposes of displaying the current image, and simultaneously gives the schnauzer a complete set of colors (256, typically) for its own purposes.
The upside is that both the image and the schnauzer look better. The downside is the annoying color flashing when you move between the windows.
You can specify the +vsperfect option to override this behavior. Doing so will force xv to share the same colormap between the schnauzer and the rest of the program. No flashes, but images won't display as nicely. It's up to you.
Of course, none of this is an issue on 16 or 24 bit TrueColor displays - if it's at all possible, I strongly recommend you run in a TrueColor visual.
In another of a long line of Design Decisions I Regret, xv tries to do all sorts of clever things with regard to the image window's position on screen. For example, if you issue the Max Size command, xv will position the window so that the window's contents exactly fill the screen (and the titlebar, frame, etc. are off the edges). Clever when it works, a big pain in the ass when it doesn't.
The popular window managers all seem to have different interpretations of how window-positioning is supposed to be done, and since almost no X programs try this sort of thing, the situation is mostly ignored. xv tries to do a number of clever things to get around the problem, but still fails on occasion.
The failure mode generally takes the form of the image window drifting down and to the right as you load new images, resize the window, etc. While it's hardly a brilliant solution, you can workaround this problem by using the -drift option and X resource.
Trust me, you almost certainly don't want to do that. As of this writing, nearly all printers that any of us can get our hands on are inherently bi-tonal. Meaning: for black/white printers, they can either put a dot at each 300dpi (or 600dpi, or whatever the printer's resolution is) pixel, or they can not. Each dot will either be fully black or fully white. (In the case of color printers, each dot can typically be one of eight colors.) These printers approximate greyscale (or full color) by dithering. As such, you really want each image pixel to correspond to several printer pixels. For example, printing the image at 75dpi (on a 300dpi printer) means that each pixel in the image is represented by a 4x4 square of black/white pixels on the printer.
Anyhow, my point is merely that you probably don't want to print color or greyscale images at much higher than 150dpi on today's 300 and 600 dpi printers.
The second part of the question: suppose you do want to print at 150 dpi. You'll find that the printed image is probably going to be smaller than you'd like, as the image size and the image resolution are inextricably linked. You can't raise the resolution without lowering the size, and vice-versa.
In this case, if you want the image to remain a respectable size, you'll need to synthesize some extra pixels somewhere. You do this by expanding the image in xv. Note, however, that unless the image was fairly small, you'll probably run into the "window can't be bigger than the screen" problem, which is a related outgrowth of the "let's tie the image size to the window size" design decision. You can work around this problem by using the -2xlimit or -nolimit options. It's not pretty, but it will work. Note that if you're working with really large windows, the Set Size command is your friend.
Common question. (Obviously, or it wouldn't be here!)
This happens on Sun machines running Solaris 2.x, and it's due to a simple compilation
problem. On said machines, I recommend turning on the -DSVR4
option in the top-level Makefile. A fine idea.
The problem comes in when you link against the BSD compatibility libraries, either
The solution is to explicitly use either /bin/cc or gcc in the top-level xv Makefile.
Note: You may run into a problem with unresolved externals involving the 'socket' calls. If this happens, add '-lsocket' to the CCOPTS line in the Makefile.
This problem is typically because HPs no longer have the needed X11 include files and X11 static libraries installed by default. Said files are distributed on the HP-UX CDs, but they need to be explicitly installed. I don't know how! (If someone who has an HP could tell me how they got the X11 files installed, please do so!)
Anyway, while this won't solve the actual problem of "how can I compile any X11 program on this machine", first-time xv'ers may want to try The HP-UX Porting and Archive Center. They have pre-compiled (unregistered) binaries of xv for HP-UX. Just download, gunzip, and 'tar xvf' them. This will expand the file into a large number of (mostly empty) directories, but there will be an xv executable in there somewhere. Your job: find it! Note that you'll still eventually want to get the X11 files installed on your machine, so that you can turn your xv into a registered copy (hint, hint), but this will at least let you see the darned thing first!
Also, if that doesn't work for you, I've been told that precompiled xv
packages for several versions of HP-UX can be found at this other HP-UX
Porting and Archive Centre
No, but these guys do!