Apply patches collected by Greg Roelofs about xv

[DavidGriffith]

xv-20040426-joe-zbiciak-rh7.3-bad-libpng.msg

The versions of libpng discussed are long obsolete. Leaving as-is

Greg,

One last rapid-fire email:

The LibPNG that comes with RedHat 7.3 doesn't seem to work well w/
XV 3.10a. I tried building xvicons for a directory full of images and
XV died with malloc failure in LoadPNG. I rebuilt/relinked against
a different LibPNG I installed when I upgraded GIMP and all was well.
(Since I'm not root on this system, the other LibPNG is in a separate
directory away from the system LibPNG.)

FWIW, the bad LibPNG is:

$ rpm -q libpng
libpng-1.0.14-0.7x.4

The working LibPNG is 1.2.5.

[DavidGriffith]

xv-20040525-jean-pierre-demailly-startgrab-imake-hips.patch

Adds a "-startgrab" option and adds support for an obscure format called HIPS. These additions made it into the 2007 Jumbo Patch. Also edits Imakefile to disable by default the included jpeg and tiff libraries. That did not make it into the Jumbo Patch. Frankly, it would be best to not do anything with imake anymore.

[DavidGriffith]

xv-20040602-walter-harms-suse-rpm-specfile.msg

Specfile stuff for making RPMs. Not relevant. At least not anymore.

[DavidGriffith]

xv-20041004-bruno-rohee-bmp-16bit-openbsd.patch.msg

References http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/graphics/xv/patches/Attic/patch-xvbmp_c which adds 16-bit support for BMP image files.

Incorporated into the 2007 Jumbo Patch.

[DavidGriffith]

xv-20050422-joe-zonker-brockmeier-response-from-john-bradley.msg

Commentary on correspondence from John Bradley.

[DavidGriffith]

xv-20050601-jim-r-kirkpatrick-xvmisc.c-statement-not-reached.msg

Something about "statement not reached" in xvmisc.c.

[DavidGriffith]

xv-20070625-thomas-klausner-bsd-compilation-issues.msg

Compilation problems with BSD. Fixes apparently in the 2007 Jumbo Patch.

[DavidGriffith]

xv-20070711-fabian-greffrath-binaries-in-patch.msg

Something about avoiding binaries in the Jumbo Patch. Probably nothing done with this.

[DavidGriffith]

xv-20071013-ross-combs-resize-ppos-paste.msg
xv-20071013-ross-combs-resize-ppos-paste.patch

Mentions xvselect.c, but the patch doesn't add it. Indeed, Greg doesn't seem to know where it is.

DID NOT appear in 2007 Jumbo Patch

• Patch to allow resizing of control and save/load windows.
• Middle-click paste support in the file selection box.
• Use of memcpy when memory doesn't overlap (slight speedup)
• Fix many cases where NULL was used in place of None
• some style stuff - whitespace, 0 -> FALSE, etc.

TODO

• Resize flickers because we don't use bit_gravity and smart redraws
• No select or copy support
• Try transient, group, and popup hints to see if placement can be made to work nicely everywhere without an option

I found the missing file. See Issue #8.

[DavidGriffith]

xv-20071016-lukacs-arpad-gcc-4.x-lvalues-fix.patch

Small patch to address problems about "generalized lvalues" being used in a way that was legal for gcc 3.x, but not 4.x. The problem seems to have been fixed by the time the 2007 Jumbo Patch came out.

[DavidGriffith]

xv-20071211-l-gabriel-somlo-response-from-john-bradley.msg

Commentary on correspondence from John Bradley.

[DavidGriffith]

xv-20080118-ian-collier-crash-fixes.msg

• "xv -root -quit foo.jpg" succeeds but always prints a BadWindow error message.
• crash when clicking around in the filename box for load/save windows.

Incorporated into the 2007 Jumbo Patch

[DavidGriffith]

xv-20080506-joe-peterson-wait-CLK_TCK-fix.dif

Use of CLK_TCK is obsolete as of POSIX.1-1996. This causes problems when using -wait.

NOT APPLIED

It probably should be added, though I want to know how this would affect machines that don't honor POSIX.1-1996.

Applied in 25683ef

[DavidGriffith]

xv-20080616-joe-peterson-makefile-LDFLAGS-to-linker.msg

Stuff about making sure that $(LDFLAGS) are on link lines in the Makefile. Mentions Gentoo patches which may be found here: https://gitweb.gentoo.org/repo/gentoo.git/tree/media-gfx/xv/files

Applied in 94fda99

[DavidGriffith]

xv-20080901-david-bath-empty-filename-save-crash-fix.dif

Offers a patch to fix the same problem reported in xv-20080118-ian-collier-crash-fixes.msg. Ian's patch was the one accepted into the 2007 Jumbo Patch.

