Hello trid users,
some days ago i used a print copy utility on Windows. That can be found on
web site hardcopy.de. Per hot key the screen or parts of it can be directed
to printer or saved as file. On offered file formats one is called "X Window
Dump" with version "v10" or "v11".
When i run TrID on such examples these are described as "X-Windows Screen
Dump". The version 10 examples are described with additional "(X10)" by
definition xdm-x10.trid.xml and the others are described with additional
"(X11)" by xdm-x11.trid.xml (see appended output/trid-v-old.txt).
For comparison reason i also run the file format identification utility
DROID ( See
https://sourceforge.net/projects/droid/). This identifies all
examples as "X-Windows Screen Dump". The X10 examples are described with
version "X10" by PUID x-fmt/300 and the others with "X11" by PUID fmt/401
(See appended output/droid_xwd.csv).
For comparison reason i check these examples by file command utility. When
running file command (version 5.41) on such examples most X11 examples are
described correctly as "XWD X Window Dump image data", but some X11 examples
like MARBLES.XWD and hardcopy-x-window-v11.xwd are not recognized. All X10
variant examples are also not recognized and are described only as "data"
(See appended output/file-5.41.txt). The newest version now recognize now
all X11 and X10 variant examples. It also does not misidentify the DROID
examples fmt-401-signature-id-618.xwd and x-fmt-300-signature-id-619.xdm
(See appended output/file-k.txt).
But TrID reports no Related URL. Luckily with information given by the other
tools i also found a page about XWD on file formats archive team web
site. There also links for samples and C-header text are listed. That
information is expressed by line inside definitions by new line like:
<RefURL>
http://fileformats.archiveteam.org/wiki/XWD </RefURL>
On that site download links for examples and graphic tools are mentioned. I
verified information by ImageMagick identify (See appended
identify-verbose-xwd.txt, XnView command line tool nconvert (See appended
nconvert-xwd.txt) and xwud software (see xwud.txt) by command lines like:
identify -verbose *
nconvert -in xwd -info *
xwud -in fig41.wxd -dumpheader
gimp fig41.wxd
The first work with version 6.9.11 on raspbian 11, but not with version
7.1.0 on Windows 64-bit. None of the mentioned tools work 100%. Some refuse
to open or freeze on some examples, the displayed image is distorted or the
colors are wrong. What an annoyance with a file format known since decades.
For mime type all tools and documentations mention the same one, but for
suffix things become complicated. Because such images are first created by
X11 utility xwd, this 3 byte suffix is used as file name suffix.
In sample files section on file formats site we found also screen dump
images with 3 byte suffix dmp like betyboop.dmp or on stuff.mit.edu site in
compressed form hundreds of images like mandrill.dmp.Z. But nowhere else
this suffix is used or mentioned. This suffix is now listed by newest file
command (see appended output/file-k-ext.txt).
On some sites and also used by Xnview is the extension x11, but i myself do
not found such examples. TrID and DROID on the other hand mention also
extension XDM, but i found no such examples. TrID also list extension XDW,
but i believe this is a probably a misspelled XWD. So the 2 suffix mentioned
by TrID were expressed by line like:
<Ext>XDM/XWD</Ext>
So in xdm-x11.trid.xml this now becomes like:
<Ext>XDM/XWD/DMP/X11</Ext>
For X10 variant i found no samples with DMP extension. Samples with X11
extension are still accepted by XnView here, but i think this make no real
sense here. So mention this fact only in remark line. And extensions are now
expressed in xdm-x10.trid.xml by line like:
<Ext>XDM/XWD</Ext>
The example fmt-401-signature-id-618.xwd is not a real image. This is the
signature of DROID for XWD X11 images. In principal it contains just the
first bytes of such a screen dump image. And the graphic tools reject such a
sample with message "Failed" or "unable to read image header". So an
additional test to skip this file must be added. According to header text at
offset 68 the size of each color mask in bits is stored as 4 byteinteger.
Here i get values like 0, 1, 8 or 24. Maybe there exist also values like 4
or 32, but i assume that values are always "small". That means values lower
256 or in other words expressed the 3 upper bytes are nil. So for that i add
an additional XML construct inside xdm-x11.trid.xml like:
<Bytes>000000</Bytes>
<Pos>68</Pos>
The example x-fmt-300-signature-id-619.xdm is not a real image. This is the
signature of DROID for XWD X10 images. In principal it contains just the
first bytes of such a screen dump image. And the graphic tools reject such a
sample with message like "Failed". So an additional test to skip this file
must be added. Here things are a little bit more complicated, because i
found no clear characteristic field at the end of the header. According to
header text at offset 36 the border width is stored as 2 byte integer.
For the few X10 variant samples i get only values zero. But for X11 example
fig41.xwd i get value 1. And some X11 examples have just a few pixel
border. So for maze.dmp i get value 2 and for examples lenna.dmp and
mandrill.dmp i get value 3. So i assume that in real examples in worst case
i get a border width of a dozens but value is "small" That means values
lower 256 or in other words expressed the upper byte is nil. So for that i
add an additional XML construct inside xdm-x10.trid.xml like:
<Bytes>00</Bytes>
<Pos>36</Pos>
With the replacement TrID definition all of my inspected X screen dumps are
still described correctly and the misidentified DROID signatures vanish.
(see appended output/trid-v-new.txt). TrID definitions, some examples and
output are stored in archive xwd_file.zip.
With best wishes
Jörg Jenderek
