Graphic tool Xnview version 2.40 produce instead 1028 a 1032 data size for 256colors like in palette-logos.pal. Such example was created by menu "Image","Edit Palette...", "Save...", "file type" and "Windows Palette"

That means some pal files contain some (4) extra bytes after colorvector. This is not logical but not explicitly forbidden by documentation.

At offset 4 riff size is stored as long value. Then the followingformula should be true: file size = riff size + 8 = data size + 12 + 8 But when we compare real size mentioned in output/ls-la.txt with calculatedbytes based on riff size in output/file.txt we see in Xnview generatedexamples like iEditor.pal real file size is 4 bytes lower. So two errors"equalize" each other. According to internal structures extra bytes should existhere, but the bytes does not exist because of lowered file size. Thisinconsistency in data apparently do not hurt, if software just reads number ofcolors, then calculate color vector size and then reads this vector.

Xnview also seems to generate pal files with 256 colors even if less colorsare used like in BWrgb.pal with 5 colors. But Xnview reads palette files withless colors like BlackWhite12.pal with just two colors.

I hope that somebody check these minor bugs and correct it.

I append an pal.zip archive with the examples , the output of ls and file(1) command.