NAME

xzgv - picture viewer for X, with thumbnail-based file selector

SYNOPSIS

xzgv [options] [dir | file ...]

DESCRIPTION

(NB: This man page is automagically generated from xzgv's texinfo file, and so may look a bit odd. We apologise for the inconvenience. :-))

xzgv is a picture viewer for X, with a thumbnail-based file selector. The thumbnails used (thumbnails being small `preview' versions of the pictures) are compatible with xv, zgv, and the Gimp. The kinds of pictures xzgv allows to be viewed are raster-format pictures (sometimes called `bitmaps' and/or `pixmaps'); things like GIF files, JPEG files, PNG files, and so on.

Most of the time, you will probably want to use xzgv's file selector (see The File Selector) to pick which file(s) to view. This is what appears on the left-hand side of the window when you start xzgv as just `xzgv' (see Options). It displays a list of subdirectories and picture files in the current directory, along with small `thumbnail' versions of the pictures if they exist. (If no thumbnails appear in a given directory, or if they are missing for some files, you can create/update them by pressing `u'. See Updating Thumbnails.)

When you've picked a file to view, you can view it by clicking on it, or pressing `Enter'. This reads the picture and displays it in the right-hand part of the window, the viewer (see The Viewer). You can then move around the picture (if it is larger than will fit) by dragging it with the mouse, or using the scrollbars, or the cursor keys. You can then select another image with the file selector (though you need to press `Esc' or `Tab' first if using the keyboard), or you can quit xzgv by pressing `q'.

While xzgv works much like any other X program, and is certainly mouse-friendly :-), it's also designed to be keyboard-friendly. Everything in xzgv can be done entirely from the keyboard. Much of this keyboard support works like the original zgv (a similar console-based picture viewer for Linux).

This overview is, as you might expect, only the very simplest of introductions to what xzgv can do, and describes only a very basic use of xzgv. xzgv can do a lot more; read on to find out what.

ACKNOWLEDGEMENTS

xzgv was primarily written by Russell Marks, also the author of this manual. It is maintained by Reuben Thomas, who ported it to Gtk+ 2.

Costa Sapuntzakis contributed code for much faster JPEG thumbnail generation (to zgv, which I adapted for xzgv).

The directory/file icons used were loosely based on gmc's dir-close.xpm. I think Tuomas Kuosmanen was responsible for that, judging from the change log.

`mkinstalldirs' is straight from the `texinfo' package, and was written by Noah Friedman. (This is also used during installation.)

Huge thanks go to the many people responsible for GTK+, without which xzgv would almost certainly not have happened. (But no thanks for Electric Eyes, which was nearly nice enough for me not to bother with xzgv at all! :-))

getopt*.[ch] are from the GNU libc.

OPTIONS

Normally you'd invoke xzgv as plain `xzgv' (perhaps via a window manager menu, or GNOME/KDE menu, etc.). However, you can directly specify files to view, or a start directory, on the command-line. In addition, there are various options.

