[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Re: New XYENC 1/13/09 release
- Subject: Re: New XYENC 1/13/09 release
- From: Carl Distefano cld@xxxxxxxx
- Date: Tue, 20 Jan 2009 01:00:17 -0500
Reply to note from wbass@xxxxxxxx Mon, 19 Jan 2009 18:52:20 -0700 (MST)
Wally:
> I think I'm in the best position to do the ongoing maintenance
> of XYENC and XYDEC programs, and you can consider me absolutely
> committed to do any maintenance to those programs that seems
> appropriate.
That is very welcome news. Since, as far as I can tell, the programs
are well nigh perfect in relation to the stationary target, XyWrite
(we'll talk about the moving target, Nota Bene, later), there should
be little maintenance to do, once you're satisfied with the code.
The more I use these programs, the more I appreciate them. Working
today on QDF4.PM (the omnibus code formatter for Xy4), I realized what
a stroke of genius it was on your part to have unflagged 3-byte
characters decode to their 1-byte counterparts. That, and the ability
to embed native XyWrite formatting within encoded matter, is what I
meant when I described the encoding system as "XyWriterly". It means
that you can reformat XYENCode output so that it looks like a native
XyWrite document -- and still have it decode perfectly. That is very
nice indeed.
Re Nota Bene:
> For the additional entries, what is your confidence level?
> Which release of NB were they obtained from, or do they
> correspond to?
I generated the table using NB v8.0A, and a modified version of my U2
FUNCTABLE routine. The latest release of NB is suffixed "I" or "J"; I
have no idea whether the function table has changed. In other words,
with respect to the latest release of NB (which I do not have), I'd
describe my confidence level as medium to low. For an authoritative
answer, contact Steve Siebert at Nota Bene.
With regard to the "moving target" problem, I'd strive for extensible
solutions rather than ad hoc ones. Changing the encoding for
underscore sounds to me like an ad hoc response to the "-D" anomaly
(although you have a point that "'_" is perhaps a more felicitous
rendering of the underscore than is "'-"). What happens, though, in
the future, when there's another character clash? Does the encoding
system change again, and what does that mean for our ability to decode
stuff that was encoded with earlier versions? But you don't need me to
ask these questions. It's clear from your remarks that you're
sensitive to them, and I'm confident you'll come up with an excellent
solution.
For my part, it would be enough if XYENC rendered func -D simply as
"~255~131~027'%'-D[CrLf]". To put it more generally, if either character
in the func's text mnemonic is incompatible with the encoding regime,
render the func as a generic 3-byter, followed by a comment with the
2-char mnemonic. Of course, this may result in a short line (less than
65 chars, or whatever the designated width is), but that's no great
shakes; better a too-short line than a too-long one. The important
point is that this rendering would be compatible with existing code. I
don't know how doable this is, but I think it would work for me.
Well, I'd better lay off coding for U2 until you know where you're
headed with the NB issue. I can hardly restrain myself, though; it's
so satisfying to work with well-built apps like yours. For the record,
here's the latest iteration of QDF4.PM. This one does a thorough
search for encodings that can be rendered as 3-byte characters, and
makes the CHanges. I've formatted some pretty tough stuff with this
routine, and it all decodes back to the original perfectly.
'%--_XYENCode_start--
',*',_Quick_&_Dirty_Format_for_XYENCode_with_XyWrite_IV_[CLD
_1/19/09]'^',*',___Usage'._RUN_QDF4.PM'^',*',_Manual_
editing_may_still_be_required'|'^',*',_(Based_on_procedure_i
n_Robert_Holmgren'`s_U2_frame_IFEI)'^',*','^'BXes_1'Q2'XP'TF
'SI',*','^'BXcia___;~['Q2',*','^'BXcia__'?<_:~<'Q2'BXcia__'?
>_:~>'Q2',*','^~~~>',*','^~~~~~~~~~~~~~~~