[DavidGriffith]

xv-20081204-fabian-greffrath-icon.xpm
xv-20081204-fabian-greffrath-pixmap-manpage-bugs.mime

Suggestion to include the supplied .xpm file for use as an icon. A later version of this appeared in the official Debian package.

[DavidGriffith]

xv-20081205-niklas-edmundsson-filename-buffersize-fix.patch
xv-20081205-niklas-edmundsson-filename-buffersize-fix.patch.mime

Fix some filename path length limits.

Applied in af2a432a106a20d9b6a5f41d46ac927bb3f0cd39

[DavidGriffith]

xv-20081211.klaus-ethgen-msg.pgp.txt

Some unknown PGP message.

[DavidGriffith]

xv-20081213-anthony-thyssen-slideshow-pause.dif

Press 'w' to pause a slide show started with the -wait N flag.

Applied in 61a5d4f

[DavidGriffith]

xv-20081215-fabian-greffrath-xv.desktop.mime

Dear Greg,

it's me again. I have created a xv.desktop file which should be
installed in /usr/share/applications for XV to appear in the start
menus of GNOME and KDE. The list of supported Mime-Types isn't
exhaustive, but I think it covers the most important formats.

This file found its way into Debian's additions.

[Desktop Entry]
Type=Application
Name=XV
Comment=An interactive image manipulation program
Icon=xv
TryExec=xv
Exec=xv %F
Categories=Graphics;RasterGraphics;Viewer;
MimeType=image/gif;image/jpeg;image/tiff;image/postscript;image/x-portable-bitmap;image/x-portable-graymap;image/x-portable-pixmap;image/x-xbitmap;image/x-xpixmap;image/x-ms-bmp;image/cmu-raster;image/x-rgb;image/targa;image/fits;image/png;image/pm;

[DavidGriffith]

xv-20081216-elmar-plischke-xviff-crash-fix.dif

Fixes a problem with with npixels being initialized inside a loop. BAD!

This one made it into a preliminary patch, xv-3.10a-enhancements.20070520-20081216.diff, which Greg has on his webpage at http://www.gregroelofs.com/greg_xv.html

[DavidGriffith]

xv-20081218-fabian-greffrath-01-cflags.patch

If there are C compiler options that must be used for proper compilation of certain files, do not include them in CFLAGS. Users expect to be able to specify CFLAGS freely themselves. Instead, arrange to pass the necessary options to the C compiler independently of CFLAGS, by writing them explicitly
in the compilation commands or by defining an implicit rule.

Applied in 6a8e511

[DavidGriffith]

xv-20081218-fabian-greffrath-02-shared-libjasper.patch

Link binaries against the shared libjasper by default.

A modern Linux system doesn't seem to care about this. I'll look at this later.

Not needed.

[DavidGriffith]

xv-20081218-fabian-greffrath-03-install-pixmap.patch

Like xv-20081204-fabian-greffrath-icon.xpm except more refined and Makefile support is added.

Applied in c11f232

[DavidGriffith]

xv-20081218-fabian-greffrath-04-install-desktop.patch

Like xv-20081215-fabian-greffrath-xv.desktop.mime except more refined and Makefile support is added.

Applied in 017ebc6

[DavidGriffith]

xv-20081218-fabian-greffrath-05-install-README.patch

Slight tweaks in how README files are installed.

Applied in 8066c34

[DavidGriffith]

xv-20081218-fabian-greffrath-06-hyphen-used-as-minus-sign.patch

Manual pages seem to contain a hyphen where a minus sign was intended.

Applied in c9b44fc

[DavidGriffith]

xv-20081218-fabian-greffrath-07-manpages-CFLAGS-etc.mime

All of the following mashed into one email:

xv-20081218-fabian-greffrath-01-cflags.patch
xv-20081218-fabian-greffrath-02-shared-libjasper.patch
xv-20081218-fabian-greffrath-03-install-pixmap.patch
xv-20081218-fabian-greffrath-04-install-desktop.patch
xv-20081218-fabian-greffrath-05-install-README.patch
xv-20081218-fabian-greffrath-06-hyphen-used-as-minus-sign.patch

[DavidGriffith]

xv-20081218-fabian-greffrath-patches-01-06.mime

duplicate of xv-20081218-fabian-greffrath-07-manpages-CFLAGS-etc.mime

[DavidGriffith]

xv-20081227-klaus-ethgen-own-jumbo-patches-in-git.msg

Discussion about maintaining patches in git.

[DavidGriffith]

xv-20090126-ignatios-souvatzis-xxx.msg.pgp.asc

Something encrypted with GPG.

[DavidGriffith]

xv-20090131-grr-C++-comments.where

Notes on possible overflows. See #12.

