On Thu, 24 Apr 2008 16:25:48 +0200, Andreas Hoenen
<[EMAIL PROTECTED]> wrote:
> It would be nice to be able to use TEXINPUTS to override the search
> path for TeX files as well. Unfortunately, dblatex modifies
> TEXINPUTS so that its own files will take precedence (unlike
> PYTHONPATH.)
Actually, since the TeX files are in /usr/share/texmf (per
Debian policy), no update_texinputs() invocation should be
necessary. Perhaps, it could be commented out for the Debian
package.
Intermediate summary of using dblatex files installed in parallel:
- Python: Use environment variable PYTHONPATH.
- TeX: Ivan's suggestion works, thus after patching Debian dblatex to
omit the superfluous manipulation of TEXINPUTS, use environment
variable TEXINPUTS.
- XSLT: As no environment variable is used here, dblatex would have to
be modified upstream. Benoît, are you willing to enhance
dblatex accordingly?
There's something I don't understand: what the customization is for? In my
opinion, there are two possible cases:
- One wants to hack the package, for debug purpose, experiment it, and so
on, with no maintenability in mind. In this case, he should start from the
sourceforge tarball, since you can work as standalone with it, patch it,
etc. with no interaction with system wide installed dblatex (the
scripts/dblatex stub is provided for that).
- One wants to customize the installed package. In this case he should
provide his own .sty, and require/include the default latex style files as
needed. For the XSL part, he should provide his own XSL entry point (-p
option), and override the necessary templates in it (that's one of the XSL
strengths). The benefit is to separate clearly what is specific from what
is not, and you can even manage the differences as an extension package.
Exploding the paths of the tool is somewhat dangerous: unconsistent XSL
stylesheets vs latex stylesheets, etc. The only case where giving another
xsldir can be interesting is for the debian packager, where the xsldir
location differs from the default dblatex XSL location (no more need to
have symbolic link). But for this particular case an environment variable
is not suited, and I must thing about something else. In general, playing
with multiple environment variables to override some stuff is not a good
idea.
Regards,
BG
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