(If you're new to xzgv, you should probably skip the rest of this section for now and come back to it later.)

The general format of the xzgv command-line goes roughly like this:

xzgv [options] [dir | file ...]

Two types of options are supported --- the traditional Unix single-letter options, and GNU-style long options. Most options can be used in either way, and both forms are listed in the table below.

Note that all options are processed after any configuration file(s). Config file settings are just like the long-option names below minus the `--' (see Configuring xzgv), though a few command-line options are not permitted as config file settings (e.g. `help'), and vice versa.

Here's what the options do:

`-a'

`--careful-jpeg'

`--delete-single-prompt'

`--dither-hicol'

`--exif-orient'

`--fast-recursive-update'

`-f'

`-g geom'

`-h'

`--image-bigness-threshold numpix'

`-i'

`--interpolate'

`--mouse-scale-x'

`--revert-orient'

`--revert-scale'

`--selector-width'

`-T'

`--show-thumbnail-messages'

`-k'

`-o order'

`--sort-timestamp-type type'

`--statusbar'

`-t'

`-v'

`--version-gtk'

`-z'

`-r'

`-p'

If started with `xzgv files', xzgv hides the file selector and treats the file or files as if they were the sole contents of a directory. (It also automatically loads the first file.) As such, you can use the Next Image and Previous Image commands to navigate between the images, or do Exit to Selector and use the selector directly.

If started with `xzgv start-dir', xzgv starts up as usual, but with the selector starting on the directory specified (rather than the current directory).

Settings which are either on or off (boolean) are, as you might expect, enabled by using e.g. `-z' or `--zoom'. However, there's an alternative long-option form for setting these, resembling how they're set in config files --- the syntax is `--option=state', where state is `on'/`y'/`yes'/`1' to enable the option, or `off'/`n'/`no'/`0' to disable it. The most useful thing about this is that it allows you to disable options which were previously enabled, by using e.g. `--zoom=off'.

(Readers used to the way GNU-style long options work should note that, since this `on'/`off'/etc. arg is optional, you can't use the `--option arg' form in this case; it must be `--option=arg' for it to work.)

A NOTE ON NOTATION

Much of this manual is taken up by a description of xzgv's various commands in its file selector and viewer. Most of these are available both from the keyboard, and from popup menus. (A popup menu appears when you press `F10' or `Menu', or right-click on the selector or the viewer; each has its own menu.) So in the manual, you will often see things rather like this:

`key'

Sometimes the key given has a `(Selector)' or `(Viewer)' suffix; this is because some keypresses in xzgv are specific to the selector or the viewer, and won't work unless the relevant part of xzgv has the keyboard focus.

THE FILE SELECTOR

Usually, on starting up xzgv, you'll want to use the file selector --- the list of files on the left. (The other subwindow (on the right) is the viewer.) The selector lets you pick files to view (among other things). It lists the subdirectories and picture files in the current directory, along with small `thumbnail' versions of the pictures if they exist.

THE SELECTOR MENU

Almost all selector commands are available from the selector's pop-up menu, which appears when you right-click anywhere on the selector. (You can also press `F10' or `Menu' to bring up the menu, but as there are keyboard shortcuts for just about everything in xzgv, this isn't often that useful. :-))

Usually, it doesn't matter where on the selector you right-click. However, a few commands on the File menu operate on a single file, the one selected by the keyboard cursor. A problem when using the mouse, you might think --- but when you right-click on the selector, as well as popping up the menu, xzgv moves this cursor to the file you right-clicked on (if any). (You can see this by the way a hollow box is drawn around the file.) So to use e.g. Details on the File menu, you need to right-click on the file you want details on.

Both the selector and viewer have `Help' menus, most items of which refer you to this manual:

`F1'

`Selector menu, Help, The File Selector'

`Viewer menu, Help, The Viewer'

`Selector menu, Help, Index'

`Selector menu, Help, About'

Currently, the way xzgv lets you read the manual is a bit crude; it runs the `info' program (see Top in the info-stnd info file) in an `xterm'.

EXITING XZGV

You can exit xzgv either by using one of two exit keypresses, or by selecting the appropriate option from the selector's popup menu:

`q'

(There's also an exit option on the selector's File menu (`Selector menu, File, Exit'), as `Exit' is generally on any File menu.)

THUMBNAILS

(This section is deliberately early on in the manual, as thumbnails are probably the most important feature of the file selector, so it's best that you know how to create/update them sooner rather than later.)

Thumbnails are small versions of the pictures they represent, and are displayed by the file selector if they exist. xzgv uses xv-compatible thumbnails --- if you create thumbnails with xv they will work with xzgv, and vice versa. xzgv's thumbnails are also compatible with the Gimp, and zgv.

If no thumbnail exists for a file, a small `document' icon appears instead (similar to the `folder' icon used for directories).

SELECTOR LAYOUT AND RESIZING

The file selector is simply a list of subdirectories and filenames, along with any thumbnails that exist for them. The list is normally in asciibetical order (but you can change this; see Changing the Sorting Order). Names of directories are shown first, and they are shown in order at the beginning of the list, before all the picture files. Long filenames may not fit in the visible part of the file selector display; if so, there will be a horizontal scrollbar you can use to see the rest of the name(s) (you can use cursor left/right to do this from the keyboard).

The list is very often larger than can fit on the screen at once. If this is the case, only part is shown at a time, but you can move around the list using the (vertical) scrollbar, or with cursor up/down and the like.

If you find the selector window to be too small vertically, and would like to see more files at once, you can start xzgv fullscreen by using the -f option (see Options), and/or use `thin rows' mode (see File Selector Options).

If you find the selector too small (or too big) horizontally, you can change this by moving the splitter line's `handle' (a small square button between the selector and viewer, near the bottom of the window), which changes the relative sizes of the selector and viewer. You can move it by dragging it with the mouse, or with these keys:

`['

`Ctrl-['

`]'

`Ctrl-]'

`~'

You can also set the initial/default size of the selector --- in effect, the position of the window split --- using `--selector-width' (see Options) or the config file option `selector-width'.

MOVING AROUND THE LIST

This section is mainly for those of us more inclined to the keyboard side of the force. :-) Mouse-happy types can freely skip it.

When the selector has the keyboard focus, the cursor (or in GTK+ jargon, the `focus row') is normally shown as a hollow box around one of the list's rows. This serves the following functions:

- It selects a file for view commands to operate on.

- It determines which part of the list is shown, as the part of the list shown onscreen always contains the cursor (unless you move around using the mouse).

There are several commands for moving the cursor. In summary, most `special' keys like the cursors do what you'd imagine they do, but in more detail:

`Cursor Up'

`Cursor Down'

`Page Up'

`Page Down'

`Ctrl-Home'

`Ctrl-End'

`g'

VIEWING A FILE

To view a file from the selector, you can click on it, or press `Enter' after moving the cursor to the relevant file, or right-click on the file and choose `File' then `Open'.

`Enter'

DIALOG BOXES

See The Viewer, for details of how the viewer works. If xzgv has a serious problem reading a file, it will give an error. Errors are shown in dialogs which appear in the middle of the screen --- they stay there until you click Ok (or press `Enter' or `Esc').

xzgv also uses similar dialog boxes for other things:

- Getting confirmation that you want to do something. `Enter' or `y' picks `yes'; `Esc' or `n' picks no. (Again, you can click on the relevant button with the mouse to do the same.)

- Showing progress when updating a thumbnail. This is a slightly unusual dialog, in that it automatically disappears when the update is complete. However, it does provide a Cancel button which you can click to abort the update (pressing `Enter' or `Esc' does the same).

- Reading a directory name. Here you should type the directory name then click Ok (or press `Enter'), or click Cancel (or press `Esc') to abort. The text-input `widget' used allows a certain amount of editing, including these keys:

`Cursor Left'

`Cursor Right'

`Home'

`End'

`Backspace'

`Delete'

You can also set the X selection (by selecting text with the mouse, or holding `Shift' while moving the cursor) to allow pasting text into other programs, and you can cut/copy/paste text in the usual ways:

`Shift-Delete'

`Ctrl-Insert'

`Shift-Insert'

You can paste text from (some) other programs using the latter command, too.

CLOSING A FILE

Usually, when you view a file, the viewer subwindow keeps displaying it until you view a different file. However, if you `close' the file, the viewer stops displaying the file and returns to its initial state.

`Ctrl-w'

FILE DETAILS

The listing the selector gives for a file is pretty sparse --- just the filename and (if the file has one) the accompanying thumbnail. While this does keep things simple, you sometimes want to know how much space a file takes up, when it was last modified, the dimensions of the image, that kind of thing. So, you can show details of a single file using the `file details' command:

`:'

Most of the details shown come from the OS (by using the `stat(2)' system call), and should always be available unless you have limited permissions for the directory the file is in. The file dimensions (width/height), however, come from the file's thumbnail. If it doesn't have one, or if it's unreadable, or if it has one and it's readable but it doesn't mention the original image's width/height, then the Details from thumbnail area is greyed out.

(In explanation of the latter point --- pre-5.0 versions of zgv did not generate width/height comments in thumbnails, so zgv users in particular may find the width/height details missing. (xzgv has always been ok, though, it's just zgv which had this problem.) Worse yet, versions 5.0 and 5.1 generated them with incorrect sizes for most JPEGs. To fix either problem for a given directory, do `rm -fr .xvpics' in that dir from a shell prompt and recreate the thumbnails with zgv 5.2 or later, or xzgv/xv/Gimp.)

TAGGING

The file selector is not restricted to working on one file at a time. You can `tag' as many (or as few) files as you wish, and certain commands described in this section will act on them.

Initially, all files are untagged, and the filenames usually appear in black (though this depends on the GTK+ theme you're using). Tagged files appear in red.

RENAMING A FILE

As well as copying/moving files, you can rename them:

`Ctrl-n'

I know `Ctrl-n' isn't the most mnemonic keypress possible for `rename', but all the good ones were taken. :-/

DELETING A FILE

Deleting a file is pretty straightforward:

`Ctrl-d'

Note that only one file is deleted (hence `Delete file'); there is currently no way to delete all tagged files.

CHANGING DIRECTORY

The easiest way to change the current directory in xzgv is usually to click on a directory entry in the file list (or move the cursor to it and press `Enter'). Selecting the `..' entry moves to the parent directory of the current one.

There is an alternative though:

(Note that the key for this command is shift-`g', not `g'.)

`G'

RESCANNING THE DIRECTORY

Normally, xzgv reads a directory once (on starting up, or when a new directory is selected). So if the contents of the directory are changed by another program, this is not automatically reflected. You can, however, explicitly tell xzgv to `rescan' the directory (reread the contents), which will update xzgv's notion of what's in it:

`Ctrl-r'

CHANGING THE SORTING ORDER

Normally, the files are listed in asciibetical order by name. However, you can instead have the file list sorted by size, last-modified date/time, or by `extension' (the file type).

(Only the order of files can be altered; directories are always listed first, and always in name order.)

`Alt-n'

`Alt-e'

`Alt-s'

`Alt-d'

You can set the default sort order via the command-line (see Invoking xzgv) or a config file (see Configuring xzgv).

There are three possible timestamps you can use for the `Time & Date' sorting order:

`Alt-Shift-m'

`Alt-Shift-c'

`Alt-Shift-a'

FILE SELECTOR OPTIONS

Various aspects of the file selector's behaviour can be configured while xzgv is running, by using these toggle commands (which enable the feature if it was previously disabled, and vice versa).

These settings can also be altered using command-line options (see Options) and/or config file settings (see Configuring xzgv).

`Alt-a'

`Alt-b'

`Selector menu, Options, Thumbnail Msgs'

`v'

`Alt-i'

THE VIEWER

Once you've selected a file to view, it's shown in the viewer (the right-hand part of xzgv's window). This section describes what you can do while viewing the picture.

Like the selector, the viewer has its own menu --- right-click anywhere on the viewer (or press `F10' or `Menu') to show it --- and a similar help menu (see The Selector Menu).

EXITING THE VIEWER

When using the mouse to control xzgv, it doesn't matter whether the selector or the viewer has keyboard focus --- mouse operations transcend such petty boundaries. :-) But keyboard control is (of necessity) effectively modal, and so you need to `exit' the viewer in order to have keyboard control over the selector again. You also need to exit the viewer if you've enabled auto-hide mode.

Exiting the viewer is simple:

`Esc'

Another way of exiting the viewer is to middle-click on it, but this mouse-only approach is really only of use when the selector is `hidden'.

BIG PICTURES

A picture may well be too large to fit entirely in the viewer window. There are two main things which can help you see more of the picture at once:

- Make the xzgv window larger. You could `maximize' it with your window manager, or you could start xzgv with a larger window using `--geometry' or fullscreen mode (see Options). The fullscreen mode gives xzgv the maximum window size possible, but needs co-operation from your window manager (and alas, many are not as willing as one might like) --- in some cases you may even find `--geometry 100%x100%' to be more effective.

- Hide the selector. To do this, either use auto-hide mode (see File Selector Options), or hide the selector explicitly (see Hiding the Selector).

But of course, these are only partial solutions to the problem; there will inevitably always be pictures larger than your screen can show at once. In general, then, there are two ways to see the whole of the picture.

SCALING

You can scale a picture --- this makes it appear larger (or smaller) onscreen. xzgv acts much as if the scaled picture were the real picture; for example, the cursor keys scroll around in steps of 100 scaled pixels, even if this means moving a fraction of a pixel (or many pixels) in the original picture (and similarly for movement with the mouse).

The main limitation of scaling (other than how much it slows things down :-), at least when scaling up) is that you can only scale by integer values, so you can only make each pixel in the image twice as wide/high, or three times as wide/high, or four times, and so on.

(It may seem odd saying e.g. `twice as wide/high' rather than `twice the size', but technically `twice the size' would be referring to scaling up the width (and height) by about 1.414...)

Normally, xzgv does no scaling, which could be considered a ratio of 1:1. Scaling up increases that ratio. How it is increased depends on which option/key you use:

`d'

`s'

There are similar commands to decrease the ratio:

`D (Shift-d)'

`S (Shift-s)'

Usually the double/halve scalings are more useful.

Note that you can also double/halve the scaling by using shift-left-click on the viewer to double, and shift-right-click to halve. This still changes scale `around' the middle of the window though (rather than around the point clicked on, as you might expect), which is a little strange and may possibly be changed in future.

When you scale `below' 1:1, the above commands lead to ratios of (e.g.) 1:2, 1:4, 1:8, etc. --- that is, the ratios work the same way, but the other way around. This gives you an increasingly small image.

The scaling ratio is never decreased below 1:32. It is also never increased beyond the point where the overall image size would exceed 32767x32767 --- this limit is due to the combination of X's limit on window sizes, and the implementation used by xzgv for scaling.

One problem with scaling up, given the way it's currently implemented, is that it's not well-suited to dithered display --- so if you're running on an 8-bit server, dragging the image around slowly when using scaling (especially scaling with interpolation) may result in some nasty, streaky, undithered-looking parts of the picture. :-(

You can undo the effect of scaling (up or down) at any time:

`n'

Normally, scaling up works by simply making the pixels into larger and larger squares (in effect), which remain the same colour. However, you can enable a feature called `interpolation' which smoothly graduates the colour change between the top-left corners of each pixel. This is very slow, but looks nice.

`i'

(If you like the appearance of scaling with interpolation, you may also be interested in a program I wrote called pnminterp, which can scale up a PGM or PPM file while applying this effect. These days it's part of the netpbm package.)

Scaling down, however, is implemented a bit like a special-case zoom mode, and currently there are no ways of making that look nicer. :-/

xzgv normally `reverts' scaling (returning the scale to 1:1) back to normal when you view a new picture. However, it's possible to disable this behaviour (see Viewer Options).

There is also support for an alternative form of scaling --- decoupled, or axis-specific, scaling. When you scale in this way, only one axis of the image is scaled at once. For example, you might choose to effectively double the height of an image (with the width left unchanged). Indeed, this sort of scaling is useful for temporarily correcting pictures intended for display using pixels twice as wide or high as normal.

`x'

`X (Shift-x)'

`Alt-x'

`Alt-Shift-x'

`y'

`Y (Shift-y)'

`Alt-y'

`Alt-Shift-y'

There are also mouse shortcuts for scaling up/down a single axis; control-left-click scales up, and control-right-click scales down. By default this acts on the y axis, but the active axis can be toggled with `Alt-c', or by toggling the `Ctl+Click Scales X Axis' option (see Viewer Options).

Interpolation is not currently supported in situations where the x scaling does not match the y scaling.

MIRROR AND ROTATE

Sometimes when viewing a picture you will want to flip it horizontally or vertically, or rotate it:

`m'

`f'

`r'

`R (Shift-r)'

`N (Shift-n)'

xzgv normally `reverts' the picture orientation (the way the picture has been transformed by mirror/flip/rotate) back to normal when you view a new picture. However, it's possible to disable this (see Viewer Options), so that any new pictures are mirrored, flipped, and/or rotated in the same way.

CHANGING PICTURE

It's possible to go directly to the previous or next file (or tagged file) in the directory, or to tag a file, without having to pick the file from the file selector by hand. These commands are particularly useful when using xzgv from the keyboard, but there's also a notable mouse shortcut for moving to the next image.

`Space'

`b'

`Ctrl-Space'

`/'

`?'

HIDING THE SELECTOR

When running on small screens, or in a small window, it can get a bit annoying to lose viewer space by having the selector constantly displayed when you don't actually need it. The usual solution to this problem is to enable auto-hide mode. But what if some pictures you're viewing are small and some large? It can sometimes be nearly as annoying having the selector hidden to `make room for' a small picture which didn't need it. So for that reason, or perhaps if you just don't like auto-hide mode :-), you may prefer to leave auto-hide off and explicitly hide the selector when necessary:

`Z (shift-z)'

You can also hide or unhide the selector by middle-clicking on the viewer.

MINIMIZING XZGV

Generally it's easy enough to use your window manager to change windows etc., but when running fullscreen this can sometimes be a little problematic. For this reason, xzgv has built-in support for `iconifying' itself:

`Ctrl-z'

VIEWER OPTIONS

As with the selector, various options can be disabled/enabled which relate to the viewer.

These settings can also be altered using command-line options (see Options) and/or config file settings (see Configuring xzgv).

`z'

`Alt-r'

`Alt-p'

`i'

`Alt-c'

`F (shift-f)'

`Viewer menu, Options, Revert Scaling For New Pic'

`Viewer menu, Options, Revert Orient. For New Pic'

`Viewer menu, Options, Use Exif Orientation'

FILE FORMATS

Picture files are stored in a variety of different forms, or `file formats'. xzgv, via gdk, supports many.

FILE TYPE IDENTIFICATION

The format a file is in is identified by its content. The file-reading code relies on libgdk to determine the file type and read the file correctly; generally this uses the format's `magic number' to determine file type --- e.g. a JPEG/JFIF file starts with the (hex) bytes `FF D8'. So if you start xzgv with xzgv foo, and foo is in a supported format (such as JPEG), the format will be figured out and the file loaded even though the `extension' is absent.

CONFIGURING XZGV

Many aspects of the way xzgv works can be modified by using a configuration file.

CONFIG FILES

A configuration file lets you alter aspects of xzgv's behaviour. xzgv supports two possible config files --- a system-wide one, /etc/xzgv.conf; and one for each user in their home directory, $HOME/.xzgvrc. Both are optional. If $HOME/.xzgvrc exists, it is used instead of /etc/xzgv.conf.

Before describing the format of config files, it may help to give an example file:

# Sample xzgv config file
# Comment lines begin with `#' and are ignored,
# as are blank lines.

# make pics fit window
zoom on
# hog the screen :-)
fullscreen on

It is a line-based format. Each line (or rather, each line which is not a comment line and is not blank) assigns a value to a single predefined `variable'. xzgv has many such variables it lets you modify in this way. For example, the fullscreen option above controls whether or not xzgv tries to use the whole screen for its window. If it is given the value `on'/`y'/`yes'/`1' it does; if `off'/`n'/`no'/`0', it doesn't. Most variables are of this yes-or-no `boolean' type.

Since the variables set in a config file have a direct effect on how xzgv works, it can be easier to simply call them `settings'. Indeed, such terminology is used on occasion in this documentation.

CONFIG VARIABLE TYPES

There are various types of variable:

- Boolean. These are on-or-off, yes-or-no variables. Most of xzgv's config file variables are of this type.

- Integer. These are whole numbers. The meaning of the number depends on what the variable is used for.

- Geometry. This window size-and/or-position specification format is only used for the `geometry' setting. See Options, for a description of how this type works.

CONFIG VARIABLES

Currently, most configuration variables (settings) in xzgv can also be set by command-line options; indeed, the name of the setting in all such cases is identical to that for the long version of the option (e.g. `fullscreen', `auto-hide'). As such, they're documented in the section which discusses command-line options and the like (see Options).

However, there are some settings only available in the config file:

click-for-next

RATIONALE

Here I (RJM) attempt to explain why I did things the way I did. This is presented in a question-and-answer format of sorts.

WHY YET ANOTHER VIEWER?

Previously, this section concentrated on xv; that may have made sense when I originally wrote it, and still makes a certain limited amount of sense for zgv, but for xzgv it was looking increasingly dated. And so here I am writing an update. :-)

I originally wrote xzgv as I simply wasn't happy with the viewers for X that I was aware of at the time (mid-1999). At the time of writing (late 2000), other key things about xzgv are becoming apparent, partly through responses I've been getting to it:

o It's `fast'. No, it doesn't do any particular operation faster than other viewers as far as I know (well, maybe thumbnail updates :-)); rather, the interface tries not to get in your way. Click on a filename, and the picture appears. No multiplicity of toolbars or windows, it's just there.

o As with zgv, it tries to do one thing well, viewing pictures. It isn't perfect in this regard, I'll admit, but at least it stays well clear of picture editing.

o It's, er, quite a lot like zgv. Some of us old fogies like this. :-)

I won't pretend xzgv is The Ultimate Viewer For Everyone. Some people will prefer other approaches, or just simply prefer other viewers. (Some people may even still use xv, ghod forbid.) There are a few viewers which you may like to try if you don't think much of xzgv:

o gqview. This seems to be well-regarded. I find it a bit gimmicky and kitchen-sink-ish; not quite as `pure' or focused as xzgv, IMHO. I think more people use it than xzgv though.

o xli. I'm not sure if this is maintained these days, but it's not too bad a viewer. No thumbnails or file selector though. (These days I mostly use this for setting the root window pixmap, something I don't think belongs in a viewer, but which xli does happen to be quite good at.)

o qiv. If I read between the lines correctly, this is essentially a modern replacement for xli.

o gtksee. I've not tried this, but I think the idea is that it's an ACDSee clone, and there seem to be an awful lot of people who want a clone of that. Which is their problem. :^)

o Electric Eyes. To be honest, I think this has been outclassed by other viewers these days, which shows how far we've come.

Ah, you say, what of xv? Well, we've emphatically reached the point where no-one need use xv any more. Anyone using xv these days really should drop that pile of ill-conceived non-Free crap and use one of the better viewers now available. It's that simple.

WHY NO IMAGE-EDITING CAPABILITIES?

It's a fscking viewer, dammit. If you want xv you know where to find it.

(OTOH, if you want a decent image editor, use the Gimp.)

WHY A TEXINFO MANUAL?

For years, I maintained a conventional `man page' for zgv (which xzgv was loosely based on). But over time, I realised just how impossibly confusing the zgv man page had become.

So I wanted to rewrite zgv's documentation in a more sensible way, in some other format than a man page. I wanted an established, well-supported format with structure and cross-referencing. I felt this made it a choice between HTML and texinfo. HTML seemed to me to be a moving target like no other, and not as well supported on text-only terminals as Info (and thus texinfo). (This latter point is admittedly not too relevant as far as xzgv is concerned.) When I noticed that a converter existed to convert texinfo to HTML in any case, the case was closed. xzgv's documentation was then based on zgv's --- the documentation is probably more similar than the programs are. :-)

Don't get me wrong --- I like man pages. And even with the excellent Texinfo documentation and Emacs' very helpful Texinfo mode, writing texinfo is hardly easy. (Without Texinfo mode's node- and menu-update commands, I personally would find it near-impossible!) But big man pages just aren't that good for reference, and this is made worse by the relative lack of structure.

WHY ONE-SPACE SENTENCE ENDS?

The conventional way to write texinfo is to follow each sentence with two spaces after the dot (or whatever ends the sentence). Many people normally write this way in a non-texinfo context too. But a sizeable proportion of people normally write text with only one space after the dot --- and I'm one of them.

The Texinfo documentation gives the impression that two-space must be used; it says ``it is important to put two spaces at the end of sentences in Texinfo documents.'' But the only circumstance in which spacing from the texinfo file is preserved at all (in any sense other than `there is a space here') is when the texinfo is converted to Info format. So, in fact, the decision to use two-space depends on how the author wants Info output to appear --- this is a subjective decision which should be entirely down to the preference of the author, despite the Texinfo documentation's attempt to make two-space sound like an objective you-must-do-this kind of thing.

You might wonder what the problem with using one-space is, then. Well, `makeinfo' has to reformat paragraphs, and whenever it needs to insert space at (what appears to it to be) the end of a sentence, it inserts two spaces. This behaviour cannot be altered, unlike in Emacs (sentence-end-double-space; see Fill Commands in the emacs info file) and GNU fmt (-u; see fmt invocation in the textutils info file). Also, attempting to `fix' the output Info with sed doesn't work properly because the `tags' used to find nodes quickly are then incorrect. These could of course also be fixed, but this would involve a lot more work than a simple sed invocation.

So realistically, anyone who writes texinfo with one-space has to put up with the occasional two-space sentence end being inserted into their text --- worse still, the current `makeinfo' formatting algorithm seems to insert two spaces even after abbreviations (such as `e.g.' and `etc.'), which breaks even two-space texinfo. (This is particularly ironic, by the way, since two-space partisans' main argument in favour of the practice is often the way it makes it possible to tell the difference between abbreviations and the end of a sentence.)

One last point may be worth noting; I am not the first person to write texinfo files using one-space. At the time of writing, it is used in the texinfo documentation for BFD, gdbm, GTK/GDK, (Linux) IPC, and viper, and I expect there are instances I'm not aware of.

BUGS AND RESTRICTIONS

All (non-trivial) programs have bugs. Anyone who denies this...

- clearly hasn't written too many programs.

- is wrong. ;-)

It follows that xzgv, like everything else, always has some bugs. Usually these are not too serious, or I'd have fixed them before releasing xzgv. But either way, bugs and other problems with xzgv are noted here.

KNOWN BUGS

- In zoom mode, it copes with resizing the window as a whole, but doesn't when you change the size of the pane (apart from when hiding/showing selector or resizing from keyboard, but that's only 'cos I kludged it :-)).

- When scaling up and dithering, you end up with a crappy-looking picture if you drag the picture around slowly (since each exposed bit is dithered independently, with no regard given to matching up to any previous error-diffusion).

- Scaling up is slow. Not sure if I can do much about this.

- Using an alignment widget to centre the viewer window results in some annoying `bounce' in certain resizing situations etc.

- Thumbnails don't look so great in palette-based (e.g. 8-bit) modes.

- When dragging an image around, if you quickly move the mouse pointer over from the image area to the selector area, the image seems to `jump' a little. I think this may have something to do with the paned window's window-splitting bit, but I'm not sure. Also, it jumps when moving across scrollbar sliders and the paned window splitter handle.

- It doesn't apply any tranparency mask. The practical result of this seems to be purple transparent bits in thumbnails and scaled-up images, and black transparent bits elsewhere. This doesn't affect PNG files, though.

- If a GIF file is corrupted in such a way that the decompressed image has a larger number of pixels in it, the extra pixels will be ignored and no error or warning will be generated.

- If you look up `joe code' in a dictionary, right next to ``see zgv'' it now says ``but for really in-depth insight into the joe code nature, see xzgv''. :-)

SUBOPTIMAL FEATURES

- Thumbnails are given an accurate width/height `IMGINFO' comment, but are always claimed to be "RGB".

- xzgv doesn't duplicate zgv's behaviour of generating thumbnails under ~/.xvpics/_foo_bar_baz if it can't generate them in /foo/bar/baz/.xvpics. I doubt anything else supported it, and it complicated lots of things unnecessarily. This isn't particularly suboptimal, but as an incompatibility with zgv it merits mention.

RESTRICTIONS

- Only the first image of a multiple-image GIF is used. (These days, multiple-image GIFs are usually animations.)

REPORTING BUGS

If you find xzgv does something wrong, which you suspect might be a fault of some sort (a bug) in the program, it is best to report it as I may not be aware of the problem. (But first, check it is not a `known bug'. See Known Bugs. It is not usually helpful to report a bug I already know about.)

It is important to include as much detail in a bug report as you can. Here are some details you should include:

o The version of xzgv you are running. `xzgv --version' reports this.

o The versions of GTK+ you are using. `xzgv --version-gtk' reports the GTK+ version being used by xzgv.

o The bitdepth your X server is running in (common depths are 16-bit, 24-bit, and 32-bit). If you don't know what depth you're running in, try `xdpyinfo|grep depth'.

o A description of the bug --- what effects it has, the circumstances it occurs in, and so on. Does it only happen for certain types of file? Only when in 8-bit modes? Only when dithering is enabled? Even `irrelevant' details can sometimes be useful.

o Finally, if you are a programmer and believe you have managed to fix the bug yourself, patches are gratefully accepted. :-) You should generate the patch using `diff -c' or (preferably) `diff -u'.

Then, please file a bug report in the SourceForge bug tracker. See https://sourceforge.net/p/xzgv.

REPORTING DOCUMENTATION BUGS

Bugs in the documentation can sometimes cause as much trouble as bugs in the program; if you notice a problem in the documentation, it's a good idea to report it.

For reports of documentation bugs, you should include these details:

o The version of xzgv the documentation is for.

o If it is a problem in one specific section of the documentation, specify which part it is (by this I mean the heading it comes under; texinfophiles should read this as `the node name' :-)).

o The format of the documentation you saw the problem in (e.g. info, man page, HTML).

o A description of the problem.

FUTURE CHANGES

See Reporting Bugs, for details of where to send the bug report. If you want to suggest a feature you'd like in xzgv, or a change to an existing feature, contact me; see See Reporting Bugs for the address.

Future changes etc. are listed in the TODO file.

AUTHOR

Russell Marks <rus@svgalib.org> and others; see the section ACKNOWLEDGEMENTS for details.

SEE ALSO

zgv(1), xv(1), cjpeg(1), djpeg(1), pbm(5), pgm(5), ppm(5), mrf(5)