August 2026 – Obsolete Thor

I make a lot of sample files. Whenever I have access to software I haven’t sampled before, I immediately make a few files to keep for reference. If I am making a signature for those files, I try and find as many versions of the software out there and make sample files from each. This way I can ensure the signature is accurate and possibly distinguish between important version changes. This process works well, but takes some time.

I discovered a flaw in my process recently, which illustrates the need for enough variation in samples to make sense of the file format. I recently made a bunch of samples from an old Macintosh software tool called TypeStyler. It is a pretty amazing early Desktop Publishing tool, with a neat past. The problem turned out to be more revealing about the format than I realized.

TypeStyler was the product of two brothers, Dave and Ken Stillman developed in 1988. It was a very incredible program that helped the Macintosh be a leader in Desktop Publishing and design. They had already made a program called PosterMaker which they sold to Broderbund, and TypeStyler did well under the same Publisher. When the Macintosh turned its focus to MacOS X, the software stalled for a number of years, finally coming back under the Strider Software name.

Let’s take a look at one of the files from version 1.0 of the software.

% hexdump -C TS1-s02 | head
00000000  02 da 02 28 00 00 00 00  00 00 02 35 02 da 02 28  |.?.(.......5.?.(|
00000010  00 00 00 64 02 da 02 28  00 00 00 00 ff ff ff ff  |...d.?.(....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 00  |????????????....|
000000b0  00 01 00 00 00 00 00 00  00 78 00 00 00 00 00 00  |.........x......|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 03 00 00 00 48 00 48  00 00 00 00 02 da 02 28  |.....H.H.....?.(|
00000210  ff e1 ff e2 02 f9 02 46  03 47 05 28 03 fc 00 02  |????.?.F.G.(.?..|

The first thing I noticed was a repeating pattern. 02 DA 02 28. This pattern seemed important. I could also see it in later versions, but not always exactly the same.

% hexdump -C TS3-s01 | head
00000000  02 d8 02 28 25 21 00 01  00 00 02 db 02 d8 02 28  |.?.(%!.....?.?.(|
00000010  00 00 00 64 02 d8 02 28  00 00 00 00 ff ff ff ff  |...d.?.(....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 80  |????????????....|
000000b0  00 10 00 00 00 00 00 00  00 78 00 00 00 00 00 00  |.........x......|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 03 00 00 00 48 00 48  00 00 00 00 02 d8 02 28  |.....H.H.....?.(|
00000210  ff e1 ff e2 02 f9 02 46  03 47 05 28 03 fc 00 02  |????.?.F.G.(.?..|

I could see this pattern in many of the samples but not all of them, but it seemed inconsistent, not following a pattern based on version. It was then I realized I had seen the pattern before. Specially the pattern seen on line 200 or the 516th byte.

% hexdump -C TS1-s02 | head
00000200  00 03 00 00 00 48 00 48  00 00 00 00 02 da 02 28  |.....H.H.....?.(|
00000210  ff e1 ff e2 02 f9 02 46  03 47 05 28 03 fc 00 02  |????.?.F.G.(.?..|

If you look back at two of the other formats I have discussed on this blog. MORE and Ready, Set, Go! you would see the same pattern in those sample files as well.

% hexdump -C RSG1-s01 | head
00000000  00 78 00 03 00 00 00 48  00 48 00 00 00 00 02 da  |.x.....H.H.....?|
00000010  02 28 ff e1 ff e2 02 f9  02 46 03 47 05 28 03 fc  |.(????.?.F.G.(.?|
00000020  00 02 00 00 00 48 00 48  00 00 00 00 02 da 02 28  |.....H.H.....?.(|
00000030  00 01 00 00 00 64 00 00  00 01 00 01 01 01 00 00  |.....d..........|
00000040  00 01 27 0f 00 01 00 01  00 00 00 00 00 00 00 00  |..'.............|
00000050  00 00 00 00 00 02 00 19  01 90 00 00 00 00 00 40  |...............@|
00000060  00 00 00 00 00 00 00 00  00 01 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 01 00 01 00 48  |...............H|
00000080  00 48 00 48 00 48 00 01  00 00 00 01 00 00 00 01  |.H.H.H..........|
00000090  00 00 00 01 00 00 00 00  00 00 00 00 00 00 00 00  |................|

% hexdump -C MORE3-s01 | head
00000000  00 06 4d 4f 52 33 00 80  00 00 00 80 00 00 00 78  |..MOR3.........x|
00000010  00 00 00 f8 00 00 01 b4  00 00 02 ac 00 00 00 a8  |...?...?...?...?|
00000020  00 00 11 16 00 00 00 32  00 00 11 48 00 00 00 20  |.......2...H... |
00000030  00 00 11 68 00 00 00 00  00 00 11 68 00 00 00 10  |...h.......h....|
00000040  00 00 11 83 00 00 00 0c  00 00 11 68 00 00 00 00  |...........h....|
00000050  00 00 00 00 00 00 03 54  00 00 0d c2 00 00 11 78  |.......T...?...x|
00000060  00 00 00 0b 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 03 00 00 00 48 00 48  00 00 00 00 02 d8 02 28  |.....H.H.....?.(|
00000090  ff e1 ff e2 02 f9 02 46  03 47 05 28 03 fc 00 02  |????.?.F.G.(.?..|

How can this same pattern be found in three completely different software titles, from three different developers? Granted they are all originally Macintosh software, but still, there shouldn’t be any common encoding between them. I will admit it took me a minute to figure it out, and I did employ the use of AI to help brainstorm the pattern.

I should have seen it sooner as my background is in commercial printing and I have been using desktop publishing tools for years. You see the most common value in printing with Postscript is the value “72”. 72 is the number of points in an inch which all started with the development of Postscript, originally on a Macintosh. The hexadecimal “00 48” is 72 in decimal in big endian systems like the Macintosh. So the first part of the pattern seen in all three formats is 72×72 values indicating the unit of measurement. The next 4 bytes happen to be the page size in points. “02 DA” is decimal 730 and “02 28” is decimal 552. If you add 60 points used in margins, then you get roughly 8.5×11 letter sized page size. You can see the change here if I save a letter size page out with one portrait and one landscape.

% hexdump -C TS-Letter-Vert | head
00000000  02 da 02 28 00 00 00 00  00 00 02 3d 02 23 01 9e  |.?.(.......=.#..|
00000010  00 00 00 4b 02 da 02 28  00 00 00 00 ff ff ff ff  |...K.?.(....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 a3  |????????????...?|
000000b0  00 20 00 00 00 00 00 00  00 78 00 00 00 00 00 00  |. .......x......|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 03 00 00 00 48 00 48  00 00 00 00 02 da 02 28  |.....H.H.....?.(|
00000210  ff e1 ff e2 02 f9 02 46  03 47 05 28 03 fc 00 02  |????.?.F.G.(.?..|

% hexdump -C TS-Letter-Horz | head
00000000  02 28 02 da 00 00 00 00  00 00 02 3d 01 9e 02 23  |.(.?.......=...#|
00000010  00 00 00 4b 02 28 02 da  00 00 00 00 ff ff ff ff  |...K.(.?....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 a3  |????????????...?|
000000b0  00 20 00 00 00 00 00 00  00 78 00 00 00 00 00 00  |. .......x......|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 03 00 00 00 48 00 48  00 00 00 00 02 28 02 da  |.....H.H.....(.?|
00000210  ff e2 ff e1 02 46 02 f9  03 45 05 28 03 fc 00 02  |????.F.?.E.(.?..|

The bytes are swapped! Very cool to figure out, but not so helpful in identification as the values could be different in every file. You may have noticed the values in the 4th set of 4 bytes was different in these samples. A little experimentation and it looks like those 4 bytes are the value of what level of zoom is displayed in the software. If at 100%, which is often default, then the values would be the same as the page size, at 50%, they would be half. So also not helpful in identification, but helpful to document.

There are other bytes we can use for identification, the 3rd set of 4 bytes, after many samples made, appear to be representative of the version of software that created the file. The value increases with each version.

% hexdump -C TS1-s01 | head
00000000  02 d0 02 40 00 00 00 00  00 00 02 35 00 b4 00 90  |.?.@.......5.?..|

% hexdump -C TS2-s01 | head
00000000  02 d8 02 28 00 00 00 01  00 00 02 3b 02 22 01 9e  |.?.(.......;."..|

% hexdump -C TS3-s01 | head
00000000  02 d8 02 28 25 21 00 01  00 00 02 db 02 d8 02 28  |.?.(%!.....?.?.(|

% hexdump -C TS372-s01 | head
00000000  02 d8 02 28 00 00 00 00  00 00 02 f9 02 d8 02 28  |.?.(.......?.?.(|

TypeStyler 3.7.2 was the last version before the 9+ year gap before the next release, version 10. So these files will all have the value “00 00 02” then 34 through the hex values up to F9. Many of the point releases I have been able to make samples of have values spanning this gap.

Version	Value	Version	Value	Version	Value
1.0 Beta	00000234	2.0.1	0000023B	3.46.3	000002DB
1.0	00000235	3.2.1	0000023D	3.5.8	000002DC
1.5.2	00000239	3.43.2	000002DA	3.7.2	000002F9

These values are probably a little short for a solid identification. If you have been paying attention, you might have noticed each TypeStyler file also has a large sequence of “FF” values. Majority have 144 bytes worth, starting at offset 28 or 0x1C, there are a random couple files which are slightly different. I think with the two parts, a fine signature can be made and not accidentally identify one of these other desktop publishing formats.

Well, in 2009, the Strider Software company released their TypeStyler software built for MacOS X intel computers after a long hiatus. They added many more features which also meant a change to the file format. No longer did they use a single file to store the graphics, they used the commonly used Apple Package format. In essence a folder with an extension, which when registered with the Mac, appears as a single file. This way you can add all the files you like to the folder and it stays together. Seemed like a good idea at the time.

% tree TypeStyler11-s01.tsdx 
TypeStyler11-s01.tsdx
├── QuickLook
│   └── Thumbnail.png
├── Template
└── contents
    ├── PkgInfo
    ├── TSDoc.tsx
    └── TypeStyler Document.xml

4 directories, 4 files

This new package format has a structure with thumbnail and a contents folder. This folder has an extension of TSDX and within the contents folder an XML file, a PkgInfo, and a TSX file. Let’s look at each of them.

% cat TypeStyler11-s01.tsdx/contents/PkgInfo 
????????%  

% cat TypeStyler11-s01.tsdx/contents/TypeStyler\ Document.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Application Version</key>
	<string>10.0</string>
	<key>images</key>
	<dict/>
</dict>
</plist>

% hexdump -C TypeStyler11-s01.tsdx/contents/TSDoc.tsx | head
00000000  03 18 02 64 24 03 00 01  00 00 03 36 03 18 02 64  |...d$......6...d|
00000010  00 00 00 64 03 18 02 64  00 00 00 00 ff ff ff ff  |...d...d....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 bf  |????????????...?|
000000b0  00 20 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |. ..............|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000e0  00 00 00 00 00 00 00 00  00 00 32 5c 0c 5c 5f 64  |..........2\.\_d|
000000f0  64 64 64 64 64 64 19 19  5c 5c 5c 46 1e 00 42 c8  |dddddd..\\\F..B?|

The PkgInfo file is unhelpful. The XML is semi-helpful, but considering this was a version 11.6 file, the XML displays only 10.0 which I think is in all the samples I have.

The best identification comes from the TSX file, which excitingly looks like the previously format. We have pages sizes in the same place as well as the 144 bytes of “FF” and the values for the version show “00 00 03 36”. This seems to make sense with 03 being a natural increase to the 02 used in the previous versions. Looking at a sample from version 10:

% hexdump -C TyperStyler10-s01.tsdx/contents/TSDoc.tsx | head
00000000  03 18 02 64 00 00 00 01  00 00 03 30 03 18 02 64  |...d.......0...d|
00000010  00 00 00 64 03 18 02 64  00 00 00 00 ff ff ff ff  |...d...d....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 3c  |????????????...<|
000000b0  00 20 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |. ..............|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  b3 08 00 00 00 00 00 4d  00 22 01 59 02 33 00 4c  |?......M.".Y.3.L|
00000210  00 21 01 58 02 33 cc d3  e2 06 10 00 00 00 00 00  |.!.X.3???.......|

The version pattern starts fresh with 30! The TypeStyler software is still available, but appears to have stalled again. Version 11.6 was the last version released in 2019, so another 7 year hiatus. Ken Stillman passed away in 2023, further adding to the uncertainty of the future of TypeStyler.

This was a fun exploration of a format beyond the simple identification I usually focus on. With some of the variations I found I came up with this signature for Versions 1-3 of the TypeStyler Document format starting from offset 8

000002[30:FF]{16-20}FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

This signature takes into account the hex values 30 through FF to cover all the incremental updates. Instead of using all 144 bytes of “FF”, I limited it to just 64 bytes to allow for the couple of variations I found. I am not addressing versions 10-11 yet, ther eis no great way of identifying package formats with PRONOM yet. I may add the TSX format by itself, but for now you can find the signature and sample files on my Github page.