[plt-scheme] 299.404

MzScheme and MrEd are now version 299.404 in the SVN repository trunk.

 !! IMPORTANT !!
 The format for "graphical" editor files has changed, so that non-text
 files saved in DrScheme 299.404 cannot be opened in earlier versions.
 Of course, files saved in earlier versions will open in 299.404.

 !! EVEN MORE IMPORTANT !!
 With this format change, there's a higher-than-usual risk of bugs that
 will lose your data. I think the current implementation is probably
 right, otherwise I wouldn't try to release it as 299.404. However,
 I've already found and fixed a bug since I first decided that the
 code was probably right. (Fortunately, my lost very little work.)
 So, upgrade with more caution than usual.

The 299.404 change replaces DrScheme's "binary" format for non-text
files. The new format is an ASCII encoding. The binary format was one
of my worst design mistakes in MrEd; this mistake turned into disaster
in 299.200, where a bug caused graphical files to be opened in 'text
mode instead of 'binary mode for output, so that the resulting file was
unreadable.

In the new format, after the first 12 bytes, the file contains sequence
of Scheme numbers, byte strings, lists containing byte strings, and
comments. MrEd/DrScheme generates output so that no line is longer than
72 characters, and the last line ends with a newline. Unquoted
whitespace is flexible, as usual for a sequence of S-expressions, and
quoted tabs, returns, and newlines are printed as \t, \r, and \n.

The new format was implemented by changing MrEd's editor-stream-in% and
editor-stream-out% classes. This implementation strategy means that no
other editor code has to change for output, and all old editor code
works for input with both the old and new formats. The implementation
strategy also means, however, that the new format is as unreadable to
humans as the old one. A good format would have more S-expression
grouping, booleans and symbols in place of certain numbers, no
redundant string-length numbers, etc.; this better format would require
adapting all code that manipulates editor streams, and it would make
reading two different formats more difficult. Meanwhile, the current
change avoids the biggest problems of a "binary" format: the file's
content is intact if it is transferred in text mode, sent unquoted
through e-mail, [de-]encoded as UTF-8/Latin-1/etc., or read/written in
'text mode.

For now, the file format is still defined only by its "executable
specification" (i.e., the source code). I expect to create a more
readable specification and put it in the documentation, eventually.


Other changes in 299.404:

 * When drawing to PostScript, text height is measured from descent to
   ascent, instead of from baseline to baseline (shifted by the
   descent). This makes PostScript drawing more consistent with
   screen/bitmsap drawing on all platforms.


Matthew