Re: New PostGhost and Xy2PDF frames - XyShell NOT Required

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Patricia M Godfrey  on Sun, 12 Dec
2004 19:49:56 -0500

Patricia:

Addendum to my note of yesterday re: Xy2PDF and TYP.

First, I got to thinking about what you said about "can't
remap" the printer port, and I realized (oof!) that you
can't use a PP: table, or the associated SETP command, with
a Postscript PRNfile on a USB-only system, because the PP:
table specifically associates a PRiNter file with a port
number, e.g.

1    G:\XY4\HPLJ-4.PRN     \\PSNYC\P1
LPT3  G:\XY4\POSTGHST.PRN    PostScript Ghostscript
et cetera

and you ain't got no recognized port to associate with!
Therefore, you must "LOAD" the PRN.

Second, I hope I was clear about how Xy2PDF works. It will
generate a PDF for the file in your *current window* ONLY.
You cannot specify a source filename! You must CAll the
source file first into the current window. If the file is
called PATRICIA.XY and you want to generate PATRICIA.PDF,
then the correct command is "Xy2PDF PATRICIA".

Third point: TYP has an internal routine which, if (only
if) no PRN file named "POSTsomething.PRN" (e.g.
POSTGHST.PRN) is already LOADed when you launch TYP,
looks in the PP: table to find a POST*.PRN, and SETPs
the first one it finds. For the reasons outlined above, I
just removed that whole portion of the frame; I'm gonna
insist that user has *already* LOADed or SETPed a
POSTscript.PRN file before launching TYP. (That procedure
worked for me because I have both a PCL parallel port
printer, and a networked USB printer; so I could associate
my PS PRN to an LPT port in the PP table -- but people who
are USB-only would be flummoxed.) You'll be fine as long
as you "LOAD POSTGHST.PRN" *before* you try to TYP.

Fourth:
> I even tried altering the path to include C:\gs\gs8.15\bin and
> C:\gs\ghostgum\gsview (which--am I wrong?--I didn't think one
> needed to do if they were referenced in the Xy Reg file).

No you don't need to do that. Xy2PDF actually SETs an
environment variable (GS_LIB) before it starts work. TYP
doesn't need anything additional.

Fifth:
> Would Carl and Robert sometime comment on the relative
> values of ADD2U2 and LOADHELP? The first seems (but maybe
> I did something wrong?) to leave the old frames in,
> whereas with LOADHELP you have to cut and replace the
> frames yourself, manually, thereby ensuring (if you're
> careful) that there's only one of each.

You're describing perceived effects, not the purpose or what
they actually do.

In XyWrite 4, loaded Help files like U2 and DLG cannot be
changed. Period. If they are loaded, sure, you can edit
them all you want, but it's a waste of time because you
can't *SAve* them! "Access denied". LOADHELP (short
command=LH) works around this: it lets you edit and then
SAve a **loaded** Help file -- and then it reLOADs the Help
file in its new form. So instead of command "SAVE", you
command "LOADHELP". It's as simple as that. It
has nothing to do with one copy, or two copies, or twenty
copies of a frame. That's the effect, maybe, because YOU
replaced one frame with a newer version, but LOADHELP
doesn't know about that.

ADD2U2 is specifically designed for users, and in general we
recommended that you use it when you want to add/replace a
new frame rather than do any manual insertion or editing to
U2. (If you manually edit and want to save your changes,
you have no alternative to LOADHELP.) ADD2U2 has a narrow
purpose: it inserts a frame that you have DeFined (in a
different window) at an appropriate spot in U2 (top or
bottom), and then it calls LOADHELP to save the changes
it has made. The advantage is that ADD2U2 knows where to
put the frame, and users often don't. ADD2U2 also does some
error checking to make sure that the text you've DeFined is
really a legitimate and correctly formatted program frame,
before it proceeds to insert it. And yes, ADD2U2 makes no
attempt to determine whether there is already a frame with
the same name in U2, nor does it delete any duplicate frame.
There is almost zero overhead to having an extra copy of a
frame in U2. It is also a temporary condition, because with
the next version of U2 you'll be back down to a single copy
of each frame. (Frame=Program, formatted in the special
manner these Help files require.)

> (I understand that if there is more than one
> frame of the same name, U2 honors the first in the U2
> file.)

Correct. U2 is delicate code. It works great if you leave
it alone. "But once [you] make the most meaningless trivial
change (e.g., adding a space to the text below the first
line), it no longer works." Yeah, well, I'm gonna bite my
tongue.

That said, I think you've successfully altered U2 and used
LOADHELP numerous times. If you study the structure -- and
it isn't hard to figure out what a basic frame consists of:
everything from the framename starting with
"{{5framename..." on down to the second instance of Ascii-2
(white smiley face) plus *two* carriages returns -- and you
replace and move code carefully and surgically and cleanly,
and then issue LOADHELP, you should be OK. Backups are a
wise idea.

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------