A reverse-engineering of Garmin's SRT Subfile format
The structure of the common header is the same in all subfiles.
Byte Offset
|
Length (bytes)
|
Description
|
0x000
|
2
|
Header length. So far only '0x1D' and '0x27' has been seen.
|
0x002
|
10
|
Type GARMIN SRT
|
0x00C
|
1
|
0x01 ?
|
0x00D
|
1
|
0x00
|
0x00E
|
2
|
Creation year
|
0x010
|
1
|
Creation month
|
0x011
|
1
|
Creation day
|
0x012
|
1
|
Creation hour
|
0x013
|
1
|
Creation minute
|
0x014
|
1
|
Creation second
|
Byte Offset
|
Length (bytes)
|
Description
|
0x015
|
2
|
?? Only seen 0x0001 in here so far
|
0x017
|
4
|
Offset of 'Contents Section' (see below)? Only seen 0x0000001D in here so far
|
0x01B
|
2
|
Length (in bytes) of 'Contents Section'? Only seen 0x0010 in here so far
|
Contents Section
Byte Offset
|
Length (bytes)
|
Description
|
0x01D
|
4
|
Offset of 'Title Section' (see below)? Only seen 0x0000002D in here so far.
|
0x021
|
4
|
Length (in bytes) of 'Title Section'? Only seen 0x00000016 in here so far.
|
0x025
|
4
|
Offset of 'Character Lookup Table'? Only seen 0x00000043 in here so far.
|
0x029
|
4
|
Length (in bytes) of 'Character Lookup Table'? Only seen 0x00000355 in here so far.
|
Title Section
Byte Offset
|
Length (bytes)
|
Description
|
0x02D
|
??
|
A null-terminated string describing the SRT file's purpose. "Western European Sort" for instance.
|
Not sure about very much of this section yet.
Byte Offset
|
Length (bytes)
|
Description
|
0x043
|
2
|
?? Only seen 0x0034 here so far
|
0x045
|
2
|
?? Only seen 0x0007 here so far
|
0x047
|
2
|
?? Only seen 0x0002 here so far
|
0x049
|
2
|
Codepage corresponding to Character Lookup Table? Only seen 0x04E4 here so far (codepage 1252?)
|
0x04B
|
2
|
?? Only seen 0x2002 here so far
|
0x04D
|
2
|
?? Only seen 0x0000 here so far
|
0x04F
|
4
|
Offset of character lookup table? 0x00000034 seen here so far
|
0x053
|
4
|
Length (in bytes) of character lookup table? 0x000002FD seen here so far (which is 765 - only enough for 255 entries)
|
0x057
|
4
|
Size (in bytes) of each entry in the character lookup table? 0x00000003 seen here so far
|
0x05B
|
4
|
Character lookup table flags? 0x00000000 seen here so far
|
0x05F
|
4
|
Offset of what follows the character lookup table? 0x00000331 seen here so far (which is 0x34 + 0x2FD (see above))
|
0x063
|
4
|
Length (in bytes) of what follows the character lookup table? 0x00000024 seen here so far
|
0x067
|
4
|
Size (in bytes) of each entry in what follows the character lookup table? 0x00000002 seen here so far
|
0x06B
|
4
|
Flags for what follows the character lookup table? 0x00000000 seen here so far
|
0x06F
|
2
|
?? 0x0034 seen here so far
|
The Character Lookup Table
This is the guts of the file, and basically consists of 256 3-byte entries, one for each character of the codepage used by the map.
Byte Offset
|
Length (bytes)
|
Description
|
0x071
|
3
|
The entry in the character lookup table corresponding to character 0x00 of the codepage used by the maps.
|
0x074
|
3
|
The entry in the character lookup table corresponding to character 0x01 of the codepage used by the maps.
|
etc
|
etc
|
etc
|
Each entry in the table looks like this:
Byte Offset
|
Length (bytes)
|
Description
|
0x00
|
1
|
Flags giving the character's 'class'. A bitwise-OR of: 0x01=alphabetic, 0x02=numeric, 0x10=ligature, 0x20=mathematical(?).
|
0x01
|
1
|
The collating position for this character. Low values appear earlier in the sorted results.
|
0x02
|
1
|
Flags describing diacritic marks on a character. One of the following: (0x10='lowercase or digit', 0x20='uppercase') which is then bitwise-ORed with one of the following: (0x01='no diacritic', 0x02=acute, 0x03=grave, 0x04=circumflex(or caron), 0x05=ring, 0x06=umlaut, 0x07=tilde).
|
It seems that Garmin don't 100% stick to this suggested bit-allocation for the diacritic marks. It's possible that the value is more to allocate an order to the sorting of diacritic letters rather than identifying them uniquely.