[tex-live] dvipdfmx warnings
Zdenek Wagner
zdenek.wagner at gmail.com
Sun Dec 1 23:39:04 CET 2013
2013/12/1 Bob Tennent <rdt at cs.queensu.ca>:
> >|> It seems the solution is to use
> >|>
> >|> \usepackage[driver=dvipdfm]{geometry}
> >|>
> >|The geometry package can test for latex, pdflatex, xelatex (and
> >|lualatex?) but if you are using latex it has no way of ``knowing'' what
> >|backend processing is going to be used to go from dvi->pdf; the default
> >|it uses is dvips->... since that is the most common path. So for any other
> >|backend processing you have to explicitely tell geometry what to use.
>
> Hi Herb. Other packages (hyperref, graphicx) seem to be able to
> figure it out witthout an explicit option, presumably from the
> global option. Also, it is somewhat confusing that sometimes one
> must use dvipdfmx and sometimes one must use dvipdfm and sometimes
> either will do. It doesn't help that there is not even a man page
> for dvipdfmx. I sent my complaint here because there seemed to be no
> other suitable venue.
>
The packages can reliably recognize XeTeX, pdftex, luatex and can
recognize whether PDF or DVI is being created. It cannot be recognized
how you will process the DVI file later. (x)dvipdfm(x) understands
some (but not all) postscript specials and some (but not all) pdftex
specials. If the package assumes that DVI will be processed by dvips
and emits only such specials that are understood by (x)dvipdfm(x), you
get no error (my zwpagelayout does that). If the package may use a
special that is understood by one DVI driver and not understood by
another DVI driver, you have to specify which DVI driver you intend to
use.
> Best,
> Bob T.
--
Zdeněk Wagner
http://hroch486.icpf.cas.cz/wagner/
http://icebearsoft.euweb.cz
More information about the tex-live
mailing list