Hello trid users,
some days ago i handled WordPerfect files with name extension CBT. So
i looked for other WordPerfect samples. There exist samples with PRS
file name extension and names like: WORKBOOK.PRS STANDARD.PRS
I found no information especially about file format specification
about such WordPerfect files, but luckily some basic info are found in
unofficial WordPerfect File Format description
WPFF_DocumentStructure.htm. So i choose that page as reference. That
is expressed by line like:
<RefURL>
https://github.com/OneWingedShark/WordPerfect/blob/master/ doc/SDK_Help/FileFormats/WPFF_DocumentStructure.htm
</RefURL>
When i run TrID on such examples these are described correctly but
unspecific like "WordPerfect (generic)" by definition
wp-generic.trid.xml (see appended output/trid-v-old.txt).
For comparison reason i also run the file utility (version 5.42). This
describes the examples as "WordPerfect" with sub classification as
"printer data" and version "v3.2" or "v3.3" (see appended
output/file-5.42.txt).
The file command use describing text "WordPerfect printer data". The
documentation uses "Printer resource file". For me this fits better to
used file name extension. So i express this inside TrID definition by
lines like:
<FileType>WordPerfect Printer Resource</FileType>
<Ext>PRS</Ext>
So i run tridscan on my examples to generate prs-wp.trid.xml. So we
see that not only the first 4 bytes are the same like \xFFWPC that is
generic for all WordPerfect samples, but also the first bytes are the
same. That is expressed by XML construct like:
<Bytes>FF57504346000000011003</Bytes>
<ASCII> . W P C F</ASCII>
<Pos>0</Pos>
Unfortunately the definition is based only on 2 samples.
At offset 4 pointer to document area is stored as 4 byte little endian
integer. In my example this value was 70 ( hexadecimal 46). So the 3
upper bytes are nil by lucky circumstances in my examples.
At offset the 8 and 9 the product and file type are stored. In my
example this value was always 1 and 16 ( hexadecimal 10). According to
documentation that is significant for WordPerfect Printer resource PRS
files.
At offset 10 the major version and minor version fields are stored as
byte value. In my examples this value was 3.1 or 3.2.
Assuming that there exist examples with other document area offset and
other version numbers this becomes according to documentation like:
<Bytes>FF575043</Bytes>
<ASCII> . W P C</ASCII>
<Pos>0</Pos>
<Bytes>0110</Bytes>
<Pos>8</Pos>
At offset 12 encryption field is stored. In my examples this was
always zero. At offset 14 pointer to index area is stored. In my
examples this value was always zero. At offset 16 not documented
extended header starts. In my examples this value always starts with
byte sequence 4600. This is expressed by XML construct like:
<Bytes>00000000460000003100</Bytes>
<ASCII> . . . . F . . . 1</ASCII>
<Pos>12</Pos>
But i do not know if this always true. So at the moment i keep it.
The definition contain short nil sequences like:
<Bytes>0000</Bytes>
<Pos>42</Pos>
Assuming that these are triggered by lucky circumstances i delete
these.
The definition contain short non nil sequences like:
<Bytes>00002200</Bytes>
<ASCII> . . "</ASCII>
<Pos>24</Pos>
<Bytes>00FFFFFFFF0000</Bytes>
<Pos>33</Pos>
Assuming that these are triggered by lucky circumstances i delete
these.
Then only one alphabet pattern survived like:
<Bytes>205072696E7465720000FFFF00002400</Bytes>
<ASCII> P r i n t e r . . . . . . $</ASCII>
<Pos>109</Pos>
And in global string section i delete garbage looking strings and just
keep strings concerning printing phrases like:
<String>COURIER 10</String>
<String>PRINTER</String>
<String>ITALIC</String>
With the new definition now WordPerfect Printer Resource PRS examples
are described more precisely ( see appended
output/trid-v-new.txt). TrID definition and output are stored in
archive prs_.zip. I hope that the XML file can be used in future
version of triddefs.
Unfortunately there exist other printer files for WordPerfect with other file
format.
With best wishes
Jörg Jenderek
