Bug 1288301

Could you please provide the following information:

- How do you reproduce the problem? (exact commandline)

- Has this worked before? (say with dblatex-0.3.5 instead of dblatex-0.3.6 if that is what you are using, or with Fedora 22 instead of Fedora 23)

> - How do you reproduce the problem? (exact commandline)
The commandline is :
dblatex -t tex --texstyle=amcdocstyle --xslt-opts="--nonet" --xslt-opts="--catalogs" auto-multiple-choice.en.xml -o auto-multiple-choice.en.tex

It's not my commandline, it appears during building (Makefile) the software 
 auto-multiple-choice (https://bitbucket.org/auto-multiple-choice/auto-multiple-choice)

> - Has this worked before? 
I don't know, it's my first time using it.

The problem is related to the use of <warning> (and similar)  in a DocBook document.
With attached w.xml,

  dblatex -t tex w.xml
  pdflatex w.tex

ends with an error:

! LaTeX Error: File `warning' not found.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...                                              

l.285 \begin{DBKadmonition}{warning}{Important}

LaTeX can't find the drawing 'warning.pdf' which is shipped with dblatex but not in the LaTeX tree.

'dblatex w.xml' works, because pdflatex is run with modified TEXINPUTS.
On debian, dblatex's 'warning.pdf' is located in the LaTeX tree.
If including dblatex graphics files in LaTeX tree is unwanted on Fedora, is there an easy way for the user to get the path leading to them, so that he can run a successful pdflatex modifying TEXINPUTS?

Created attachment 1102536 [details]
DocBook test file

Created attachment 1102537 [details]
DocBook test file

Sorry, this is the right one.

TEXINPUTS=/usr/share/dblatex/latex/graphics/: pdflatex w.tex

works. Really, the problem is not the use "of warning" but the use of a non-stand
ard mode ("-t tex") without setting the search path in the same way as dblatex does for its own processing.

I'm really wondering whether we should support that - if yes, then all the graphics files would need to be copied or moved inside the latex tree.

The strange thing is that dblatex undertakes quite some efforts to set TEXINPUTS appropriately, without relying on distributions or setup.py to put its files into the standard latex tree. That would be moot if we put everything there, so I don't think that its tex output is supposed to work out of the box.

I understand that dblatex was designed to let its graphics files outside the latex tree, so that a dblatex package can't be blamed to respect this.
Do you know a simple way to get the path to the dblatex graphics directory? Maybe assuming it is /usr/share/dblatex/latex/graphics/ won't work in all situations. I need to use the tex output to run platex instead of pdflatex for japanese DocBook documents.

If the way in which you want to use "-t tex" is the way dblatex is meant to be used, than by all means we should copy those files to the standard LaTeX tree.

Alas, the documentation of dblatex does not mention that as part of the installation procedure, but leaves those files in /usr/share. Therefore, I'm leaning towards doing it the same way (i.e. leave the package as is).

dblatex does not provide any way to override the latex engine, unfortunately. Two possible workarounds:

1) "monkey patch", i.e. set up a "pdflatex" in your PATH which calls "platex":

--->%--- pdflatex
#!/bin/sh
exec platex "$@"
--->%---

2) read the paths from dblatex:

2a) either get the package_base from the dblatex script:

sed -ne 's/package_base.*"\(.*\)".*/\1/p' $(which dblatex)

gives /usr/share/dblatex for me.

2b) or use dblatex's texpost feature to get the exact environment it uses:

--->%--- d.sh
#!/bin/sh
env > dblatex.env
--->%---

dblatex -r ./d.sh   w.xml

That will put the environment in a file dlatex.env, which in my case contains:

TEXINPUTS=/usr/share/dblatex/latex/style//::/usr/share/dblatex/latex//

But really, if you need to jump through these hoops for japanese TeXing then maybe upstream (dblatex) should provide a way to override the TeX compiler. Or are there any packages that would the same job? That would lead to possibility

3) Use the "-r" switch to transform the TeX file before dbaltex calls pdflatex.

Thank you very much for your help: these are good solutions for my problem.

Closing as NOTABUG for now.

Upstream could make it easier for users of "-t tex", though.