xv.c:    strcpy(fullname, namelist[filenum]);   // 1 of 2 places fullname != const
xv.c:    *tmp = '\0';                      // 2 of 2 places fullname != const


xvevent.c:      //fprintf(stderr, "RAC: orig window pos %d,%d\n", xwa.x, xwa.y);
xvevent.c:      //fprintf(stderr, "RAC: image size now %d,%d\n", xwa.width, xwa.height);
xvevent.c:      //fprintf(stderr, "RAC: moving window to %d,%d\n", xwa.x, xwa.y);


xvgif.c:          xv_mktemp(pinfo->pagebname, "xvpgXXXXXX"); // a.k.a. close(mkstemp())


xvhips.c://extern char *calloc();
xvhips.c:  pic = pinfo->pic = (byte *) malloc(h.rows * h.cols);   // GRR POSSIBLE OVERFLOW / FIXME


xvmag.c:    *pic0  = mag_malloc((size_t) mi->width * mi->height, "mag_expand_body#2");  // GRR POSSIBLE OVERFLOW / FIXME
xvmag.c:    pixel0 = mag_malloc((size_t) 2 * mi->p_width * 17, "mag_expand_body#3");  // GRR POSSIBLE OVERFLOW / FIXME
xvmag.c:    mag.a_size = (mag.p_width * mag.p_height + 15) / 16;        /* x/2/8 */   // GRR POSSIBLE OVERFLOW / FIXME
xvmag.c:    pixel0 = mag_malloc((size_t) 2 * mi->p_width * mi->p_height,  // GRR POSSIBLE OVERFLOW / FIXME
xvmag.c:    flag0 = mag_malloc((size_t) mi->p_width * mi->p_height,  // GRR POSSIBLE OVERFLOW / FIXME
xvmag.c:    mi->a = mag_malloc((size_t) mi->a_size, "mag_compress_data#4");   // GRR POSSIBLE OVERFLOW / FIXME


xvmaki.c:    mi->vs = maki_malloc((size_t) bpl * mi->height,  // GRR POSSIBLE OVERFLOW / FIXME
xvmaki.c:    *pic = maki_malloc((size_t) mi->width * mi->height,  // GRR POSSIBLE OVERFLOW / FIXME
xvmaki.c:    mi->forma = maki_malloc((size_t) mi->width / 2 * mi->height,  // GRR POSSIBLE OVERFLOW / FIXME
xvmaki.c:    mi->formb = maki_malloc((size_t) mi->width / 2 * mi->height,  // GRR POSSIBLE OVERFLOW / FIXME
xvmaki.c:    mi->vs = maki_malloc((size_t) bpl * mi->height,  // GRR POSSIBLE OVERFLOW / FIXME
xvmaki.c:    mi->fa = maki_malloc((size_t) bpl * mi->height, "maki_make_flags#1");  // GRR POSSIBLE OVERFLOW / FIXME


xvpi.c:    *pic = pi_malloc((size_t) max_cnt, "pi_expand");   // GRR POSSIBLE OVERFLOW / FIXME


xvpic.c:    pi->data = pic_malloc(sizeof(data32) * pi->width * pi->height,   // GRR POSSIBLE OVERFLOW / FIXME
xvpic.c:            *xp = pic_malloc((size_t) pi->width * pi->height * 2,   // GRR POSSIBLE OVERFLOW / FIXME
xvpic.c:            *xp = pic_malloc((size_t) pi->width * pi->height,   // GRR POSSIBLE OVERFLOW / FIXME
xvpic.c:        *xp = pic_malloc((size_t) pi->width * pi->height * 3,   // GRR POSSIBLE OVERFLOW / FIXME
xvpic.c:    pi->data = pic_malloc(sizeof(data32) * pi->width * pi->height,   // GRR POSSIBLE OVERFLOW / FIXME


xvpic2.c:       *xp = pic2_new((size_t) pi->x_max * pi->y_max * 3, "pic2_make_xvpic");   // GRR POSSIBLE OVERFLOW / FIXME
xvpic2.c:    p = pi->buf = (byte *) pic2_new((wid + 8) * sizeof(pixel) * 3   // GRR POSSIBLE OVERFLOW / FIXME


xvpng.c:// GRR FIXME:  add .Xdefaults option to omit writing gamma (size, cumulative errors when editing)--alternatively, modify save box to include "omit" checkbox
xvpng.c:      //fprintf(stderr, "Disabling MMX read support for combining rows.\n");
xvpng.c:      //fprintf(stderr, "Disabling MMX read support for expanding interlacing.\n");
xvpng.c:      //fprintf(stderr, "Disabling MMX read support for decoding row-filters.\n");


xvtiff.c:#endif // USE_LIBJPEG_FOR_TIFF_YCbCr_RGB_CONVERSION

[DavidGriffith]

xv-20090322-jan-fuchs-CLOCKS_PER_SEC-vs-USE_TICKS.msg

Hi Greg,
on Linux non-functionality option -wait.

Solution:

 - on xv.h destroy USE_TICKS

Detail:

 - on Linux system use XV from timing function times(NULL) and
   sleep(1), POSIX requires that CLOCKS_PER_SEC equals 1000000
   independent of the actual resolution, but between call times()
   equals 100

I'm not sure what the problem is. The -wait option works fine with Debian Stretch.

Applied a different patch.

[DavidGriffith]

xv-20090426-lluis-perez-vidal-c++-comments-and-makefile.patch.mime

Assorted minor cosmetic changes. Of these, I picked some comment character changing from C++ style to C.

Applied in 7f9785f

[DavidGriffith]

xv-20090826-paul-howarth-warnings-and-JP-FLmask.patch.mime

Addresses dubious type conversions, typically of int versus unsigned int. Also include FLmask filter additions. The latter is being addressed separately in Issue #3.

Applied in 93da0c1

[DavidGriffith]

xv-20090907-patrick-keshishian-CMYK-JPEG-crash-fix.patch
xv-20090907-patrick-keshishian-CMYK-JPEG-crash-fix.patch.mime
xv-20090912-patrick-keshishian-CMYK-JPEG-crash-test-case.jpg
xv-20090912-patrick-keshishian-CMYK-JPEG-crash-test-case.jpg.mime

I came across a CMYK JPEG file that caused xv to crash. It appears
that the error was introduced by one of the patches in the "jumbo" xv
patch to xvjpeg.c file.

Attached trivial patch fixes this crash.

The provided image file that's supposed to trigger this bug doesn't cause trouble on my machine. Maybe it's a 32-bitness versus 64-bitness problem.

Applied in 4264f83

[DavidGriffith]

xv-20091212-patrick-keshishian-bmp-negative-height.patch.mime
xv-20091217-patrick-keshishian-bmp-negative-height.patch.mime
xv-20100405-patrick-keshishian-negative-height-sample.bmp.mime

From http://en.wikipedia.org/wiki/BMP_file_format

Uncompressed Windows bitmaps can also be stored from the top row to the bottom, if the image > height value is negative.

The patch works on the 30k test file provided. Here is the header:

00000000   42 4D 68 75  00 00 00 00  00 00 36 00  00 00 28 00  BMhu......6...(.
00000010   00 00 64 00  00 00 9C FF  FF FF 01 00  18 00 00 00  ..d.............
00000020   00 00 32 75  00 00 12 0B  00 00 12 0B  00 00 00 00  ..2u............
00000030   00 00 00 00  00 00 FF FF  FF FF FF FF  FF FF FF FF  ................
00000040   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  ................
00000050   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  ................
00000060   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  ................
00000070   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  ................
00000080   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  ................
00000090   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  ................
000000A0   FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  ................

$ file negheight_test_cs3.bmp 
PC bitmap, Windows 3.x format, 100 x -100 x 24

I found another, much smaller, test image at https://issues.apache.org/jira/browse/IMAGING-162. Even with the patch, xv doesn't like it.

Here's the whole file (cannot attach bmp files to Github issues):

begin 644 monochrome-negative-height.bmp
M0DVB`````````((```!L````!````/C___\!``$``````"`````3"P``$PL`
M``(````"````0D=2<P``````````````````````````````````````````
M``````````````````````(```````````````````#___\`````````````
;```````````````0````(````$````"`````
`
end

This is the entire hexdump of the file:

00000000   42 4D A2 00  00 00 00 00  00 00 82 00  00 00 6C 00  BM............l.
00000010   00 00 04 00  00 00 F8 FF  FF FF 01 00  01 00 00 00  ................
00000020   00 00 20 00  00 00 13 0B  00 00 13 0B  00 00 02 00  .. .............
00000030   00 00 02 00  00 00 42 47  52 73 00 00  00 00 00 00  ......BGRs......
00000040   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000050   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000060   00 00 00 00  00 00 00 00  00 00 02 00  00 00 00 00  ................
00000070   00 00 00 00  00 00 00 00  00 00 FF FF  FF 00 00 00  ................
00000080   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000090   00 00 10 00  00 00 20 00  00 00 40 00  00 00 80 00  ...... ...@.....
000000A0   00 00                                               ..

file monochrome-negative-height.bmp
monochrome-negative-height.bmp: PC bitmap, Windows 95/NT4 and newer format, 4 x -8 x 1

So... it appears that the patch is deficient in handling newer-format .bmp files. See #5.

Applied in 564e566

[DavidGriffith]

xv-20091215-werner-fink-multiple-fixes.patch.mime

for the jumbo patch 20070520 (not for the enhancements 20081216)
I've a few patches.

First of all without reverting the patch for xvxwd.c I've made
that the version from 20070520 simply works.

From Greg:

He's fixing something. Here's the context:

20070428
modified install to include README.jumbo in docs (GRR); incorporated PNG
no-stdio patch (SBM); fixed XWD endianness support, improved performance
(replaces SJT 16/24-bit fix) (SBM)
- xv-scott-marovich-20070214-xvpng.diff
- xv-scott-marovich-20070214-xvxwd.c.patch

20081205
reverted xvxwd.c to SJT's version (bug reported by Jari Ruusu)

So presumably xv-scott-marovich-20070214-xvxwd.c.patch could go back in with Werner's fix. (I never use .xwd format, so I honestly don't care that much, but if SBM's changes improved the performance a fair bit, then that's probably a good way to go.)

Clarification from Greg. First is my question:

I don't have the file "xv-scott-marovich-20070214-xvxwd.c.patch". Is the
patch contained in "xv-3.10a-enhancements.20070520-20081216.diff"?

No, all of the entries before 20070520 are already in the last jumbo patch.
I would have guessed they're also in one of the DONE.* subdirs I sent you,
but maybe that's only the post-20070520 set.

Then within xvmisc.c not only the png X Window is destroyed
twice but also the Cursor is defined twice a time.

Applied in 6f54969

For new Xorg libraries the third patch corrects the signal
handling.

Applied in a1d499e

The patch number four uses the correct tick definition of the
system instead of a hard defined value. In fact CLK_TCK isn't
defined anymore on newer Linux systems as it now becomes
variable at boot time.

Applied in 25683ef

See #6 for concerns about backwards compatibility.

The next patch avoid buffer overflows in bmp and pbm driver.

Applied in ce5432f

The sixth patch corrects the behaviour of the jpeg8 driver
as within the jpeg library the numbers of out_color_components
and color_components are diffenrent for quantize_colors, that
is that color_components is the colormap (normally 1).

Applied in 454f7f2

[DavidGriffith]

xv-20100225-jpeg-segfault-bug-test-case.notes

/home/roelofs/bin/xv-20090201 /home/roelofs/dl/JUNK/cdr1/images/linux/lwn.net-andrew-morton-matt-mackall-dave-neary-jonathan-corbet-angela-brown-on-GreatWall-2008-Beijing-Linux-Developer-Symposium-China.jpg

Segmentation fault

[regular-size image; 20070520 version displays just fine; no clue...]
[oh...maybe exceeded filename buffer? > 160 chars long...]

It looks like the problem this one describes was fixed by xv-20081205-niklas-edmundsson-filename-buffersize-fix.patch.

[DavidGriffith]

xv-20100228-anthony-thyssen-window-geometry-pos-drift.patch

The XV program is great, but its complex handling of position for some
window managers requiring the use of -drift to try and stop it slowly
drifting is ridiculous.

This very very small patch records a user defined position (given in
-geometry) and always places the window in that position unless the
window becomes too big. When the window shrinks it RETURNS to the
given user defined position. no drift or other things needed.

It only works if a -geometry is given, and is a hack in that the
position can not be changed. But this if users set a -geometry
do they really want the XV window to move or drift around?

Basically it WORKS especially for slide shows type needs.

Really the whole positioning stuff needs to just be re-written and
simplified!

The way this works is worse than simply leaving the problem alone.

[DavidGriffith]

xv-20100206-niklas-edmundsson-filename-buffersize-fix2.patch
xv-20100206-niklas-edmundsson-filename-buffersize-fix2.patch.mime

This patch is a restatement of these two others, plus an sprintf() versus snprintf() safety fix.
xv-20081205-niklas-edmundsson-filename-buffersize-fix.patch
xv-20100225-jpeg-segfault-bug-test-case.notes

Applied in 13d2926

[DavidGriffith]

xv-20100523-markku-savela-wheelmouse-request.msg

Hi,

As a long time user of 'xv', I once again found myself in a situation
where I had to rebuild the program, and had a hard time getting all
changes. Then I got to your

http://www.gregroelofs.com/greg_xv.html

Great work! Thanks! Got at least partially satisfactory version working
on Ubuntu.

However, I've been previously been using a version where the scroll
button can be used to flip images, and have became addicted to this
feature. Maybe one of the patches

KS = Kyoichiro Suda (http://www.coara.or.jp/~sudakyo/XV_jp.html)

..but, that page is either gone (hard to tell without japanese
knowledge) or moved. I hope these patches are still saved somewhere? (I
may have some patched source somewhere, but for now I'm away from home
for 3 months and can't check it).

Just a vote for getting those included into next jumbo patch...

I tracked this patch down to http://www.seanborman.com/software/xvwheelmouse.html

It turns out that this referenced patch made it into the 2007 Jumbo Patch. Neither this nor the Jumbo Patch are capable of making the scroll wheel flip images.

[DavidGriffith]

xv-20100523-ville-saari-clipboard-colormap-fix.dif

Hi. I discovered your excellent jumbo patch for xv. I had been maintaining
similar combined patch file for my own use for many years, but it only
consisted of the patches found on the official xv site and some of my own
fixes. Your set is much more complete and it even contained some fixes
to same bugs I had had to fix myself.

But there's one xv bug I had fixed that's not fixed in your patch. If you
cut or copy parts of the image in 24 bit mode and the selected area contains
256 distinct colors or less, the copied image in clipboard will be corrupted.
This is because of an off-by-one error in colormap indexing.

My fix to this bug is attached so you can add it to your jumbo patch if
you wish. It is diffed against a version with your jumbo patch already
applied.

Not only will the copied image be corrupted, the whole program can freeze up.

Applied in d43d02e

[DavidGriffith]

xv-20100811-eeri-kask-nopos-window-placement-fix.patch

may I send you a patch to minorly tweak 'xv' attempting to make the
'nopos' parameter, if set, for window placement kind of work: don't
set the PPosition/USPosition window hints, which leads to

(1) respect the hard-wired placing by 'xv' if no window manager is
running; and

(2) let the window manager do the placement if one is running.

I'll send this improvement to you in the hope you might be interested...

P.S. Reading the code and observing the behaviour it was not quite
clear how the 'nopos' feature was intended to work, so I created
this small tweak. :-)

Applied in 6cbe040

[DavidGriffith]

xv-20110523-patrick-keshishian-openbsd-segfault-fix.msg

Memory access is more sensitive in OpenBSD than many other Unices. That's why this off-by-one bug causes a crash when running on OpenBSD, but not elsewhere.

From http://marc.info/?l=openbsd-ports&m=130613524414672&w=2:

Attached patch fixes crash in xv in smoothY(). The for()-loop iterates
one too many times, and make clptr to point to out-of-bound memory,
and later, cptr is assigned based on clptr (line 393) and causes a
crash when dereferenced (line 398).

Test image[1] from post[2] with following command on my 1366x768
display (on amd64):

$ xv -rmode 5 -quit -max openbsd.jpg

The patch also fixes another for(i=0; i <=shigh; i++) case in
smoothXY() (line 471). I don't have a test-case for this, but visually
looks wrong.
[1] http://openbsd-france.org/goodies/wallpapers/openbsd.jpg
[2] http://marc.info/?l=openbsd-misc&m=130608796413023&w=2

Applied in b91710b

[DavidGriffith]

xv-20110615-fabian-greffrath-libpng15-compile.msg

This is a report that xv will not compile with libpng version 1.5. I've already reported this problem in Issue #1 and fixed it with 98a60d4.

[DavidGriffith]

xv-20120505-ross-combs-middle-button-paste.mime
xv-20120507-ross-combs-middle-button-paste.mime

The second of these is an update of the first. The patch is quite large and so I've started Issue #8 for it.

[DavidGriffith]

xv-20130213-hints-for-macosx-snow-leopard.msgs

This has to do with compiling a separate xv-related program: vdcomp, which is contained entirely in the file vdcomp.c. It has to do with a bunch of ifdefs used to figure out the correct location of malloc.h. There are two choices: <sys/malloc.h> or <malloc.h>.

Greg concludes that the block of ifdefs can be deleted because xv manages to get it right without such a long block. Never mind that modern Unices define malloc() and friends in
stdlib.h.

Applied in 7b65fd6

[DavidGriffith]

xv-20130314-gabriel-somlo-NAME_MAX-buffer-overrun-fix.dif
xv-20130328-gabriel-somlo-NAME_MAX-buffer-overrun-fix2.mark-brader-cut-paste-fix.dif

These two change some more filename strings from [256] to [NAME_MAX] in the fashion of xv-20081205-niklas-edmundsson-filename-buffersize-fix.patch. There's also a patch for what was fixed in xv-20100523-ville-saari-clipboard-colormap-fix.dif, but was done differently. Some of what's done here looks better than what was presented earlier, so I'll cherry-pick some stuff to use.

Applied in 7283ce8

[DavidGriffith]

xv-20140327-mark-brader-24bit-autocrop-bug.msg

This is a longstanding bug in xv's AutoCrop function, which is
documented as follows:

# Crops off any constant-color borders that exist in the image.
# It will crop to the smallest rectangle that encloses the
# 'interesting' section of the image. It may not always appear
# to work because of minor invisible color changes in the image.
# As such, it works best on computer-generated images, and not as
# well on scanned images. In an attempt to get around this problem,
# if you AutoCrop while in 24-bit Mode, it will crop off portions
# that change by a little bit, not just portions that are exactly
# the same. Not that it works all that well.

Attached is a reduced copy of a photo that I took a few months ago.
If you open this in xv and press C for AutoCrop, it crops away the
entire sign and just leaves a narrow strip at the bottom of the photo.

AutoCrop is reliable on 8-bit images, but on 24-bit ones this sort of
overcropping happens fairly often. I have now figured out why.

If you look at the function doAutoCrop24() in xvimage.c, you will see
these macros:

# define EPSILON 39 /* up to 15% (39/256ths) variance okay /
# define NEIGHBOR 16 / within 6% of neighboring pixels /
# define MISSPCT 6 / and up to 6% that don't match */
# define inabsrange(a,n) ( (a) < n && (a) > -n )

and then a four successive loops, one for each side of the image.
In each case the body of the inner loop reads:

  r=3Dcp1[0]-bgR;  g=3Dcp1[1]-bgG;  b=3Dcp1[2]-bgB;
  R=3Dcp1[0]-oldr; G=3Dcp1[1]-oldg; B=3Dcp1[2]-oldb;
  if (!inabsrange(r-g, EPSILON) ||
      !inabsrange(r-b, EPSILON) ||
      !inabsrange(b-g, EPSILON) ||
      !inabsrange(R-G, NEIGHBOR) ||
      !inabsrange(R-B, NEIGHBOR) ||
      !inabsrange(B-G, NEIGHBOR)) misses++;

This is comparing three colors each expressed in RGB style: the current
point (cp[0], cp[1], cp[2]), the presumed background color (bgR, bgG, bgB),
and a nearby point (oldr, oldg, oldb).

It sets the three variables (r,g,b) equal to, not a color as the names
might suggest, but the color DIFFERENCE between the current point and
the presumed background color. And similarly it sets (R,G,B) to the
color DIFFERENCE between the current point and the nearby point.

So far so good. But then what happens? It doesn't test the three
elements (r,g,b) of those color differences against the thresholds;
instead it SUBTRACTS THEM PAIRWISE FROM EACH OTHER and compares
THOSE numbers against the thresholds.

This makes no sense -- what it is testing is not the closeness of the
colors to each other, but the direction in the RGB color cube the line
joining them. In fact, it means that black will compare equal to white!
Which is obviously what happened with my sample image.

The if-condition, in all four cases, should simply read:

  if (!inabsrange(r, EPSILON) ||
      !inabsrange(g, EPSILON) ||
      !inabsrange(b, EPSILON) ||
      !inabsrange(R, NEIGHBOR) ||
      !inabsrange(G, NEIGHBOR) ||
      !inabsrange(B, NEIGHBOR)) misses++;

I have tested this on the sample image and a handful of others and it
seems to avoid the ghastly overcrops while successfully cropping where
there is a genuine solid-color background.

Please verify this, and have it distributed if you agree with me.

I must add, while I'm writing, that I think the thresholds in the
#defines are awfully loose. I understand the motivation as explained
in the document, but does the range really need to be as large as
15%, and is 6% of pixels not matching really acceptable? In practice,
since this feature has never worked properly because of the bug, I've
never made much use of it with 24-bit images, so I can't say that the
numbers are inferior, but I am suspicious of them. The other day
I tried autocropping an image containing a shield shape on a genuine
single-color background, and it happily cropped the pointed bottom
off the sheild.

Thanks for your attention.

Applied in f62b3fd

This fix doesn't entirely fix the problem, but seems a decent first step. Issue #9 has been opened for this problem.

[DavidGriffith]

xv-20140506-yann-ricquebourg--exitcode.patch

Patch of xv.c for exit-code:
xv was not really exiting with 0 for a valid call "xv -help"
since exit(0) was not reached

Applied in 24f230b

[DavidGriffith]

xv-20140506-yann-ricquebourg--newpng.patch

Libpng 1.5 update. I already did this in #1.

[DavidGriffith]

xv-20140603-fabian-greffrath--updated-Debian-redistrib-permission.msg

Reference to
http://anonscm.debian.org/gitweb/?p=collab-maint/xv.git;a=blob;f=debian/copyright;hb=HEAD#l110
on various files in xv and their distribution licenses.

[DavidGriffith]

xv-20150913-rainer-m-canavan--xrandr-support--webp-support.dif

i've written two patches for xv, one to add XrandR support (so that the xv window is not limited to the size of e.g. the builtin screen of a notebook after one plugs in an external screen), and one to add webp support. I've tested the webp patch on Linux and IRIX, and the XRandR one only on Linux, since there's no RandR on IRIX. If you ever release an updated Jumbo Patch, please consider including the patches below.

Applied XrandR support in a84406c

Applied webp support in 5682a07

[DavidGriffith]

xv--adobe-XMP--test-image--inspections_table_2013.png
xv--adobe-XMP--test-image--inspections_table_2013.where
xv--adobe-XMP--test-image--tumblr_mlqyn0H7A01qb3mfao1_250.png
xv--adobe-XMP--test-image--tumblr_mlqyn0H7A01qb3mfao1_250.where

URLs where to find some test images in PNG format and the test images themselves. These two files will cause xv to crash. Somehow I was able to load the first one.

Putting this into its own Issue #10.

[DavidGriffith]

xv-erling-jacobsen-20080225-smoothing-crash-fix.diff

Fixes off-by-one error that could cause crashes and uses a better way of interpolating/rounding that ensures, I think, that all the data will be taken into account when averaging pixels.

Applied in 72c80bf

[DavidGriffith]

xv-fabian-greffrath-20070215-debian-stuff.msgs

Stuff about some sort of permission John gave for allowing Debian to distribute xv.

[DavidGriffith]

xv-fabian-greffrath-20070814-cygwin-patch.msg

Cygwin compilation fixes.

Applied in 00c4789 with edits.

[DavidGriffith]

xv-fabian-greffrath-CFLAGS-fix2.diff
xv-fabian-greffrath-CFLAGS-fix.diff

Almost duplicate of xv-20081218-fabian-greffrath-01-cflags.patch.

Applied in 6a8e511

[DavidGriffith]

xv-greg-kriehn-20071214-fedora8-packaging.msg

Stuff about packaging xv for Fedora 8 and the patches Greg Kriehn has applied. I've applied the ones he's done.

[DavidGriffith]

xv-grr.dif.20070318.xvinfo-security-fix

Some snprintf() and vsnprintf() substitutions that have already been applied in another patch.

[DavidGriffith]

xv-jerome-ibanes-jpeg2000-2005-07-02T16-14-47-quality-100-truncate-eighth.jp2
xv-jerome-ibanes-jpeg2000-output.gif
xv-jerome-ibanes-jpeg2000-patches3.diff
xv-jerome-ibanes-jpeg2000-patches.diff
xv-jerome-ibanes-jpeg2000-patches.msg
xv-jerome-ibanes-jpeg2000-patches.sh

This looks like a fix for not being able to read the supplied test image. Unfortunately it was presented as a modification to a patch by Scott Marovich. I tried to tease out the modifications relevant to fixing jpg2k loading, but was not successful in getting something that works. Hopefully this will be fixed when the switch to OpenJPEG is complete in #2.

[DavidGriffith]

xv-joe-zbiciak-20070621-gif-decoder-bugfix.dif

It's an obscure bug that only occurs when your palette size is a power-of-2 size larger than your initial code length

Already in the 2007 Jumbo Patch.

[DavidGriffith]

xv-jpdemailly-20070904-g3-fax-patch.mime

Add G3 fax image read support. Write support might be nice to have. In the meantime, ImageMagick will do the job.

Applied in 473034f

[DavidGriffith]

xv-lukacs-arpad-gcc422-fix.dif

Duplicate of xv-20071016-lukacs-arpad-gcc-4.x-lvalues-fix.patch

[DavidGriffith]

xv-michal-maruska-no-flicker-bkgd.patch

Since the Image window is full of the image pixels, the window background
is not meant to be seen.... but it can make flicker, be seen for an instant,
when the window is exposed.

Applied in f9d46bd

[DavidGriffith]

xv-rcombs-resize-ppos-paste.diff
xv-rcombs-resize-ppos-paste.where

Appears to be duplicate of
xv-20071013-ross-combs-resize-ppos-paste.msg
xv-20071013-ross-combs-resize-ppos-paste.patch

Again, xvselect.c is missing.

Found xvselect.c. See Issue #8.

[DavidGriffith]

xv-scott-marovich-20070214-jpeg2000-stuff.msgs

The magic numbers for JP2 files can differ depending on the CPU's endianness. It's not clear to me how this is supposed to help. Part 1 JP2 files load fine without this patch. Part 2 JP2 files are still a problem. This might go hand-in-hand with the patches proposed by Jerome Ibanes earlier in this Issue.

See also Issue #11

[DavidGriffith]

xv-thomas-loimer-20070810-ubuntu-fixes.msg

Some fixes for Ubuntu 7.04 compilation. The problems described seem to be mostly fixed. I am committing some defines for TRUE and FALSE in xv.h in case they're not defined elsewhere.

in xv.h add the line (e.g., below line 10)
#define FALSE 0
(xvpopup.c, xvtext.c, xvxxpm.c, xvpds.c .. did not have FALSE defined)

Applied in 82808b7