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
PixMap".
When running TrID on such thousands XPM examples and related files i get an
unexpected output.
Most examples are described as "X PixMap bitmap" by bitmap-xpm.trid.xml But
a few like logo.xpm, mozicon50.xpm, mozicon16.xpm and my3-xpm.xpm are
described as "Unknown!" (see appended output/trid-v-old.txt).
For comparison reason i check these examples by file command utility. When
running file command (version 5.41) the undetected examples are also not
recognized. Furthermore one of dozens dframeIB.xpm samples is not recognized
and described only as "data" (See appended output/file-5.41.txt)
When running file command (newest version > 5.41) then undetected examples
are now recognized and misidentification vanish (See appended
output/file.txt)
For comparison reason i also run the file format identification utility
DROID ( See
https://sourceforge.net/projects/droid/). This identifies a few
XPM examples as "X-Windows Pixmap Image" with obviously correct mime type
image/x-xpixmap by x-fmt/208 signature (See appended droid_xpm.csv).
First i update the current definition bitmap-xpm.trid.xml. Because the XPM
file format is just a simple bunch of c-source lines the generic type
text/plain used by current TrID is not wrong. This is also shown by file
command when ignoring signature by -i and -e soft option (see appended
output/file-soft-i-5.41.txt). But XPM get their own type. Used by current
file command image/x-xpmi (see appended output/file-i-5.41.txt) is obviously
a misspelled with an additional appended letter i. So correct would be
image/x-xpm. According to shared-mime-info found for example on web site
reposcope.com this is an alias for image/x-xpixmap. This is also used by
DROID and mentioned on Wikipedia page. So i follow the main stream and now
also use this. This is now expressed by changed line like:
<Mime>image/x-xpixmap</Mime>
One advantage of the XPM format is that it can easily included in C code. To
be consistent this should be done by a pre-processor directive like:
#include "foo.xpm"
But some people put the XPM fragment directly inside C header text or C
source text which have file name extension c or h. Such examples are
xpmputty.c or progressui_gtk_icon.h. So beside standard XPM suffix you also
find XPM images with these two other extensions. This is now expressed
inside definition by updated line like:
<Ext>XPM/C/H</Ext>
But people should not do this. On some systems, such examples are now
considered as C header text or C source text based on the file
extension. When trying to edit them, they are usually opened with a text
editor like Emacs or vi. On other systems, however, the examples are viewed
as X pixmap files based on the magic comment. When trying to edit them, they
are then usually opened with an image editor.
The undetected examples are described as "ASCII text" by file command
utility (version 5.41) and the newest version describes these samples now
also as "X pixmap image text", but it also shows additional information that
starts with phrase "1st line". So we see that these examples still start
with a c-comment, but that is different from 9 byte c-comment "/* XPM */".
That should be used according to specification.
You might say i do not care about "strange" non standard examples. Then such
examples are only described as ASCII text or "Unknown!" but not an unimportant
factory is "bad" behaving. The company doing so is the "flagship" of open
source "Mozilla". Shame on them! I do not know why such people do not follow
the rules. Maybe when you include such images inside your c sources, then
the position or even missing of this magic 9 byte comment does not matter.
Because i am nice guy so i will support Mozilla extra ways. The observed
examples are mozicon16.xpm and mozicon50.xpm. These are found for example
inside Thunderbird version 60.5.3 source tree.
The Mozilla "bad" examples still start with a c comment. The 9 byte magic
comment comes a little bit later. But things are become more complicated. I
found inside qemu version 7.0.0 an example like logo.xpm where the magic
comment is completely missing.
Most software like XnView for example can not handle these non standard XPM
samples (see appended output/nconvert-info.txt), but a a few like IrfanView
or ImageMagick can do (see appended output/identify-verbose.txt).
So i run tridscan on these "strange" examples to generate
bitmap-xpm-rem.trid.xml. The samples still start with a c-comment. That is
expressed by XML construct like:
<Bytes>2F2A20</Bytes>
<ASCII> / *</ASCII>
<Pos>0</Pos>
According to specification the c expression should start with part like:
static char* <variable_name>[] = {
According to specification words are separated by a white space which can be
composed of space and tabulation characters. That was expressed inside
bitmap-xpm.trid.xml in global strings section by lines like:
<String>STATIC</String>
<String>CHAR</String>
Luckily in my "bad" examples this white space was exactly 1 space character,
but i do not know if this always true for such "bad" examples. That was
expressed inside bitmap-xpm-rem.trid.xml in global strings section by line
like:
<String>STATIC CHAR *</String>
Furthermore in all "strange" examples before data part was a 12-byte comment
"/* pixels */". That is expressed in global strings section by line like:
<String>* PIXELS *</String>
Because the magic comment line is missing this now looks like an ordinary c
source or header. So i do a counter check on such ten thousands
c-files. Unfortunately i found one example fapiufst.c. This is found for
example inside GhostPDL Source tree ( version 9.50 and 9.56.1). This
contains a line like:
const double expansion_x = 2, expansion_y = 2; /* pixels *//* adesso5.pdf */
Therefor this example is now misidentified as XPM.
The example x-fmt-208-signature-id-620.xpm is not a real XPM image. This is
used by DROID as signature for XPM. So this also identied as bitmap.
With the updated trid definition and variant now all XPM examples are
described ( see appended output/trid-new-v.txt). TrID definitions, some
examples and output are stored in archive xpm_trid.zip. I hope that my XML
files can be used in future version of triddefs.
With best wishes
Jörg Jenderek
