This page describes the dictionary-compressed resource file format
introduced from Symbian OS v7.0. This format can produce higher-compression
than the simple compression format.
The format is supported by the resource reading APIs, but Development
Kits do not currently contain a resource compiler that produces this
format.
Number of bytes
|
Description
|
16
|
These bytes store the resource files UIDs.
The first twelve bytes consist of three four-byte integers (in
little-endian byte order) followed by a four-byte CRC checksum generated from
those three integers.
The first UID is always 0x101f5010.
The second and third UIDs are the same as the second and third
UIDs of the file from which the dictionary-compressed resource-file is
generated.
|
1
|
The least significant three bits:
These store the number of bits used for dictionary references,
storing this value as an offset from 3. For example, if 2 is stored in these
three bits, then the number of bits per dictionary reference would be 3+2=5.
Thus, the number of bits per dictionary reference may range inclusively from 3
(=3+0) to 10 (=3+7). The maximum number of dictionary entries for each number
of bits per dictionary reference is therefore 8
(=23), 16 (=24), 32
(=25), 64 (=26), 128
(=27), 256 (=28), 512
(=29), 1024
(=210).
The most significant five bits:
This stores flags. Currently there are three flags
defined:
The most significant bit (0x80) indicates whether the third UID
is actually the resource files offset (see the first row of the
preceding table for a description of what the offset is). The bit is set to
non-zero if it is, and zero if it is not.
The second-most significant bit (0x40) indicates whether the
first resource in the resource file (from the clients point of view) is
an RSS_SIGNATURE with default values for which no
data is actually stored later in the resource file. The bit is set to non-zero
if it is, and zero if it is not. This flag must only be on if the third UID of
the resource file is the resource files offset (see the 0x80 flag
described immediately above).
The third-most significant bit (0x20) flags if the bit-array
that indicates which resources contain compressed Unicode has been stored as a
resource before the clients actual resources. (If it is stored as a
resource, it benefits by being dictionary-compressed.) The bit is set to
non-zero if the bit-array is stored as a resource, and zero if it is simply
stored as a field on its own (see the fifth row of this table).
Note that the bit-array will not contain a bit that refers to
the non-stored (if the 0x40 flag is on) initial
RSS_SIGNATURE resource. It will also not contain a bit that refers
to itself if it is stored as a resource (i.e. if the 0x20 flag is on).
|
2
|
This two-byte integer (in little-endian byte order) stores the
size in bytes of the largest resource in the file (that is, the size when
uncompressed with regard to both dictionary-compression and compressed
Unicode).
|
2
|
This two-byte integer (in little-endian byte order) stores the
file-position of the start of the resource data (see the penultimate row of
this table for a description of the resource data).
|
Number_of_resources/8 (rounded up to the nearest whole number),
or zero if the 0x20 flag (described in the second row of this table) is
on
|
This is a bit-array (one bit for each resource) storing which
resources contain compressed Unicode. This field is not always present (see the
left-hand column).
|
[any]
|
This contains the data for all the dictionary entries stored
one after another with no bit-padding between them, encoded according to the
scheme described in the next table. The last dictionary entry, if not finishing
on a byte-boundary, is followed by zero pad-bits up to the next
byte-boundary.
|
Number_of_dictionary_entries*2
|
This is the dictionary index which is a series of two-byte
integers (in little-endian byte order), one for each dictionary entry, each
storing the offset in bits from the start of the entire dictionary data to
one-bit past the end of that dictionary entrys data (see row
immediately above).
|
[any]
|
This contains the data for all the resources stored in order,
one after another with no bit-padding between them, encoded according to the
scheme described in the next table. The data for the last resource, if not
finishing on a byte-boundary, is followed by zero pad-bits up to the next
byte-boundary.
|
Number_of_resources*2, or (number_of_resources-1)*2 if the 0x40
flag (described in the second row of this table) is on
|
This is the resource index which is a series of two-byte
integers (in little-endian byte order), one for each stored
resource, each storing the offset in bits from the start of the entire resource
data to one-bit past the end of that resources data (see row
immediately above).
|
|
The data for each dictionary entry and the data for each resource
consist of zero, one or more of the following bit-sequences shown in the table
below. Note that the order of bits is taken as going from least-significant to
most-significant. Thus, for example, the binary prefix 10 (assuming that these
bits were not split across a byte-boundary) would actually be stored with the 1
in the less significant bit of the bit-pair and the 0 in the more significant
bit.
Prefix bits
|
Description of what follows
|
0
|
This is followed by a dictionary reference (the second row of
the previous table describes the field indicating how many bits a dictionary
reference occupies). A dictionary reference is a zero-based index* into the
dictionary entries, i.e. a dictionary reference of 0 indicates the first
dictionary entry, and dictionary reference of 1 indicates the second dictionary
entry, etc.
|
10
|
This is followed by one octet of data, the least significant
bit of the octet being stored first.
|
110
|
This is followed by two octets of data, the least significant
bit of the first octet being stored first.
|
1110
|
This is followed by a three-bit integer* storing the number of
subsequent octets minus 3, followed by those octets themselves (the least
significant bit of the first octet being stored first). Use this to store a run
of between 3 and 10 octets (inclusive).
|
1111
|
This is followed by an eight-bit integer* storing the number of
subsequent octets minus 11, followed by those octets themselves (the least
significant bit of the first octet being stored first). Use this to store a run
of between 11 and 266 octets (inclusive).
|
|
* These integers, if split across one or more byte-boundaries are
stored in little-endian byte-order, i.e. the segment of the
integer stored in the next byte store more
significant bits than the segment of the integer stored in the
current byte.