Re: [patch] fix bug 2721 now with attached patch
Uwe Stöhr wrote: [1 ** WARNING ** Unparsed material at end of special ignored. Current input buffer is --! /landplus90 true store-- ] 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 tested this with with various larger documents. dvipdfm is not under development since 5 years now and therefore not recommended to use. So we should also use this when using dvipdfm. Meanwhile, I had a look at geometry.sty. In fact, the options dvips and dvipdfm insert the same specials except that dvips additionally inserts the landscape correction, which is, as you describe above, just skipped by dvipdfm. In the view of this, I'd say implementing the more elegant solution (which needed to implement an output param driver and pass that to writeLaTeX, is not worth it. So, I finally think you should shove your latest patch in (trunk). Jürgen
Re: [patch] fix bug 2721 now with attached patch
Jürgen wrote: 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. I know that this is confusing, but in this case dvips is the driver which is also used when you simply run latex test.tex An this is what the patch is for. 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. I tested this again and you are right. But how can this be achieved? In converter.C there is already a routine that checks for the landscape format to use the correct calling parameter if (bp.orientation == ORIENTATION_LANDSCAPE) result += -l; But the entry in the LaTeX-file has to be made in bufferparams.C. I'm a code newbie so can you help me here? I would add a variable to store the information what converter is used. How can this variable later be used for bufferparams.C? 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). Btw. Are the files really smaller? So there's a good new that the PDF filesize is now smaller with the new pdftex 1.4. regards Uwe
Re: [patch] fix bug 2721 now with attached patch
Uwe Stöhr wrote: But the entry in the LaTeX-file has to be made in bufferparams.C. I'm a code newbie so can you help me here? I would add a variable to store the information what converter is used. How can this variable later be used for bufferparams.C? I think you'd need to add a driver param to outputparams.[Ch], which is set in Converters::convert. In buffer.C, writeLaTeXSource, this param is queried and then passed to params().writeLaTeX (which would need an additonal param string const driver). But as I wrote in my last mail, I'm not sure anymore it's worth the effort. 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). Btw. Are the files really smaller? Sometimes, yes (depends on the contents) So there's a good new that the PDF filesize is now smaller with the new pdftex 1.4. I know. Still, dvipdfm has the advantage to support dvi specials. So, for instance, change tracking is visible in LyX. Jürgen
Re: [patch] fix bug 2721 now with attached patch
Uwe Stöhr wrote: > [1 > ** WARNING ** Unparsed material at end of special ignored. > Current input buffer is -->! /landplus90 true store<-- > ] > > 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 tested this with with various larger > documents. dvipdfm is not under development since 5 years now and therefore > not recommended to use. So we should also use this when using dvipdfm. Meanwhile, I had a look at geometry.sty. In fact, the options dvips and dvipdfm insert the same specials except that dvips additionally inserts the landscape correction, which is, as you describe above, just skipped by dvipdfm. In the view of this, I'd say implementing the more elegant solution (which needed to implement an output param "driver" and pass that to writeLaTeX, is not worth it. So, I finally think you should shove your latest patch in (trunk). Jürgen
Re: [patch] fix bug 2721 now with attached patch
Jürgen wrote: 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. I know that this is confusing, but in this case dvips is the driver which is also used when you simply run latex test.tex An this is what the patch is for. 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. I tested this again and you are right. But how can this be achieved? In converter.C there is already a routine that checks for the landscape format to use the correct calling parameter if (bp.orientation == ORIENTATION_LANDSCAPE) result += " -l"; But the entry in the LaTeX-file has to be made in bufferparams.C. I'm a code newbie so can you help me here? I would add a variable to store the information what converter is used. How can this variable later be used for bufferparams.C? 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). Btw. Are the files really smaller? So there's a good new that the PDF filesize is now smaller with the new pdftex 1.4. regards Uwe
Re: [patch] fix bug 2721 now with attached patch
Uwe Stöhr wrote: > But the entry in the LaTeX-file has to be made in bufferparams.C. I'm a > code newbie so can you help me here? I would add a variable to store the > information what converter is used. How can this variable later be used for > bufferparams.C? I think you'd need to add a "driver" param to outputparams.[Ch], which is set in Converters::convert. In buffer.C, writeLaTeXSource, this param is queried and then passed to params().writeLaTeX (which would need an additonal param string const & driver). But as I wrote in my last mail, I'm not sure anymore it's worth the effort. > >> 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). > > Btw. Are the files really smaller? Sometimes, yes (depends on the contents) > So there's a good new that the PDF > filesize is now smaller with the new pdftex 1.4. I know. Still, dvipdfm has the advantage to support dvi specials. So, for instance, change tracking is visible in LyX. Jürgen
Re: [patch] fix bug 2721 now with attached patch
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
Re: [patch] fix bug 2721 now with attached patch
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
Re: [patch] fix bug 2721 now with attached patch
I think it is correct to use this option. However, even if it does not harm
when using pdflatex, I've read that you have to expect errors if you're
using another dvi-to-something driver that does not understand the dvi
specials this option inserts (for instance: dvipdfm and dvipdfmx).
So I'd prefer to insert this option only if we are actually exporting via
dvips.
Using dvips shouldn't cause troubles where have you read this? 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. All you get is this warning:
[1
** WARNING ** Unparsed material at end of special ignored.
Current input buffer is --! /landplus90 true store--
]
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 tested this with with various larger documents.
dvipdfm is not under development since 5 years now and therefore not
recommended to use.
So we should also use this when using dvipdfm.
Furthermore, this should not be inserted as an option to the usepackage
command, but as an argument to the \geometry{} command, as we do for all the
other options.
See some lines below in bufferparams.C.
OK, updated patch attached.
regards Uwe.
Index: bufferparams.C
===
--- bufferparams.C (revision 16655)
+++ bufferparams.C (working copy)
@@ -883,7 +883,7 @@
texrow.newline();
os \\geometry{verbose;
if (orientation == ORIENTATION_LANDSCAPE)
- os ,landscape;
+ os ,landscape,dvips;
switch (papersize) {
case PAPER_CUSTOM:
if (!paperwidth.empty())
Re: [patch] fix bug 2721 now with attached patch
>> I think it is correct to use this option. However, even if it does not harm
>> when using pdflatex, I've read that you have to expect errors if you're
>> using another dvi-to-something driver that does not understand the dvi
>> specials this option inserts (for instance: dvipdfm and dvipdfmx).
>> So I'd prefer to insert this option only if we are actually exporting via
>> dvips.
Using dvips shouldn't cause troubles where have you read this? 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. All you get is this warning:
[1
** WARNING ** Unparsed material at end of special ignored.
Current input buffer is -->! /landplus90 true store<--
]
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 tested this with with various larger documents.
dvipdfm is not under development since 5 years now and therefore not
recommended to use.
So we should also use this when using dvipdfm.
> Furthermore, this should not be inserted as an option to the usepackage
> command, but as an argument to the \geometry{} command, as we do for all the
> other options.
> See some lines below in bufferparams.C.
OK, updated patch attached.
regards Uwe.
Index: bufferparams.C
===
--- bufferparams.C (revision 16655)
+++ bufferparams.C (working copy)
@@ -883,7 +883,7 @@
texrow.newline();
os << "\\geometry{verbose";
if (orientation == ORIENTATION_LANDSCAPE)
- os << ",landscape";
+ os << ",landscape,dvips";
switch (papersize) {
case PAPER_CUSTOM:
if (!paperwidth.empty())
Re: [patch] fix bug 2721 now with attached patch
LyX creates dvi documents without proper dimension information
http://bugzilla.lyx.org/show_bug.cgi?id=2721
Simply add the [dvips] option to the geometry package when landscape is
used.
Opinions?
regards Uwe
Index: bufferparams.C
===
--- bufferparams.C (revision 16619)
+++ bufferparams.C (working copy)
@@ -879,7 +879,10 @@
}
if (use_geometry || nonstandard_papersize) {
- os \\usepackage{geometry}\n;
+ if (orientation == ORIENTATION_LANDSCAPE) {
+ os \\usepackage[dvips]{geometry}\n;}
+ else {
+ os \\usepackage{geometry}\n;}
texrow.newline();
os \\geometry{verbose;
if (orientation == ORIENTATION_LANDSCAPE)
Re: [patch] fix bug 2721 now with attached patch
Uwe Stöhr wrote: Opinions? I think it is correct to use this option. However, even if it does not harm when using pdflatex, I've read that you have to expect errors if you're using another dvi-to-something driver that does not understand the dvi specials this option inserts (for instance: dvipdfm and dvipdfmx). So I'd prefer to insert this option only if we are actually exporting via dvips. Jürgen
Re: [patch] fix bug 2721 now with attached patch
Jürgen Spitzmüller wrote:
Opinions?
I think it is correct to use this option. However, even if it does not harm
when using pdflatex, I've read that you have to expect errors if you're
using another dvi-to-something driver that does not understand the dvi
specials this option inserts (for instance: dvipdfm and dvipdfmx).
So I'd prefer to insert this option only if we are actually exporting via
dvips.
Furthermore, this should not be inserted as an option to the usepackage
command, but as an argument to the \geometry{} command, as we do for all the
other options.
See some lines below in bufferparams.C.
Jürgen
Re: [patch] fix bug 2721 now with attached patch
LyX creates dvi documents without proper dimension information
http://bugzilla.lyx.org/show_bug.cgi?id=2721
Simply add the [dvips] option to the geometry package when landscape is
used.
Opinions?
regards Uwe
Index: bufferparams.C
===
--- bufferparams.C (revision 16619)
+++ bufferparams.C (working copy)
@@ -879,7 +879,10 @@
}
if (use_geometry || nonstandard_papersize) {
- os << "\\usepackage{geometry}\n";
+ if (orientation == ORIENTATION_LANDSCAPE) {
+ os << "\\usepackage[dvips]{geometry}\n";}
+ else {
+ os << "\\usepackage{geometry}\n";}
texrow.newline();
os << "\\geometry{verbose";
if (orientation == ORIENTATION_LANDSCAPE)
Re: [patch] fix bug 2721 now with attached patch
Uwe Stöhr wrote: > Opinions? I think it is correct to use this option. However, even if it does not harm when using pdflatex, I've read that you have to expect errors if you're using another dvi-to-something driver that does not understand the dvi specials this option inserts (for instance: dvipdfm and dvipdfmx). So I'd prefer to insert this option only if we are actually exporting via dvips. Jürgen
Re: [patch] fix bug 2721 now with attached patch
Jürgen Spitzmüller wrote:
> > Opinions?
>
> I think it is correct to use this option. However, even if it does not harm
> when using pdflatex, I've read that you have to expect errors if you're
> using another dvi-to-something driver that does not understand the dvi
> specials this option inserts (for instance: dvipdfm and dvipdfmx).
>
> So I'd prefer to insert this option only if we are actually exporting via
> dvips.
Furthermore, this should not be inserted as an option to the usepackage
command, but as an argument to the \geometry{} command, as we do for all the
other options.
See some lines below in bufferparams.C.
Jürgen
