Hello trid users,
some days ago the update of my AVM power line adapter failed. So i looked
for manual update procedures. One step was to download firmware like
fritz.powerline_1000ET_01_05.image from avm.de download server. These
firmware has "image" file name extension.
When i run TrID on such firmware examples mostly are described wrong like
"Amiga bitmap Font" by definition font-amiga.trid.xml. The real FONT
examples are described correctly by that definition ( see appended
output/trid-v-old.txt)
For comparison reason i also run the file utility (version 5.40). This
describes this example similar as "AmigaOS bitmap font" ( see appended
output/file-5.40.txt). According to specification i also run a patched file
command that displays more information ( see appended output/file.tmp)
The detection of font variant happens by checking for valid FCH_ID value
0x0f00 at the beginning. That is expressed inside front block section by XML
construct like:
<Pattern>
<Bytes>0F00</Bytes>
<Pos>0</Pos>
</Pattern>
So only 2 bytes are used as test criterion. According to file documentation
at least 4 bytes should be used for identification because when using fewer
number of bytes the recognition becomes less unique enough. That is here the
case for AVM firmware examples.
According to specification i also run a patched file command that displays
more information ( see appended output/file.tmp)
So i run tridscan to generate a replacement definition and refine definition
manually.
At offset 2 the number of FontContents elements is stored a 2 byte big
endian integer fch_NumEntries. That is the number of fonts with different
sizes. This has often value 1, but i also found value like 2, 3 like in
examples IconCondensed.font and tempfont.font. Also value 4 occur like in
example Franklin.font. Highest value i seen was 6 like in mcoop.font. In
theory the highest available value is 65535, but with knowing about the
meaning i assume that this value is always below 256. That means the upper
byte of that value is nil. That fact about number of elements is used by
patched file command as additional test criterion. So this fact together
with valid FCH_ID is now expressed by XML construct like:
<Pattern>
<Bytes>0F0000</Bytes>
<Pos>0</Pos>
</Pattern>
At offset 4 the fc_FileName is stored as string with maximal length of 256.
Apparently this often consist of filename appended by slash character and
font size element fc_YSize. This looks like:
topazb/6 suits/8 Excel/9e emerald/17 Franklin/23 DIAMONDS/60.8C
So in real world only a few dozen characters are used and the remaining
bytes are nil. The longest names in my examples used 28 bytes and that was:
BitStream Vera Sans Mono.font
So the trailing nil bytes are expressed by XML construct like:
<Pattern>
<Bytes>00000000000000000000000000000000000000000000
<Pos>31</Pos>
</Pattern>
At offset 260 the font size is stored as 2 byte big endian integer variable
fc_YSize with values like:
6 7 8 9 11 12 16 17 21 23 45 60
In theory the highest available value is 65535, but with knowing about the
meaning i assume that this values is always below 256. That means the upper
byte of that value is nil, that means byte at offset 260 is always 0.
With the generous assumption that fc_FileNam use 236 characters ( that means
20 training bytes are nil bytes) and "low" fc_YSize variable this is now
expressed by XML construct like:
<Pattern>
<Bytes>000000000000000000000000000000000000000000</Bytes>
<Pos>240</Pos>
</Pattern>
Instead of generic mime type application/octet-stream i choose a user
defined one. That is expressed by line like:
<Mime>font/x-amiga-font</Mime>
With my replacement trid definition all of my inspected FONT examples are
still recognized and misidentification of some AVM power line firmware
images vanished (see appended output/trid-v.txt). TrID definition and output
are stored in archive font_amiga.zip. I hope that the XML file can be used
in future version of triddefs.
With best wishes
Jörg Jenderek
