TypeStyler

August 21, 2026 by Thor 1 Comment

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.

Common Ground

October 20, 2023 by Thor 1 Comment

If digital preservation had an extension it most likely would be .DP

Unfortunately, it’s taken. Say hello to Digital Paper.

In the early 1990’s, folks started to share documents with each other through the their phone lines. The early internet, BBS, AOL, CompuServe and the like allowed people to share ideas through applications like Word/WordPerfect Documents. Most people had a copy of the popular software and that software could open documents from their competitors, but fonts were always a problem. Technically a font is software as well and needs a license to be used. Also printers at the time dictated what the document might look like when opened, so your document may look different on someone else’s computer. This lead to a few innovations in the software market Digital Paper.

The idea is simple, create a format which could be opened with a free viewer which includes all the parts to make it look and print just like it was intended to. You may have already guessed who the winner in this space tuned out to be, yes, the PDF format. You can’t tell the history of the PDF Format without mentioning others that tried their luck to be the leader in portable document formats . WordPerfect’s Envoy format was one, Common Ground Digital Paper was another.

No Hands Software which started in 1990, developed the idea of making your documents truly portable. They released the Common Ground Maker and Viewer software in 1993. By 1996 the company was doing so well they were bought for $6 million by Hummingbird Ltd. PDF soon became so ubiquitous, formats like Common Ground and Envoy fizzled out. That doesn’t mean they didn’t have a big impact and still can be found in quite a few places.

Apple was one of the bigger users for awhile, but the format can still be found floating around today.

The Common Ground Digital Paper has some similarities to the PDF format, but the biggest different is the format is proprietary and not open like PDF. Another difference is you could embed the viewer into the file, this would make an executable on both Windows and Macintosh. Very convenient for sending to those who may not have the viewer or can’t install the viewer on their system.

Common Ground had two different viewers, a pro viewer with more features and a Mini Viewer with basic features and which was free to download and distribute from their website. Unfortunately, they linked to an FTP site which no longer is available and so finding the viewers today can be difficult.

I came across a boxed version 1 for Macintosh of the software a few years back, but have yet to find other full versions. The software did change hands a bit, but seems to have topped out at Version 4 in the late 1990’s. Let’s take a look at the file format for the samples we do have.

Version 1 for the Macintosh was the first I believe, coming to Windows shortly afterwards. The format was even assigned a MimeType for use on the web and the application gives us a little insight into the format.

The commonground file format does have versions (two at the moment). They *are* internally documented with a file signature, allowing commonground viewers to automatically handle both old and new format files. Therefore, I don’t believe a ‘version’ parameter is needed.

A Content-Type of “application/commonground” indicates a document in the Common Ground portable file format, also known as Digital Paper.

Encoding considerations: Common Ground files are in a binary format. Some encoding will be necessary for MIME mailers as in application/octet-stream. Common Ground files for the Macintosh are encoded in the data fork of a Macintosh file. The file type is APPL, the creator is CGVM.

If we look at a sample from Version 1 for the Macintosh we find the follow hex values:

hexdump -C CG-s01.dp | head
00000000  00 00 03 56 00 00 04 d9  43 47 44 43 00 00 00 00  |...V....CGDC....|
00000010  96 6c 00 07 04 b4 03 de  00 00 00 00 02 da 02 28  |.l.............(|
00000020  00 11 02 ff 0c 00 ff ff  ff ff 00 00 00 00 00 00  |................|
00000030  00 00 02 28 00 00 02 da  00 00 00 00 00 00 00 01  |...(............|
00000040  00 0a 00 05 00 05 00 15  02 23 00 32 00 05 80 02  |.........#.2....|
00000050  00 15 7f fe 00 2c 00 09  00 03 06 47 65 6e 65 76  |.....,.....Genev|
00000060  61 00 00 03 00 03 00 0d  00 0c 00 2e 00 04 00 00  |a...............|
00000070  00 00 00 2b 06 11 07 54  65 73 74 69 6e 67 00 01  |...+...Testing..|
00000080  00 0a ff e1 ff e2 02 f9  02 46 00 03 00 00 00 0d  |.........F......|
00000090  00 00 00 28 02 d5 01 05  05 2d 20 31 20 2d 00 ff  |...(.....- 1 -..|

In all the samples I have the first 8 bytes are not consistent, but the next four bytes are. CGDC, which happens to be the registered type on the Macintosh. Convenient. But it appears later versions are not the same.

hexdump -C MANUAL.DP | head
00000000  00 00 00 20 00 00 b7 f4  44 50 4c 33 00 00 00 04  |... ....DPL3....|
00000010  00 00 00 00 00 00 00 00  3b 60 53 df 00 00 00 00  |........;`S.....|
00000020  00 00 00 18 00 00 b4 da  00 00 b4 c2 00 00 03 3e  |...............>|
00000030  78 00 79 00 7a 00 7b 00  00 00 00 77 01 01 00 0c  |x.y.z.{....w....|
00000040  00 01 02 01 00 00 00 97  fe ed f0 05 00 b7 86 04  |................|
00000050  5f 05 f7 01 00 03 ed f0  02 00 3d 00 ff 45 75 72  |_.........=..Eur|
00000060  6c 20 00 01 07 ff bf 05  9f 00 01 08 a3 05 fb ba  |l ..............|
00000070  02 fa f1 00 ff ff 00 11  ff 68 74 74 70 3a 2f 2f  |.........http://|
00000080  77 ff 77 77 2e 47 53 50  2e 43 b9 43 1c 0f 03 04  |w.ww.GSP.C.C....|
00000090  95 05 c8 0d 00 cc fb 05  e3 13 06 15 6d 61 69 6c  |............mail|

hexdump -C dpwhite.dp | head
00000000  00 00 00 18 00 01 79 17  44 50 4c 32 00 00 00 00  |......y.DPL2....|
00000010  00 00 00 00 00 00 00 00  00 00 00 18 00 01 76 de  |..............v.|
00000020  00 01 76 c6 00 00 04 b2  00 00 00 00 00 00 00 00  |..v.............|
00000030  00 00 00 1e 01 01 00 0c  00 00 01 01 00 00 00 12  |................|
00000040  00 01 00 01 00 00 00 00  0c 4e 09 60 01 2c 01 2c  |.........N.`.,.,|
00000050  00 64 00 00 00 02 00 00  00 00 00 a2 01 01 00 0c  |.d..............|
00000060  00 01 02 01 00 00 00 e2  fa ed f0 22 ed f1 0c 4e  |..........."...N|
00000070  09 60 00 ff e1 01 26 0a  83 08 3b ff ff 6a ff 6a  |.`....&...;..j.j|
00000080  0c e4 09 f6 01 ff 2c 01  2c 00 08 00 64 00 df 00  |......,.,...d...|
00000090  01 01 00 03 ed f0 0f 00  79 0a 1c 0f 28 07 42 41  |........y...(.BA|

These files are from a later version and have a different string at byte 8. DPL2 & DPL3. In the MiniViewer you can request document information and it provides some basic metadata for each file.

I only have one example of the DPL3, but a couple examples of DPL2, and it seems like DPL2 comes from a Version 3 DP Maker and DPL3 comes from Version 4 Maker. Need to see if I can find a Version 2 file and see if it follows the same pattern.

Two of my favorite CD-ROM’s on Internet Archive are Dr. Dobb’s The Essential Books on File Formats and Internet File Formats, both have copies of the Mini Viewer.

One of features similar to PDF is the ability to password protect certain features. This is what the document information looks like.

The header is the same, but the plain text usually seen in the file is no longer visible, so it appears the rest of the file is encrypted.

hexdump -C password.dp | head 
00000000  00 00 5d 95 00 00 06 94  43 47 44 43 00 00 00 01  |..].....CGDC....|
00000010  8e 3b 18 7e c5 16 f8 e0  0f f5 6f 32 2f 34 36 81  |.;.~......o2/46.|
00000020  4b 8a 03 da 9e 1a 85 6c  36 e4 39 f2 5a 2a a2 5f  |K......l6.9.Z*._|
00000030  81 83 65 ee 9c 16 d0 2d  2d c3 04 df 69 c8 06 0d  |..e....--...i...|
00000040  77 df 27 19 33 59 f6 05  61 4e 2c a6 58 27 47 26  |w.'.3Y..aN,.X'G&|
00000050  fe 6b 3c 06 7e cb 7f fb  33 f8 64 ed 05 54 b4 7d  |.k<.~...3.d..T.}|
00000060  c7 b5 e3 c2 df 40 53 63  ef 8e 10 1c c7 58 bd 28  |.....@Sc.....X.(|
00000070  9b 8a 2c 8f ae 82 33 f7  ff d4 3c 96 5c b4 08 69  |..,...3...<.\..i|
00000080  1f 00 af ce a7 56 93 27  07 cc 39 97 17 22 49 d7  |.....V.'..9.."I.|
00000090  5b 89 9b e6 b7 b1 5c 38  75 ba 08 ee 66 d0 9a d2  |[.....\8u...f...|

This file format is not currently in PRONOM. From what I have gathered I could add three signatures. There could be some other variations out there and the password protection needs to be considered. Maybe I’ll take Nick Gault’s offer and request the format which was available starting in the middle of 1995. Think they’ll deliver?