12 <concept xml:lang="en" id="GUID-9574041E-183D-5C3F-8429-A62323B97739"><title>Dictionary-compressed resource format</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>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.</p> <p>The format is supported by the resource reading APIs, but Development Kits do not currently contain a resource compiler that produces this format.</p> <table id="GUID-BBB907BA-47D0-5218-94D8-C6DA502830EE"><tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/><tbody><row><entry><p><b>Number of bytes</b> </p> </entry> <entry><p><b>Description</b> </p> </entry> </row> <row><entry><p>16</p> </entry> <entry><p>These bytes store the resource file’s UIDs.</p> <p> 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. </p> <p>The first UID is always 0x101f5010. </p> <p>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.</p> </entry> </row> <row><entry><p>1</p> </entry> <entry><p><i>The least significant three bits:</i> </p> <p>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 (=2<sup>3</sup>), 16 (=2<sup>4</sup>), 32 (=2<sup>5</sup>), 64 (=2<sup>6</sup>), 128 (=2<sup>7</sup>), 256 (=2<sup>8</sup>), 512 (=2<sup>9</sup>), 1024 (=2<sup>10</sup>).</p> <p><i>The most significant five bits:</i> </p> <p>This stores flags. Currently there are three flags defined:</p> <p>The most significant bit (0x80) indicates whether the third UID is actually the resource file’s 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.</p> <p>The second-most significant bit (0x40) indicates whether the first resource in the resource file (from the client’s point of view) is an <codeph>RSS_SIGNATURE</codeph> with default values for which <i>no</i> 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 file’s offset (see the 0x80 flag described immediately above).</p> <p>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 client’s 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).</p> <p>Note that the bit-array will not contain a bit that refers to the “non-stored” (if the 0x40 flag is on) initial <codeph>RSS_SIGNATURE</codeph> 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).</p> </entry> </row> <row><entry><p>2</p> </entry> <entry><p>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).</p> </entry> </row> <row><entry><p>2</p> </entry> <entry><p>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).</p> </entry> </row> <row><entry><p>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</p> </entry> <entry><p>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).</p> </entry> </row> <row><entry><p>[any]</p> </entry> <entry><p>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.</p> </entry> </row> <row><entry><p>Number_of_dictionary_entries*2</p> </entry> <entry><p>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 entry’s data (see row immediately above).</p> </entry> </row> <row><entry><p>[any]</p> </entry> <entry><p>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.</p> </entry> </row> <row><entry><p>Number_of_resources*2, or (number_of_resources-1)*2 if the 0x40 flag (described in the second row of this table) is on</p> </entry> <entry><p>This is the resource index which is a series of two-byte integers (in little-endian byte order), one for each <i>stored</i> resource, each storing the offset in bits from the start of the entire resource data to one-bit past the end of that resource’s data (see row immediately above).</p> </entry> </row> </tbody> </tgroup> </table> <p>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.</p> <table id="GUID-4CE924FB-B8D7-51FE-9E67-CD9188E06D3D"><tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/><tbody><row><entry><p><b>Prefix bits</b> </p> </entry> <entry><p><b>Description of what follows</b> </p> </entry> </row> <row><entry><p>0</p> </entry> <entry><p>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.</p> </entry> </row> <row><entry><p>10</p> </entry> <entry><p>This is followed by one octet of data, the least significant bit of the octet being stored first.</p> </entry> </row> <row><entry><p>110</p> </entry> <entry><p>This is followed by two octets of data, the least significant bit of the first octet being stored first.</p> </entry> </row> <row><entry><p>1110</p> </entry> <entry><p>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).</p> </entry> </row> <row><entry><p>1111</p> </entry> <entry><p>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).</p> </entry> </row> </tbody> </tgroup> </table> <p>* 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 <i>more</i> significant bits than the segment of the integer stored in the “current” byte.</p> </conbody></concept> |
|