See more on Chunks in general.
This is a small bitmap, used to represent items in a graphical environment. The plain ICON chunk is used to define icons, and the ICON-n chunk specifies an icon for the archive file itself.
The n (pointer) Flag must be cleared. If set, see the ICON-n definition instead.
All other flags must be cleared. So, there can be no payload specification, no continuation, etc.
The Instance Number is matched against fields that refer to icons, including the ICON-n chunk and CMNT Icon chunks.
Instance numbers from hex 40 through hex FFF (64 through 4095) are reserved. An archive shall not contain instances in this range. Rather, pre-defined ICONs may be refered to without incuding them in your file.
∴Define the pre-defined ICONs
The Payload contains a list of records. All records in the same Instance refer to the same logical icon, but will contain different choices. The different choices may contain different resolutions, color depths, and features, but represent the same logical image. The environment picks one that is most suitable and supported.
Each record contains:
A uintV containing the number of bytes remaining in this record, not counting this Record Size field itself. After reading the Record Size, skip this many bytes to read the next Record Size.
A uintV coding one of the following options:
code | meaning |
---|---|
1 | Embedded |
2 | Internal |
3 | External |
An lp-something (either lpstring or lpbinary).
Depending on the Storage Type, the data is:
An actual image. Data is a lpbinary containing a PNG or MNG file for the bitmap.
An lpstring containing the name of a file stored in the archive. The name uses the same naming system used by the Entry Name of an INDX chunk, and starts with the top-level index of the archive. If an alternative index is involved, its Entry Name is mentioned as if it were another node in the path to the file.
A URL of a PNG or MNG file for the bitmap.
The intention is to make it easy for a graphical environment to detect and locate the Instance being refered to by the ICON-n#0 chunk without having to understand much about ZIP2 file structure. It can simply walk the chunks and spot the two-byte Type for ICON without having to worry about flags or unpacking solid-packed instances or gathering fragmented chunks or applying any kind of payload specification.
Such an environment may only understand the one and two byte forms of uintV, so don't use Instance Numbers greater than 16383 (hex 3FFF).
The n (pointer) Flag must be set. If cleared, see the plain ICON definition instead.
All other flags must be cleared. So, there can be no payload specification, no continuation, etc.
The Instance Number must be 0. There is only one instance per archive file (in a multi-part archive, each portion file can have its own).
The Payload contains a uintV containing the Instance Number of an ICON chunk.
The intention is to make it easy for a graphical environment to detect and locate an ICON-n#0 chunk without having to understand much about ZIP2 file structure. It can simply walk the chunks and spot a constant three bytes for chunk header ICON-n#0 without having to worry about flags or unpacking solid-packed instances or gathering fragmented chunks or applying any kind of payload specification.
Page content copyright 2003 by John M. Dlugosz. Home:http://www.dlugosz.com, email:mailto:john@dlugosz.com