Hello trid users,
Some days ago i handled some Macintosh forks. Examples with DFONT extension
are Macintosh forks with fonts embedded.
So i run trid utility on my DFONT examples. Many (24 of 26) like
AppleCasual.dfont are described correctly as "Macintosh OS X Data Fork Font"
by dfont.trid.xml. But few examples like ESPNTicker.dfont and GohuFont.dfont
are only described wrong as "MacBinary 1" by macbinary-1.trid.xml (See
appended output/trid-v-old.txt).
For comparison reason i check these examples by file command utility. When
running file command (version 5.43) here also a most examples are described
correctly as "Mac OSX datafork font". Furthermore it does a sub
classification like "TrueType" or "PostScript". But here other examples like
AppleCasual.dfont and ESPNTicker.dfont are not recognized as fonts and are
only described as "Apple HFS/HFS+ resource fork" because file command use
another method for recognition (See appended output/file-5.43.txt). When
running newest version (>5.43 with apple,v 1.46 2022/10/02) now all my DFONT
examples are recognized (See appended output/file.txt). With -i option it
also show now the correct mime type (See output/file-i.txt)
For comparison reason i also run the file format identification utility
DROID ( See
https://sourceforge.net/projects/droid/). This does not
recognize the DFONT examples.
After running tridscan to update definition dfont.trid.xml i looked what has
changed and why. In global string section some lines vanish like:
<String>GLYF</String>
<String>HEAD</String>
<String>HMTX</String>
<String>LOCA</String>
The really characteristic is inside global strings section lines like:
<String>POST</String>
<String>SFNT</String>
The first is handled by file command as PostScript sub type. The second is
handled by file command as TrueType sub type.
At position 0 the offset of resource data is stored as 4 byte big endian
integer. Usually this starts at offset 0x0100. At position 4 the offset of
resource map is stored as 4 byte big endian integer. Theoretical upper limit
is 4 GiB. Obviously this is never reached. So the highest byte is nil. These
facts are expressed inside Front Block section by XML construct like:
<Bytes>0000010000</Bytes>
<Pos>0</Pos>
At position 8 the length of resource data is stored as 4 byte big endian
integer. Theoretical upper limit is 4 GiB. Obviously this is never
reached. So the highest byte is nil. This fact is expressed inside Front
Block section by XML construct like:
<Bytes>00</Bytes>
<Pos>8</Pos>
At position 12 the length of resource map is stored as 4 byte big endian
integer. In the documentation is written that here s 32 K limit exist ( that
is 8000 hexadecimal). So the 2 upper bytes are ALWAYS nil. That facts are
expressed by XML construct like:
<Bytes>0000</Bytes>
<Pos>12</Pos>
Luckily information about Macintosh resource can be found on file formats
archive team web site. So this is used as reference . That is expressed by
line like:
<RefURL>
http://fileformats.archiveteam.org/wiki/Macintosh_resource_file </RefURL>
According to Wikipedia the DFONT examples have an own mime type. That is
expressed by line like:
<Mime>application/x-dfont</Mime>
With the updated trid definition now my DFONT examples are described (see
appended output/trid-v-new.txt). TrID definition and output are stored in
archive dfont_.zip. I hope that my updated XML file can be used in future
version of triddefs.
With best wishes
Jörg Jenderek
