Re: Showing value of a s/g

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Harry Binswanger  on
Sat, 08 Sep 2007 13:16:24 -0400


> And how on earth can you read NB's tiny, gray, guillemets in NB's "codes"
> mode? You said earlier that it was no problem, but maybe
> you have some different kind of display from what I have.

Command:
 DMFONT
and increase the font size ("DMFONT"=DraftModeFONT). [Since NB
calls this "Codes Mode", perhaps we can infer that a non-NBer
wrote this interface -- guess who that would be!]

> I assume that once you are working with only NB-created files in
> NB, you can call them any old way.

No. You need to understand the problem. Fact #1: NBWin is
compatible with the old 3-byte characters of XyWrite and NBDOS;
but it concurrently accepts and preferentially uses a new system
which allows more than 255 characters. Fact #2: For chars
128-255, NBWin is based on ANSI. The primary problem for
XyWrite-to-NB conversion in the 128-255 range lies with chars
159, 222, and 223. In ANSI, these are Y-umlaut, Thorn, and
eszet. NBWin **automatically** changes these characters to
3-byte representations of themselves (according to the new
system, which yields 255+65+159, 255+65+222, and 255+65+223).
This allows them to work with the internal case conversion
tables of NBWin, and with case-INsensitive SEarches/CHanges --
if you toggle the case of Y-umlaut to y-umlaut, for example, you
get 255+65+255. That, anyway, was Siebert's concept.

This totally screws up XPL in XyWrite, which uses characters
159, 222, and 223 for many things other than human-readable
characters -- such as, duh, just being themselves, e.g. the one
hundred fifty-ninth character in the character set. It's a
disaster.

On a file-by-file basis, you can inhibit this conversion by
using CA/100. As long as you *open* the window initially with
CA/100, you can immediately switch to any other display mode
without triggering an auto-conversion of the file (although why
you'd want to do that with XPL defies explanation -- XPL should
be viewed in eXPanded mode).

Now, a global solution is to replace one file in NBWin, called
CHARUPDT.TBL, with a file I've attached below, called
CHARUPXY.TBL. If you use CHARUPXY.TBL, you can CAll XPL files
(and any other files) in any display mode -- you are not limited
to CA/100. To use CHARUPXY.TBL, you must REName CHARUPDT.TBL,
and then REName CHARUPXY.TBL as CHARUPDT.TBL, and locate it in
Editor's directory, i.e. the directory of NOTABENE.EXE.

> In this connection, I tried to paste
> into NB a RHA from a Xy document, and it didn't work--produced only
> one-byte guillemets.

Paste _how_? Using the CLIP frame from XyWrite? You've
forgotten that NBWin uses a bastardized ANSI, which retains the
guillemets on 174 and 175, instead of moving them to ANSI 171
and 187 where they ordinarily belong (which would REALLY screw
up XPL). Now, CLIP.EXE doesn't know nada about bastardized
forms of anything. It converts between genuine CodePages, and
its default is to convert from 850 to 1252 (Windows ANSI) when
moving from XyWrite to the "outer world". So what you have to
do is change the resulting ANSI guillemets 171 and 187 (which
are what you're seeing) back to 174 and 175. Then RHA will work.

CHARUPXY.TBL is attached (in a ZIPfile).

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------
Attachment:
CHARUPXY.ZIP

Description: Binary data