Uwe Stöhr wrote: > Using dvips shouldn't cause troubles where have you read this?
comp.text.tex or de.comp.text.tex. I can't find it now. > dvips is > for example also the default driver of hyperref and therefore also used > when producing DVI and PDF files. But dvipdfm takes the ready DVI-file so > it is driver independent. I don't understand. dvips is a converter from dvi to PostScript, dvipdfm is a converter from dvi to PDF. Both start from the dvi file. The point is that geometry inserts dvi specials that might confuse dvipdfm or other post-dvi tools. > All you get is this warning: > > [1 > ** WARNING ** Unparsed material at end of special ignored. > Current input buffer is -->! /landplus90 true store<-- > ] I see. > This can be ignored this has no consequences an tells that the input DVI > file is in landscape. When this message doesn't appear dvipdfm doesn't > recognize the landscape format and produces ugly PDFs. So not using dvips > is makes it more worse than using dvips because using the dvips driver > also fixes the bug when using dvipdfm! I didn't say that your solution does not improve the current situation. It does. However, I don't like hardcoding dvips instead of chosing the appropriate driver if we can do better. > I tested this with with various > larger documents. dvipdfm is not under development since 5 years now and > therefore not recommended to use. But there's dvipdfmx. And some people just prefer dvipdfm over pdflatex (for instance, because it generates smaller files). > So we should also use this when using dvipdfm. To rephrase: the correct solution is not to hardcode a driver, but to use always the correct one. That is, dvips when dvips is used, dvipdfm when dvipdfm is used and pdftex when pdflatex is used. It might turn out that this is not so easy, I didn't have a closer look at the code. Then your solution is probably better than the current solution. Jürgen
