Re: Subject: Re: pdf2xy routine

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Patricia M Godfrey  on Thu, 13 Jan
2005 12:18:25 -0500


> Yes, but the sourcefile is a datafile.

And? All files are datafiles. I was responding to this:

> 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).

What I'm saying is, the "usual" location of your data files isn't germane.
What matters is where the single sourcefile is. And since it _isn't_ on e:,
what does e: have to do with anything? I don't understand what you're driving
at. Look, I'm just striving for clarity and simplicity. Not "I'd been typing
d: even though the file was in d:" I just scratch my head at stuff like that
-- no idea what it means.

> I run cd e:\xyinfo\2005  and then SE e:*.* /searchstring/  all the
> time successfully

Those are both XyWrite commands -- including the second one. In the end, after
a lot of additional processing, U2's SE command simply uses native XyWrite
services. If you think about it, it simply must use native services -- because
there just isn't any other way to search, except via the native SE command.

What is it that you suppose is happening when you command
 SE e:*.* /searchstring/ 
I trust you don't think that the search is going to automatically commence in
the roor directory, or search more than one directory -- because it isn't. It
is only going to search within the current logged directory on e: -- the
directory you were situated in when you last visited e: If you've never
visited e: since you started the session, then, yes, it will be the root dir,
and only the root dir, no subdirs. Still, it doesn't make much sense to me
UNLESS you only have one directory on e:, or you only ever care about one
directory, or you've got a really great emmeory about where you last were when
you went to e: All my drives have hundreds of subdirs, and it just wouldn't
work.

> I had never realized ... that
> one needed to give a fully qualified path name if
> the file wasn't in one's working (d:\xyw4dos) directory

That's not accurate. You must always use a fully-qualified d:\path\filename
unless the file is in the *current* directory. The CURRENT directory. If you
switch away from your "working directory" (whatever that means -- the place you
usually keep documents? Editor's directory?) -- if you CD away from that, and
you then want to operate on a file in that directory, you _must_ use a
fully-qualified filespec. There are no assumptions about "working directories"
or any other directories. In fact, in some cases -- PUTFTP, GETHTTP, etc --
you must use a fully-qualified filespec regardless. The only directory that
has any kind of special status is Editor's directory, because it's a convenient
and appropriate place to put helper files etc. -- with a user var (VA$ED) that
always points at it.

> Well, it's _your_ file: the one you created from my fontproof.

Well when I used it, it made sense! It is a printout of precisely the
character assignments coded in POSTGHST.PRN. So naturally it's called
POSTGHST.PDF. That's not the situation here. We are trying to example and
elucidate a problem.

Look at it from my standpoint. People do the silliest things around here.
Maybe not you, but -- you never know whether they think POSTGHST.PRN has some
role to play here, or maybe they're confused about the syntax; and if I don't
ask about it, then I find out five msgs later that this is in fact the problem,
or it is a contributing factor, or there is some misconception, or whatever.
So in prudence I do have to ask about it, just to spare myself trouble down the
line. I get irritated because it's a red herring, but I feel I have to deal
with it anyway.

> The similarity to
> POSTGHST.PRN could indeed be skewing things. I have, however, tried a
> couple of times with another pdf (thinking this one might be too big),
> and still failed.

Size shouldn't be a factor.

OK: so both XSR and SFN/NV are functioning correctly. Hmmm. I'm stumped. If,
coming out of the first SFN, "S/G 50=c:\gs\gs8.15\bin\pstotxt3.exe" -- well,
there isn't any more processing after that! That's the end of it. There's
just > and then S/G 15 is plugged into the DOS command. Try
putting > right after the second SFN/NV. Did something
happen to S/G 15 during the second SFN -- did it get overwritten? (That
shouldn't happen. If something was wrong there, it would be affecting Carl, it
would affect me -- we'd all lose 15 -- but we don't.)

Maybe Carl has an idea (he wrote the frame). I haven't a clue why this is
happening. You just basically debugged it, and there's nothing wrong! Makes
no sense.

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