Author Topic: all-wp.trid.xml for WordPerfect printer data *.ALL  (Read 898 times)

jenderek

  • Sr. Member
  • ****
  • Posts: 375
all-wp.trid.xml for WordPerfect printer data *.ALL
« on: August 22, 2022, 09:36:45 PM »
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 ALL
file name extension and names like: HP4.ALL HP4L593.ALL WPMS1.ALL
WPMS53.ALL.

I found no information especially about file format specification for 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.3" (see appended output/file-5.42.txt).

So i run tridscan on my examples to generate all-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>FF57504346000000011303030000000046000000</Bytes>
   <ASCII> . W P C F . . . . . . . . . . . F</ASCII>
   <Pos>0</Pos>

At offset 4 pointer to document area is stored as 4 byte little endian
integer. In my examples this value was "low" 70 ( hexadecimal 46).
At offset the 8 and 9 the product and file type are stored. In my examples
this value was always 1 and 19 (hexadecimal 13). According to documentation
that is significant for WordPerfect Printer resource files.  At offset 10
the major version and minor version fields are stored as byte value. In my
examples this value was always 3.3. 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
extended file header starts with byte sequence 4600. This apparently is the
same as document pointer.

Assuming that there exist examples with other document arras and other
version numbers this becomes according to documentation like:
         <Bytes>FF575043</Bytes>
         <ASCII> . W P C</ASCII>
         <Pos>0</Pos>
         <Bytes>0113</Bytes>
         <Pos>8</Pos>
         <Bytes>00000000</Bytes>
         <Pos>12</Pos>

The definition contain short nil sequences like:
         <Bytes>0000</Bytes>
         <Pos>24</Pos>
         <Bytes>00</Bytes>
         <Pos>97</Pos>
Assuming that these are triggered by lucky circumstances i delete these.

The definition contain short non nil sequences like:
         <Bytes>FFFFFFFF0000</Bytes>
         <Pos>46</Pos>
         <Bytes>1400</Bytes>
         <Pos>92</Pos>
Assuming that these are triggered by lucky circumstances i delete these.

And in global string section i delete garbage looking strings like:
      <String>ED WITH T</String>
      <String>WITH THE</String>
      <String>ON THE</String>
      <String>SHOULD</String>
      <String>THE FI</String>
      <String>THE FO</String>
      <String>ASTER</String>
      <String>ATION</String>
      <String>DE FO</String>
      <String>E THE</String>
      <String>ER SH</String>
      <String>FOR T</String>
      <String>NOT S</String>
      <String>SHADO</String>
      <String>TERNA</String>
      <String>THE O</String>
      <String>THE P</String>
      <String>(10U</String>
      <String>(11U</String>
      <String>(15U</String>
      <String>(SP1</String>
      <String>*C0F</String>
      <String>*P+_</String>
      <String>*P-_</String>
      <String>*R1A</String>
      <String>.  T</String>
      <String>A DO</String>
      <String>GE F</String>
      <String>GH S</String>
      <String>I*B_</String>
      <String>I*P_</String>
      <String>I*T_</String>
      <String>L SH</String>
      <String>R OR</String>
      <String>R TO</String>
      <String>S AS</String>
      <String>S RE</String>
      <String>S SE</String>
      <String>S SH</String>
      <String>S TH</String>
      <String>T BE</String>
      <String>T CO</String>
      <String>T FE</String>
      <String>T MA</String>
      <String>T ON</String>
      <String>TING</String>

And i just keep strings concerning printing phrases like:
      <String>LTRGOTHIC (ITALIC)</String>
      <String>S CONDENSED ITALIC</String>
      <String>14PT BOLD (</String>
      <String>16.67CPI (</String>

With the new definition now these WordPerfect printer ALL examples are
described more precisely ( see appended output/trid-v-new.txt). TrID
definition and output are stored in archive all_.zip. I hope that the XML
file can be used in future version of triddefs.

Unfortunately there exist other Printer resource with other file format and
other suffix. So i mentioned this in a remark line.

With best wishes
Jörg Jenderek

Mark0

  • Administrator
  • Hero Member
  • *****
  • Posts: 2743
    • Mark0's Home Page
Re: all-wp.trid.xml for WordPerfect printer data *.ALL
« Reply #1 on: September 03, 2022, 05:44:34 PM »
Thanks!