<?xml version="1.0" encoding="UTF-8"?>
<!--
   ====================================================================
   Licensed to the Apache Software Foundation (ASF) under one or more
   contributor license agreements.  See the NOTICE file distributed with
   this work for additional information regarding copyright ownership.
   The ASF licenses this file to You under the Apache License, Version 2.0
   (the "License"); you may not use this file except in compliance with
   the License.  You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.
   ====================================================================
--><!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "../dtd/document-v11.dtd">
<document>
    <header>
        <title>POI-HPBF - A Guide to the Publisher File Format</title>
        <subtitle>Overview</subtitle>
        <authors>
            <person name="Nick Burch" email="nick at torchbox dot com"/>
        </authors>
    </header>

    <body>
        <section><title>Document Streams</title>
		<p>
		The file is made up of a number of POIFS streams. A typical
        file will be made up as follows:
		</p>
<source xml:space="preserve"><![CDATA[
Root Entry -
  Objects -
    (no children)
  SummaryInformation <(0x05)SummaryInformation>
  DocumentSummaryInformation <(0x05)DocumentSummaryInformation>
  Escher -
    EscherStm
    EscherDelayStm
  Quill -
    QuillSub -
      CONTENTS
      CompObj <(0x01)CompObj>
  Envelope
  Contents
  Internal <(0x03)Internal>
  CompObj <(0x01)CompObj>
  VBA -
    (no children)
]]></source>
		</section>
        <section><title>Changing Text</title>
		<p>If you make a change to the text of a file, but not change
          how much text there is, then the <em>CONTENTS</em> stream
          will undergo a small change, and the <em>Contents</em> stream
          will undergo a large change.</p>
        <p>If you make a change to the text of a file, and change the
          amount of text there is, then both the <em>Contents</em> and
          the <em>CONTENTS</em> streams change.</p>
		</section>
        <section><title>Changing Shapes</title>
        <p>If you alter the size of a textbox, but make no text changes,
          then both <em>Contents</em> and <em>CONTENTS</em> streams
          change. There are no changes to the Escher streams.</p>
        <p>If you set the background colour of a textbox, but make
          no changes to the text, (to finish off)</p>
		</section>
        <section><title>Structure of CONTENTS</title>
        <p>First we have "CHNKINK ", followed by 24 bytes.</p>
        <p>Next we have 20 sequences of 24 bytes each. If the first two bytes
         at 0x1800, then that sequence entry exists, but if it's 0x0000 then
         the entry doesn't exist. If it does exist, we then have 4 bytes of
         upper case ASCII text, followed by three little endian shorts.
         The first of these seems to be the count of that type, the second is
         usually 1, the third is usually zero. The we have another 4 bytes of
         upper case ASCII text, normally but not always the same as the first
         text. Finally, we have an unsigned little endian 32 bit offset to
         the start of the data for this, then an unsigned little endian
         32 bit offset of the length of this section.</p>
        <p>Normally, the first sequence entry is for TEXT, and the text data
         will start at 0x200. After that is normally two or three STSH entries
         (so the first short has values 0, then 1, then 2). After that it
         seems to vary.</p>
        <p>At 0x200 we have the text, stored as little endian 16 bit unicode.</p>
        <p>After the text comes all sorts of other stuff, presumably as 
         described by the sequences.</p>
        <p>For a contents stream of length 7168 / 0x1c00 bytes, the start 
         looks something like:</p>
