[File] [PATCH] Magdir/images for X pixmap image *.XPM
Christos Zoulas
christos at zoulas.com
Sat Apr 23 12:57:23 UTC 2022
Committed, thanks!
christos
> On Apr 22, 2022, at 6:59 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> 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 file command
> version 5.41 on such thousands examples and related files i get an
> output like:
>
> debug.c: C source, ASCII text
> dframeIB.xpm: data
> gnus.xpm: X pixmap image, ASCII text
> hardcopy.xpm: X pixmap image, ASCII text
> , with very long lines (10243)
> logo.xpm: ASCII text
> , with very long lines (303)
> mh-logo.xpm: X pixmap image, ASCII text
> mozicon50.xpm: ASCII text
> my3-xpm.xpm: ASCII text
> psetupl.xpm: X pixmap image, ASCII text
> testmlc.c: C source, ASCII text
> , with CR line terminators
> unchecked.xpm: X pixmap image, ASCII text
> x-fmt-208-signature-id-620.xpm: X pixmap image, ISO-8859 text
>
> Furthermore a probably misspelled image/x-xpmi mime type is
> shown with -i option. With option --extension only 3 byte sequence
> ??? is shown.
>
> For comparison reason i run the file format identification utility
> TrID ( See https://mark0.net/soft-trid-e.html). These are described
> as "X PixMap bitmap" with generic mime type text/plain by
> bitmap-xpm.trid.xml. It also identifies example dframeIB.xpm as
> pixmap image whereas file command only says "data" (See appended
> trid-v-xpm.txt.gz).
>
> 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.gz).
>
> Luckily with information given by the other tools i also found a
> page about X PixMap (XPM) on file formats archive team web
> site. There now also links for unusual samples are listed.
> That informations are expressed by comment lines inside
> Magdir/images like:
> # URL: http://fileformats.archiveteam.org/wiki/XPM
> # Reference: http://www.x.org/docs/XPM/xpm.pdf
> # http://mark0.net/download/triddefs_xml.7z
> # defs/b/bitmap-xpm.trid.xml
>
> The description happens by line like:
> 0 search/1 /*\ XPM\ */ X pixmap image text
> !:mime image/x-xpmi
>
> For reasons i explain later i put displaying part inside a subroutine
> that starts like:
> 0 name xpm-image
>> 0 string x X pixmap image text
> #!:mime image/x-xpm
> !:mime image/x-xpixmap
> !:ext xpm
> #!:ext xpm/pm
>
> Because the file format is just a simple bunch of c-source lines the
> generic type text/plain used by TrID is not wrong, but XPM get their
> own type. Used by current file command image/x-xpmi 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. In documentation beside XPM file name
> extension also PM is mentioned but i do not find such examples.
>
> For other image formats mostly the dimensions are shown. So i thought
> when working on XPM i do this and add that information. According to
> specification that values are stored as string with white space
> separated parts like:
> <width> <height> <ncolors> <cpp> [<x_hotspot> <y_hotspot>] [XPMEXT]
> The problem was to reach the beginning of the string. In my first
> efforts i just try to get to the string beginning by checking
> for double quote character, but that does not work because some
> examples like psetupl.xpm contains other strings like "License"
> before values string. But luckily the value string seems to appear
> always at a line on it own. So now show dimension part by lines like:
>
>> 0 search/0x406 \n"
>>> &0 regex/8 [0-9]{1,5} \b, %s
>>>> &0 regex/8 [0-9]{1,5} x %s
>>>>> &0 regex/12 [0-9]{1,9} x %s
>>>>>> &0 regex/14 [0-9]{1,2} \b, %s chars/pixel
>
> The second last line shows the numbers of colours with values like:
> 1 2 3 4 5 8 11 14 162 255
> For examples created by hardcopy i get here very high unrealistic
> value like 4294967295. So maybe that tool is buggy concerning XPM
> images.
>
> According to specification XPM examples should start with a 9 byte
> c-comment "/* XPM */". This check use TRID and DROID and most
> examples do this but a few do not do this. So give a hint to user
> about this non standard behaviour by additional lines like:
>> 0 string !/*\ XPM\ */
>>> 0 string x \b, 1st line "%s"
>
> You might say i do not care about "strange" non standard examples.
> Then such examples are only described as ASCII text 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. So these are now matched by
> starting test lines like:
> 0 string /*\040
>> 0 search/0xCE /*\ XPM\ */
>>> &0 search/1249 []
>>>> 0 use xpm-image
>
> The Mozilla and other "bad" examples still start with a c comment.
> The 9 byte magic comment comes a little bit later. Unfortunately
> these 2 first tests are also true for example
> x-fmt-208-signature-id-620.xpm. This is not a real XPM image. This is
> used by DROID as signature for XPM. So i look for an additional third
> test. According to specification the c expression should start with
> part like:
> static char* <variable_name>[] = {
> So in real examples this is a char array without explicit length (
> that are 2 brackets like [] ). So by third test "bad" DROID sample is
> skipped and real examples like mh-logo.xpm ( found in Emacs source
> tree) are matched.
>
> 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. So this sample is handled by branch like:
>> 0 default x
>>> 0 search/0x52 static\040char\040
>>>> &0 search/64 []
>>>>> 0 use xpm-image
>
> According to specification words are separated by a white space which
> can be composed of space and tabulation characters. Luckily in my
> "bad" examples this was exactly 1 space character, but i do not know
> if this always true for such "bad" examples. 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. So the
> first two test lines are also true for few examples testmlc.c and
> debug.c. The last is found inside clamav version 0.104 source tree.
> So these examples are skipped by additional third test for char array
> without explicit length.
>
> I found dozen of examples with name dframeIB.xpm. Most are part of
> icewm-themes package version 1.2.26-2 on raspian 11 system. In the
> example in sub directory gnomeish the last bytes are obviously used
> for padding and are nil bytes. And there may exist examples created
> on DOS systems with ASCII-Z as last character. So such examples were
> not considered as text by file command with the original search
> expression. With the new test lines such "non" ASCII examples are
> recognized, but i do not know if this always works.
>
> After applying the above mentioned modifications by patch
> file-5.41-images-xpm.diff then all my inspected XPM examples are
> now described with more details and some misidentification vanish.
> This now looks like:
>
> debug.c: ASCII text
> dframeIB.xpm: X pixmap image text
> , 32 x 2 x 1, 1 chars/pixel
> gnus.xpm: X pixmap image text
> , 271 x 273 x 3, 1 chars/pixel
> hardcopy.xpm: X pixmap image text
> , 1280 x 1024 x 42949672
> , 95 chars/pixel
> logo.xpm: X pixmap image text
> , 300 x 80 x 44, 1 chars/pixel,
> 1st line
> "/* This logo was created by
> Stephan Lau,"
> mh-logo.xpm: X pixmap image text
> , 18 x 13 x 2, 1 chars/pixel
> mozicon50.xpm: X pixmap image text
> , 48 x 48 x 251, 2 chars/pixel,
> 1st line
> "/* This Source Code Form is subject
> to the terms of the Mozilla Public"
> my3-xpm.xpm: X pixmap image text
> , 16 x 16 x 162, 2 chars/pixel,
> 1st line "/* my xpm test 3 */"
> psetupl.xpm: X pixmap image text
> , 32 x 32 x 11, 1 chars/pixel
> testmlc.c: ASCII text, with CR line terminators
> unchecked.xpm: X pixmap image text
> , 12 x 12 x 5, 1 chars/pixel
> x-fmt-208-signature-id-620.xpm: ISO-8859 text
>
>
> I hope my diff file can be applied in future version of file
> utility.
>
> With best wishes,
> Jörg Jenderek
> - --
> Jörg Jenderek
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCYmMzZgAKCRCv8rHJQhrU
> 1m9IAJ0bWgU2ZjHWfKeoHaeFtpHVMMw7dACgs2G2kBulEIeaIwhisI2JVTTVfsI=
> =adVK
> -----END PGP SIGNATURE-----
> <Nachrichtenteil als Anhang.DEFANGED-0><trid-v-xpm.txt.gz><droid-xpm.csv.gz><file-5_41-images-xpm_diff.DEFANGED-1><file-5_41-images-xpm_diff_sig.DEFANGED-2>--
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>
More information about the File
mailing list