(little endian)

The page file is a tree. The root of the tree is a page object.

Page file structure:
+--------+----------------------------------------+
|pri hdr | +----------+ +-----------+ +---------+ |
|        | |aux hdr #1| |closing hdr| | payload | |
|9 bytes | |type=0xa  | |type=0xa   | |         | |
|        | |          | |(MAGIC)    | |         | |
|type=0xa| +----------+ +-----------+ +---------+ |
+--------+----------------------------------------+


Object structure:
	Primary header is 9 bytes long:
		- type: 1 byte
		- len: 4 bytes
		- unknown: 4 byte (usually all-zero)
	Payload: len number of bytes

Payload may start with aux headers:
	- this is recognised by the first byte matching the main header's type byte
	- these subsequent headers do not allocate or address further data blocks
	- the last header is the closing header and has a different structure:
		- the length of this header is the length field of the previous header
		- structure:
			- type: 1 byte (matching the main header)
			- the length of this header is known
			- the last 8 bytes of this header is a magic number
				0xFF 0xE4 0x5C 0x39 0x00 0x00 0x00 0x00

Payload:
	- payload is probably a C struct saved as is
	- the structure of payload depends on primary header type


----

string:
	- 2 byte length
	- string characters (as many as length said)
	- \0 (not part of length!)

----

Page struct:
	- page name (string)
	- page size (string): standard sizes (hardwired dimensions) 'A'..'E'
	- page settings:
		- TODO
	- a fixed sequence of payload segments:
		- 2 bytes number-of-object counter (how many objects make up this segment)
		- a sequence of the same objects packed (as many as the number-of-object counter) said