Menu
▾
▴
#68 use KPSE_DOT expansion
Sometimes xdvi fails to fully display a document if
includes external parts, e.g., graphics. This happens,
if each of the following is true:
- it includes parts (graphics) that are located in a
directory other than the directory of the document
- these parts are found via environment variables,
e.g., TEXINPUTS. For example, mine includes
export TEXINPUTS=:.:./Bilder:
and all graphics of my documents are kept in a
subfolder Bilder
- xdvi is run from a directory other than the directory
of the document
In my case, this often happens if I use mozilla to view
dvi files (via helper applications) as mozilla is
almost always started in a different directore.
This could be overcome by using the KPSE_DOT
environment variable. In case xdvi cannot locate a
file, it could set KPSE_DOT to the directory of the
dvi-file and restart the search.
Of course, afterwards KPSE_DOT should be restored to
its original value.
[I would have programmed it myself but I'm a novice in
using environment variables from programs, not
mentioning the problem of makeing it work on 100 + 1
operating system]
Uli
Logged In: YES
user_id=177175
> export TEXINPUTS=:.:./Bilder:
hmm, couldn't you put the full path there? For me this works
without any problems, e.g. (assuming all files are under ~/tex):
export TEXINPUTS=.:~/tex//:
The behaviour of xdvik should be parallel to dvips IMHO, and
as far as I can see it is.
> In my case, this often happens if I use mozilla to view
> dvi files (via helper applications)
if you have embedded files, don't these need to be inside
the same directory as the .dvi file (/tmp in this case)? If
you only have the DVI file, embedded graphics won't work
anyway - you'd need a .tar.gz file including all embedded
files for that (that's supposed to be handled by xdvizilla).
> This could be overcome by using the KPSE_DOT
> environment variable.
I'm not sure if this would be the best solution ... kpathsea
info says about KPSE_DOT `You should not ever define it
yourself.'. I'm not sure what that means, but it sounds as
if it would be a bad idea to set it from within xdvi ...
wouldn't it be easier to set it in the environment, e.g. the
wrapper script, if this was the route to go?
Logged In: YES
user_id=810188
> > export TEXINPUTS=:.:./Bilder:
> hmm, couldn't you put the full path there?
No, that's the purpose of "./Bilder". It means that every
document has its own folder and has a subdirectory Bilder
with its graphics.
> wouldn't it be easier to set [KPSE_DOT] in the environment
I guess, it's the other way around: It seems to be dangerous
to (permanently) set KPSE_DOT in the environment because it
might get overwritten. There should be no problem in
setting KPSE_DOT in xdvi, using kpathsea, and then restoring
the original value of KPSE_DOT.
> e.g. the wrapper script, if this was the route to go?
That might be a good workaround for the first file. But
then, if you open another file in a different directory, the
current directory would still be the one of the first
document and you'd have the same problem.
Uli
Logged In: YES
user_id=177175
> That might be a good workaround for the first file. But
> then, if you open another file in a different directory, the
> current directory would still be the one of the first
> document and you'd have the same problem.
OK ,that makes sense.
Unfortunately I didn't manage to get KPSE_DOT to work - it
seem that setting it later in the program doesn't have any
effect (even though it does seem to get evaluated each time
one of the kpse_ functions is used - I had a quick look at
kpathsea/expand.c to confirm this).
My attempt is attached below for reference; it works if the
path reported by the printf() is set in the shell before
starting xdvi ...
patch to use KPSE_DOT, doesn't work
Logged In: YES
user_id=810188
> Unfortunately I didn't manage to get KPSE_DOT to work
I think it depends on kpse_file_format_type. For example,
it works if you encapsulate the call to find_file in util.c,
i.e.,
char *expanded_filename = NULL;
struct stat statbuf;
char *curr_kpse_dot = getenv("KPSE_DOT");
setenv("KPSE_DOT", globals.dvi_file.dirname, 1);
expanded_filename = find_file(filename, &statbuf,
pathinfo);
Then the fourth case in find_file succeeds. I don't know
what's the vaule of pathinfo in this case.
Uli
Logged In: YES
user_id=177175
> I think it depends on kpse_file_format_type. For example,
> it works if you encapsulate the call to find_file in util.c
Ah, good find!
> I don't know
> what's the vaule of pathinfo in this case.
it's 25 (kpse_pict_format), but that's the same in all
cases. It seems that a result for a path expansion for a
specific file type is cached; I checked this by inserting
printf() statements into kpse_expand_kpse_dot, expand.c in
kpathsearch. These are printed only for the first invocation
of kpse_find_file for a specific file type. So setting
KPSE_DOT after the first find_file() in send_ps_file is too
late, and it works if it is set before find_file().
However, I'm a bit sceptical about setting KPSE_DOT
unconditionally, since it breaks strict dvips
compatibility, and I'm not 100% sure that it won't cause
problems in other cases. Maybe we could make it an #ifdef ...
Logged In: YES
user_id=810188
I've talked to Olaf Weber, one of the authors of kpathsea.
He says:
- KPSE_DOT is a hack that may or may not continue to work.
- KPSE_DOT cannot be used more than once. If you want to
reuse it, you have to restart kpathsea.
- a real way to do what [I have suggested] will take some actual
work.
On the other hand, KPSE_DOT suffices fot my cause. I now use
xdvi from mozilla via the bash script
export KPSE_DOT=${1%/*}
xdvi "$1"
where $1 contains the full path to the dvi-file.
My suggestion is:
Mention the problem with file search and the local
$TEXINPUTS in the documentation (maybe under "known issues")
together with a reference to kpathsea/KPSE_DOT, its
problems, and an example.
Uli
Logged In: YES
user_id=177175
> I've talked to Olaf Weber, one of the authors of kpathsea.
Great! Thanks very much for sorting this out. It sounds
indeed as if KPSE_DOT wasn't the right thing to use in xdvik ;-)
> My suggestion is:
> Mention the problem with file search and the local
> $TEXINPUTS in the documentation
OK, I will.