Re: Subject: Re: pdf2xy routine

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Patricia M Godfrey  on Wed, 12 Jan
2005 14:18:31 -0500


> I thought this might be the spanner in the works, because I tend to
> specify drive letters whether I need to or not. So I'd been typing
> PDF2XY d:postghst.pdf
> even though the file was in d: (Usually, my data files are in a directory
> on e, to which I have CD'd). But omitting the drive letter makes no
> difference.

Huh? You'd been "typing PDF2XY d:postghst.pdf even though
the file was in d:". That makes no sense. What are you going to do,
type z: if the file is in d:? Of course you specify d: if the file is in d:!

Usually your "data files are in a directory on e, to which I have CD'd"?
This frame couldn't care less where your data files are -- that's your
affair. All it cares is where your sourcefile (POSTGHST.PDF in your example)
is located.

"But omitting the drive letter makes no difference." Well, it makes a
HUGE difference here. The frame fails eevry time if I do it your way.
You've got two choices, only, when specifying file location -- this is
true right across the board in U2, unless otherwise noted: either the
current directory, in which case you write:
 PDF2XY postghst.pdf
or a ***fully-qualified*** filespec, in which case you write:
 PDF2XY d:\fullpath\postghst.pdf
But what you've got there is bastard DOS shorthand, neither here
nor there, fish nor fowl:
 PDF2XY d:postghst.pdf
meaning [implicit but unspecified] current dir on drive d: (which
may or may not be your current drive). Frames do NOT
evaluate what the current directory is on this or another drive if
you only specify the drive but not the dirfectory --
DOS might have a nice ASM routine for that, but we do not. XPL does
not. XPL could only evaluate an implicit directory with great
difficulty. We'd have to switch to whatever drive you've
specified, grab , then switch back to the original drive.
That's ridiculous. I don't EVER recall having offered, in
the THOUSANDS of examples I've given here, a filespec like that!
Baaaaaad habit.

I don't like your example filename, either. If I say POEM.PDF, it's
clear that there's a PDF of a poem. When you say POSTGHST.PDF -- do you
actually have a PDF of that name? Because it sounds like POSTGHST.PRN,
POSTGHST frame, POSTGHST concept... confusing, and raises unnecessary red
flags when we're trying to ELIMINATE problems. I don't want to have to
think about it, much less write about it.

Bottom line: when I do it your way, no source PDF filename is specified in the
command issued by the frame to PSTOTXT3.EXE, therefore the whole thing fails
every time. BUT!!! S/G 15 is NOT empty for me. It does contain the path
grabbed from the REGistry + PSTOTXT3.EXE, e.g. "C:\gs\gs8.15\bin\PSTOTXT3.EXE".
Whereas in your case S/G 15 is empty. At VA$M+6 = 5, you do not have OOM
(nowhere near it). And you've demonstrated (with your 101 test) that you are
successfully grabbing the path from the REGistry. So something else is screwed
up. What you need to do now is track the progress of that GS path spec and
find out where it evaporates. There is one instance of a call to child frame
XSR. Put > right after the call to XSR and see what it is
producing... If S/G 52 has content, then put > right after
the _first_ call to SFN/NV -- see what S/G 50 is coming out of that. One of
those two child frames must be the problem... IMO. I'm guessing you have a
buggy or outdated version of a child frame somewhere in your U2.

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