[File] [PATCH] Magdir/ FIG image *.fig; ASCII text versus data

Sat Feb 19 22:57:10 UTC 2022

Committed, thanks!

christos

> On Feb 14, 2022, at 5:04 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> some days ago i recompiled lilo boot loader source. In doc sub
> directory are files with FIG name extension.
> 
> When running file command version 5.41 on such examples and related
> files i get an output like:
> 
> COM-0-Modem-Stecker.fig:     data
> NCC1701.FIG:                 data
> bootloader.fig:              data
> gnupg-card-architecture.fig: FIG image text, version 3.2, ASCII text
> image.fig:                   data
> map.fig:                     FIG image text, version 3.1, ASCII text
> other.fig:                   data
> thermostat.fig:              data
> 
> Furthermore with -i option only generic application/octet-stream or
> text/plain is shown. With option --extension only 3 byte sequence ???
> is shown.
> 
> The example thermostat.fig is part of xfig package. The example
> COM-0-Modem-Stecker.fig was created by myself long time in the past.
> So i know these examples are valid. So the non detection of lilo
> example bootloader.fig is not an accident. This can be verified by
> opening examples by xfig graphic tool. Or on the command line this
> can be verified by command sequence like:
> fig2mpdf -v bootloader.fig && file bootloader.pdf
> 
> For comparison reason i run the file format identification utility
> TrID ( See https://mark0.net/soft-trid-e.html). Most examples,
> especially also the "data" examples are described as "FIG vector
> drawing" by fig.trid.xml (See appended fig-trid-v.txt.gz).
> 
> Luckily TrID tool displays correct file name extension FIG for
> inspected samples. This list with -v option the URL pointing to
> some information sites. That informations are expressed now by
> comment lines inside Magdir/images like:
> # URL: 		http://fileformats.archiveteam.org/wiki/Fig
> #		https://en.wikipedia.org/wiki/Xfig
> # Reference:	http://mark0.net/download/triddefs_xml.7z
> #		defs/f/fig.trid.xml
> 
> The description happen by lines like:
> 0	search/1	#FIG		FIG image text
> This only applies to text files and is equivalent to line like:
> 0	search/1/t	#FIG		FIG image text
> Unfortunately a few of hundreds examples like COM-0-Modem-Stecker.fig
> ,
> thermostat.fig and bootloader.fig contain Non ASCII text characters
> like CTRL-A or phrase "°C" like in thermostat.fig. So these
> examples are not detected by the magic line. These becomes vice
> versa if i use a line with binary search option like:
> 0	search/1/b	#FIG		FIG image text
> When i changed this to another variant both are recognised but with
> keep-going option i get text messages twice. I do not know if it a
> BUG or feature. This is done by line like:
> 0	search/1/tb	#FIG		FIG image text
> So i finally use 2 different start magic lines. That look like
> 0	search/1/ts	#FIG
>> &0	use		image-xfig
> 0	search/1/bs	#FIG
>> &0	use		image-xfig
> The displaying part is now done by new sub routine image-xfig. This
> starts like:
> 0	name		image-xfig
>> 8	ubyte		x		FIG image text
> !:mime	image/x-xfig
> !:ext	fig
> According to FreeDesktop.org shared MIME database instead of
> generic mime type like text/plain these get their own user defined
> one image/x-xfig. That information can be found for example on web
> site
> reposcope.com. After the start magic the version string (like 1.4
> 2.1 3.1 3.2) is shown by line like:
>> 5	string		x		\b, version %.3s
> Afterwards some times on first line comes text like: "Produced by
> xfig version 3.2.5-alpha5". That information is now also shown by
> line like:
>> 8	ubyte		>0x0D
>>> 8	string		x		"%s"
> The TrID command also checks for point character (2Eh) of version
> string. Probably no such exception examples exist. So maybe show
> unexpected examples by line like:
>> 6	ubyte		!0x2E		\b, at 6 %#x
> Furthermore TrID assume that 4-byte magic pattern always start at
> the beginning, but according to current file command this magic
> could occur a little bit later. I my self do not found such
> examples, but i keep the current behaviour.
> 
> Some "data" examples like CASTLE.FIG or NCC1701.FIG are described
> as "DeskMate Draw drawing" by dm-fig.trid.xml (See appended
> fig-trid-v.txt.gz).
> Luckily TrID tool displays correct file name extension FIG for such
> inspected samples. This list with -v option the URL pointing to
> some information site:
> That informations are expressed inside Magdir/images after XFIG
> section by by comment lines like:
> # URL: 		http://fileformats.archiveteam.org/wiki/DeskMate_Draw
> #		http://en.wikipedia.org/wiki/Deskmate
> # Reference:	http://mark0.net/download/triddefs_xml.7z
> #		defs/d/dm-fig.trid.xml
> According to that information such examples are now described by
> lines like:
> 0	string		\x14FIG		DeskMate Drawing
> !:mime	image/x-deskmate-fig
> !:ext	fig
> Instead of generic mime type application/octet-stream i display a
> user defined on.
> 
> After applying the above mentioned modifications by patch
> file-5.41-images-fig.diff then all my inspected examples are now
> described as before, but the data examples are now also identified.
> This now looks like:
> 
> COM-0-Modem-Stecker.fig:     FIG image text, version 2.1
> NCC1701.FIG:                 DeskMate Drawing
> bootloader.fig:              FIG image text, version 2.1
> gnupg-card-architecture.fig: FIG image text, version 3.2
> 			     "  Produced by xfig
> 			     version 3.2.5-alpha5", ASCII text
> image.fig:                   FIG image text, version 2.1
> map.fig:                     FIG image text, version 3.1, ASCII text
> other.fig:                   FIG image text, version 2.1
> thermostat.fig:              FIG image text, version 3.2
> 
> I hope my diff file can be applied in future version of file
> utility.
> 
> According to TrID there exist some other image files with fig file
> name extension (fig-cabri.trid.xml fig-playmation.trid.xml), but i
> do not find such examples.
> 
> With best wishes
> Jörg Jenderek
> - --
> Jörg Jenderek
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCYgrR/QAKCRCv8rHJQhrU
> 1qqKAJ9Y9aA075rV8SURZ10X+Btqmqe4NwCaAnP6oBZNdaVNEH5pk1mNrP7vvMI=
> =bVd7
> -----END PGP SIGNATURE-----
> <fig-trid-v.txt.gz><file-5_41-images-fig_diff.DEFANGED-7><file-5_41-images-fig_diff_sig.DEFANGED-8>--
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://mailman.astron.com/pipermail/file/attachments/20220219/0c342695/attachment.asc>