The Plucker Document Format

Introduction

This document is the official description of the Plucker format.

Overview

The Plucker document format supports a multi-page (in the Web sense of 'page') hyperlinked information structure containing both 'rich' text and images. Links must be internal to the document, though external links, in standard URL form, may be included and displayed, but not followed. Images may either be embedded in a text page, as with HTML, or be included as separate stand-alone pages.

Plucker documents are structured so that they can be used both with a file-system-oriented operating system such as Unix or Windows, and with the PalmOS, a non-file-system-oriented OS. To this end, they always begin with a standard PalmOS record database prefix, which consists of four parts: the database header, a record-id list, an AppInfo block, and a SortInfo block. The Plucker format does not use the SortInfo block, which is therefore null, and consequently occupies no space in the document prefix.

The record database prefix is then followed by a sequence of application-specific records. In a Plucker document, this sequence consists of one index record, followed by a series of data records. The index record contains information about the data records, along with some global information, such as the type of compression used. Each data record contains either a page, an image, or data about the document, such as bookmarks or URL data.

The format is big-endian; any multi-byte numeric values specified in this document are big-endian. Images are stored in the Palm image format; for more information on this format please consult http://www.palmos.com/dev/tech/docs/.

The Database Prefix

The Database Header

The database header is a fixed-size structure of 72 bytes. It contains the name of the database, the Plucker version number, various timestamps (creation, modification, last backup), and several flags. All timestamps are given using the PalmOS standard, seconds since 12:00 AM on January 1, 1904.

Field	Bytes	Type	Notes
docName	32	String	Must contain a NUL-terminated 7-bit ASCII string (only character codes 0x20-0x7E are valid) giving the name of the document. Because of the terminating NUL character at end, only 31 bytes can actually be used for the name of the document. The first 26 bytes of this string are used by Plucker as a unique ID for the document; names should be unique in the first 26 characters.
flags	2	Bitfield	Most bits in this field are unused. Unused bits should be set to zero on document creation, but reader software should not expect them to stay at this value. Valid bits are as follows. All numeric values given are big-endian. Name Value Meaning CopyPrevention 0x0040 Indicates that system should not allow copying of this document. Launchable 0x0200 Indicates that this document should be presented as a first-class object on desktop renderings. If this bit is set, an AppInfo block must be included. Backup 0x0008 Indicates that this document should be backed up, if the system includes such a capability.
version	2	Numeric	Version of the Plucker format used in this document. Must have the value 1.
creationDate	4	Timestamp	Time of document creation
modificationDate	4	Timestamp	Time document last modified
unused1	8	Numeric	Must be zero at document creation, but any specific value should not be relied upon.
appInfoOffset	4	Numeric	Either zero, if no appInfo is present, or the offset from the beginning of the document to the start of the appInfo block.
sortInfoId	4	Numeric	Must be zero.
magic	8	String	Must be the 8 ISO Latin-1 characters "DataPlkr". No terminating NUL character.
unused2	4	Numeric	Must be zero at document creation, but any specific value should not be relied upon.

The Record-ID List

This list consists of a six-byte list header, followed by one ID entry for each data record in the document. The list header has the structure:

This is then followed by numRecords entries of the following structure:

Finally, there are two bytes of zero-padding to bring the structure alignment back to 4 bytes.

The AppInfo Block

Typically, this is only present when the launchable flag is set in the flags field of the database header. No Plucker data aside from icon display information and a versioning string is stored in this block. This block has the following structure:

The Index Record

This record includes info about the compression type used for the Plucker document and also what IDs the reserved records use. The viewer will use this record to know where to look for the reserved records and whether it must have support for ZLib compression. This record should always be the first record in the Plucker document (i.e. at index 0).

The reserved ID array consists of a series of name/ID pairs, where the ID is the unique ID (2 bytes) for the record and the name is a value (2 bytes) from the following list.

• home.html = 0
• external bookmarks = 1 (not implemented yet)
• URL handling = 2
• default category = 3
• additional metadata = 4

The Data Records

There are several different types of data records.

• text data (compressed/uncompressed)
• image data (compressed/uncompressed)
• mailto data
• URL handling data
• URL data (compressed/uncompressed)
• external bookmarks
• default category
• metadata

Each data record starts with a header, having the following structure:

Compression and the Owner-ID

This data format supports two forms of compression, DOC and ZLIB. That part of a data record that occurs after the header is compressed as a single chunk. All compressed records in a single document must use the same compression format. Compressed records may be mixed with uncompressed records.

DOC compression is the the format invented for early Palm usage.

ZLIB compression uses the ZLib format documented in Internet RFCs 1950 and 1951. See also http://www.gzip.org/zlib/manual.html for a description of the library used to perform the compression and decompression.