<source xml:space="preserve"><![CDATA[
CHNKINK       // "CHNKINK "
04 00 07 00   // Normally 04 00 07 00
13 00 00 03   // Normally ## 00 00 03
00 02 00 00   // Normally 00 ## 00 00
00 1c 00 00   // Normally length of the stream
f8 01 13 00   // Normally f8 01 11/13 00
ff ff ff ff   // Normally seems to be ffffffff

18 00 
TEXT 00 00 01 00 00 00       // TEXT 0 1 0
TEXT 00 02 00 00 d0 03 00 00 // TEXT from: 200 (512), len: 3d0 (976)
18 00 
STSH 00 00 01 00 00 00       // STSH 0 1 0
STSH d0 05 00 00 1e 00 00 00 // STSH from: 5d0 (1488), len: 1e (30)
18 00 
STSH 01 00 01 00 00 00       // STSH 1 1 0
STSH ee 05 00 00 b8 01 00 00 // STSH from: 5ee (1518), len: 1b8 (440)
18 00 
STSH 02 00 01 00 00 00       // STSH 2 1 0
STSH a6 07 00 00 3c 00 00 00 // STSH from: 7a6 (1958), len: 3c (60)
18 00 
FDPP 00 00 01 00 00 00       // FDPP 0 1 0
FDPP 00 08 00 00 00 02 00 00 // FDPP from: 800 (2048), len: 200 (512)
18 00 
FDPC 00 00 01 00 00 00       // FDPC 0 1 0
FDPC 00 0a 00 00 00 02 00 00 // FDPC from: a00 (2560), len: 200 (512)
18 00 
FDPC 01 00 01 00 00 00       // FDPC 1 1 0
FDPC 00 0c 00 00 00 02 00 00 // FDPC from: c00 (3072), len: 200 (512)
18 00 
SYID 00 00 01 00 00 00       // SYID 0 1 0
SYID 00 0e 00 00 20 00 00 00 // SYID from: e00 (3584), len: 20 (32)
18 00 
SGP  00 00 01 00 00 00       // SGP  0 1 0
SGP  20 0e 00 00 0a 00 00 00 // SGP  from: e20 (3616), len: a (10)
18 00 
INK  00 00 01 00 00 00       // INK  0 1 0
INK  2a 0e 00 00 04 00 00 00 // INK  from: e2a (3626), len: 4 (4)
18 00 
BTEP 00 00 01 00 00 00       // BTEP 0 1 0
PLC  2e 0e 00 00 18 00 00 00 // PLC  from: e2e (3630), len: 18 (24)
18 00 
BTEC 00 00 01 00 00 00       // BTEC 0 1 0
PLC  46 0e 00 00 20 00 00 00 // PLC  from: e46 (3654), len: 20 (32)
18 00 
FONT 00 00 01 00 00 00       // FONT 0 1 0
FONT 66 0e 00 00 48 03 00 00 // FONT from: e66 (3686), len: 348 (840)
18 00 
TCD  03 00 01 00 00 00       // TCD  3 1 0
PLC  ae 11 00 00 24 00 00 00 // PLC  from: 11ae (4526), len: 24 (36)
18 00 
TOKN 04 00 01 00 00 00       // TOKN 4 1 0
PLC  d2 11 00 00 0a 01 00 00 // PLC  from: 11d2 (4562), len: 10a (266)
18 00 
TOKN 05 00 01 00 00 00       // TOKN 5 1 0
PLC  dc 12 00 00 2a 01 00 00 // PLC  from: 12dc (4828), len: 12a (298)
18 00 
STRS 00 00 01 00 00 00       // STRS 0 1 0
PLC  06 14 00 00 46 00 00 00 // PLC  from: 1406 (5126), len: 46 (70)
18 00 
MCLD 00 00 01 00 00 00       // MCLD 0 1 0
MCLD 4c 14 00 00 16 06 00 00 // MCLD from: 144c (5196), len: 616 (1558)
18 00 
PL   00 00 01 00 00 00       // PL   0 1 0
PL   62 1a 00 00 48 00 00 00 // PL   from: 1a62 (6754), len: 48 (72)
00 00                        // Blank entry follows
00 00 00 00 00 00
00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00

(the text will then start)
]]></source>
		<p>We think that the first 4 bytes of text describes the
		 the function of the data at the offset. The first short is
		 then the count of that type, eg the 2nd will have 1. We
		 think that the second 4 bytes of text describes the format
		 of data block at the offset. The format of the text block
		 is easy, but we're still trying to figure out the others.</p>

           <section><title>Structure of TEXT bit</title>
           <p>This is very simple. All the text for the document is
            stored in a single bit of the Quill CONTENTS. The text
            is stored as little endian 16 bit unicode strings.</p>
           </section>
           <section><title>Structure of PLC bit</title>
           <p>The first four bytes seem to hold the count of the 
            entries in the bit, and the second four bytes seem to hold
            the type. There is then some pre-data, and then data for
            each of the entries, the exact format dependant on the type.</p>
           <p>Type 0 has 4 2 byte unsigned ints, then a pair of 2 byte
            unsigned ints for each entry.</p>
           <p>Type 4 has 4 2 byte unsigned ints, then a pair of 4 byte
            unsigned ints for each entry.</p>
           <p>Type 8 has 7 2 byte unsigned ints, then a pair of 4 byte
            unsigned ints for each entry.</p>
           <p>Type 12 holds hyperlinks, and is very much more complex.
            See <code>org.apache.poi.hpbf.model.qcbits.QCPLCBit</code>
            for our best guess as to how the contents match up.</p>
           </section>
		</section>
	</body>
</document>