From the v0.96 readme:
XYENC.COM is a program for encoding XyWrite files, especially XyWrite files containing XPL program content. The encoding is essentially a series of substitutions at the "character" level, keeping in mind that "characters" in the XyWrite source file can be 3 byte encoded characters, and that the character replacements in the encoded file can be multicharacter sequences, such as the sequence "~228", which is one of the permitted encodings for the character "Σ" (byte value 228 decimal). (The unaltered "Σ" encoding is also permitted.)
One intention of the programs is that the encoded file be readable by humans. Although it might first seem that such encodings would make an encoded file harder to read than the original, it is actually true that encoded files can be MUCH, MUCH easier to read than the originals. XPL programs can be very hard to read, and one of the intents of this package is to alleviate that problem.
For XyWrite III+ users, we invite you to look at the file QDF1.PM in this package, and then look at the file QDF1.ENC, which is an encoded version of QDF1.PM. XyWrite IV or later users can look at these files, and can also look at the ENCODE.PM file in this package, and compare it to an XYENC encoded version of it, ENCODE.ENC. This should give you some idea of what the package is about. (XyWrite III+ users can also look at ENCODE.ENC without problems, but ENCODE.PM is a XyWrite IV file which may cause trouble for XyWrite III+ users.)
These programs should also be usable by Notabene users, and include some support for Notabene primitive up to about version 8.0i.
There are variants of XYENC encoded files, to meet different needs. The "readability" need is illustrated by the above examples. Another need is conversion of XyWrite files to "pure ASCII" encodings, to allow handling in environments other than XyWrite, and to allow transmission of files by means such as embedding encoded text in emails.
QDF1.PM, QDF2.PM, and QDF3.PM are three XPL programs which convert the "raw" variant of encoded files into some of the other variants. These XPL programs are all designed to produce more readable variants of encoded files.
XYDEC.COM is a companion program which "decodes" the encodings produced by XYENC. The reformatting operations done by QDF1, QDF2, and QDF3 to not interfere with the ability of XYDEC to decode back to the original.
XyWrite as delivered by the factory is notoriously under documented, particularly with regard to some implementation notions (such as 3 byte encoded data characters) that one really needs to understand to use XyWrite well. Over time, Herbert Tyson's superb "XyWrite Revealed" book, and a number of excellent notes by Carl Distefano and Robert Holmgren have been extremely useful in filling the documentation void.
I have been working on my own set of notes concerning these implementation details. My notes differ considerably in approach from Tyson's, Distefano's, and Homgren's works in that they attempt to rationalize how and why things in the implementation got to be the way they are. For me, and presumably some readers who are like me, a how-it-got-that-way approach makes things easier to understand and remember. Other will no doubt find the prevailing Tyson/Distefano/Homgren works more to their liking. Some may find value in reading both
These notes assume a reader that would be comfortable using a typical DOS full screen editor. They do not assume (or try not to assume) a reader who knows XyWrite at all. A secondary goal, in fact, it to allow a reader unfamiliar with XyWrite to get a sense of what XyWrite was/is, and "what the XyWrite fuss was all about" (even now, more then 15 years after XyWrite III+'s demise, many folks still declare it their favorite word processor/editor, and still use it).
However, the notes are written using XyWrite, which leaves a reader without XyWrite with a problem in reading the notes. Occasionally, when they seem at least momentarily stable, the notes are translated into html, so some of the notes are available for html viewing. The html versions are often downlevel, however.
The organizational idea that I had when I started the notes was that I would write an overview, which would briefly introduce and discuss XyWrite's approach to several topics common to many word processors/editors, those topics being (a) keyboard mapping, (b) screen, buffers, command line, embedded commands, (c) character set and file format, (d) primitive functions, (e) some local macro buffers that XyWrite calls "Save/Gets", (f) macros and programming facilities, and (g) the help system. Then, following the overview which touched on all of these, I would write a followup section on each of the above, filling in whatever details I thought were important. I didn't plan any farther than that
At the moment, there is a fairly good first pass completed on the overview sections, except that the help system section is badly lacking. The good news is that the overview sections are much more complete in their own right than I even dreamed that they would be, and for some of the sections, I don't think that there is a lot more that I need to write. The bad news is that only the keyboard section currently has a detailed followup section written at all.
I think the existing documents might fact be quite useful/interesting to many readers. Even at the introductory level that they are directed at, the notes reveal perhaps even most of the important "tricks" that XyWrite never documented, but that one eventually needs to know to use XyWrite well.
What these notes DON'T do, is any kind of "here are all of the commands and what they do" kind of documentation. Maybe, some day, I will be able to add that, but for now (a) I have nothing useful to add to existing documentation that is organized that way, and (b) I just can't justify giving that kind of documentation any kind of priority.
Work on these notes has not stopped (as of 1/2009), but at the moment is second priority to other XyWrite work that I am doing.
As is. Constructed by me. Width tables are believed to be quite accurate. Only for printers that have corresponding built in fonts (e.g., no notion of font downloading is supported).