Plucker documents may be keyed to a specific string of 40 or fewer ASCII characters, called the owner-id. When such a key is specified, zlib compression must be used in the document. When an owner-id is specified, the beginning of each zlib-compressed data segment is XOR'ed with a value derived from the key, after compression, and must be XOR'ed again with the derived value before being decompressed. If an owner-id is specified for a document, the metadata record must exist, and must contain an OwnerID subrecord giving the CRC-32 of the owner-id string.

The derived value mentioned above is a 40-byte value constructed by forming 10 strings by concatenating the owner-id string with itself 2, 3, 4, 5, 6, 7, 8, 9, 10, and 11 times, then taking the CRC-32 values of each of these concatenations, then packing those 32-bit values in big-endian order into a 40-byte buffer.

Text data records

For text data the data record header is followed by a series of paragraph headers, each representing a paragraph block in the text data. This series of paragraph headers is then followed by the compressed or uncompressed text data. Each paragraph header has the form:

The (uncompressed) text data contains a character stream of ISO Latin-1 characters, interspersed with 'functions'.

A function is introduced in the text stream by a NULL character (0x00), followed by a one-byte function code and up to 7 bytes of data. The 3 LSB of the function code represent the remaining function data length; the 5 MSB denote the actual function code. The following functions are valid:

The function arguments have the following definitions:

Image data records

The image data consists of an image in Palm image format, compressed or uncompressed as specified in the document's index record. The image may in addition be internally compressed, via any of the compression techniques allowed in the Palm image format. Images must be less than 60k, uncompressed.

Mailto data records

URL handling data records

In practice, there are two kinds of records used to store the URL strings, the URL handling data record, which serves as an index into the sequence of strings, and the URL data record, one or more of which contain the actual strings.

The URL handling data is used to find the record ID of the record which contains the correct URL string. It contains a series of 2 byte number pairs.

Field	Bytes	Type	Notes
last_url	2	Numeric	the ordinal number of the last URL in record
id	2	Numeric	record ID for record

URL data records

These records may or may not be compressed. This is indicated by the type in the header. These records are used by the Details form to display the URL of the current record and by the External Reference form to display the URL of not collected pages. From either form you can copy the URL to a Memo to remind you to pluck it at a later date.

External Bookmarks data records

The bookmark data is a series of uid/offset pairs.

Default Category data records

Each Plucker document can be assigned to a number of named categories. This record stores the names of default categories for the document. The data consists of a concatenated series of NUL-terminated strings that should be used as the default category/categories for this document.

Metadata data records

There should only be one of these per document. This record begins with a two byte numeric value, giving the number of subrecords that follow, followed by that number of subrecords. The subrecords are a sequence of tagged variable length items. Each subrecord consists of three fields:

Field	Type	Bytes	Description
type code	Numeric	2	Specifies what piece of extra information is in this subrecord
length	Numeric	2	Number of 2-byte words in the argument
argument	(type code specific)	2 * length	Data

The following table describes the valid subrecord type codes, and describes the structure of the associated data for each subrecord type. Subrecords with unknown type codes should be ignored.

Type code	Name	Description	Argument
1	CharSet	This is the character set and encoding used by text records in this document, unless otherwise specified for particular records.	a two-byte numeric value, specifying the IETF IANA MIBenum value for the character set. See the IANA registry of character sets for valid values.
2	ExceptionalCharSets	This is a list of text records which use a charset other than that specified by the default CharSet. Note that if no default CharSet is specified, the default charset should be thought of as "unknown".	a sequence of (length / 2) record-ID, IANA-MIBenum pairs, where MIBenum values are as specified for CharSet. The invalid MIBenum value of 0 (zero) is used for records which have an unknown charset, if necessary. Field Bytes Type Notes record ID 2 Numeric unique ID for record MIBenum 2 Numeric IANA MIBenum for the character set used in this record
3	OwnerID	This is the CRC-32 of the specified owner-id for the document, if any. Note that associating an owner-id with a document also affects the calculation of zlib compression.	a four-byte numeric value giving the CRC-32 of the owner-id string.
4	Author	The name of the author of the document.	A string value in the document's default character set, padded at the end with NUL characters to an even number of bytes.
5	Title	The full title of the document.	A string value in the document's default character set, padded at the end with NUL characters to an even number of bytes.
6	PublicationDate	The date and time this document was created.	A 4-byte unsigned integer giving the number of seconds from 12:00 AM on January 1, 1904, to the time when this document was created.

© Copyright 2000 Michael Nordström <micke@sslug.dk> · Copyright 2001 Bill Janssen <bill@janssen.org

$Id: DBFormat.html,v 1.13 2002/06/11 23:59:11 janssen Exp $