Re: Trouble with eps inclusions in lyx-1.4.1
Date: Thu, 1 Jun 2006 22:41:11 -0500 From: Paul Johnson [EMAIL PROTECTED] To: lyx-users@lists.lyx.org Subject: Re: Trouble with eps inclusions in lyx-1.4.1 Well, this seems like a serious problem, not one where we should say there's nothing to do. I'd suggest that LyX SHOULD NOT offer to export documents to pdf when they have eps files in them, or at least users need a VERY BIG warning because a lot of users will get in trouble unless they proof read their output very carefully. A bug of this sort, which crops up after a project is finished and printed out and presented to students/teachers, and appears only later in pdf output intended for the Web, is very serious. Sure, this problem gave me headaches until I discovered the Autorotate switch and patched it in a ps2pdf wrapper (epstopdf includes it by default since TL2005). However, why should LyX behave differently with eps graphics than with other kinds of graphics ? The current paradigm is to build output regardless of the type of graphic source, using internal conversion. With pdfatex, your problem came from a badly configured eps file (disagreement between the .eps extension and the magic number in the file (no EPSF in the first line, which lead lyx to believe that it was a PS file). As I stated, ps2pdf conversion of individual figures could be avoided by giving precedence on extension over magic number when there is disagreement. As for the ps2pdf conversion alone (DVI-PDF), I wonder if the autorotate switch should be included a default in the converter section. It's easier to remove a switch than to add one which you never heard of. Two converters (one w/autorotate, one without it) is perhaps an overkill. Of course, autorotation could be set on a figure by figure basis in the graphics menu, and on a general basis with a checkbox. If tex2pdf works, couldn't LyX incorporate that (its GPL, right?) and cut all usage of the other converters? I've seen it fail, but mostly on latex files not created with lyX, and with older versions of epstopdf. But I use it a lot (manages metadata, hyperref, indexes, glossaries, ... for you, without extra coding in the source). -- Jean-Pierre
Re: Trouble with eps inclusions in lyx-1.4.1
Paul Johnson wrote: Well, this seems like a serious problem, not one where we should say there's nothing to do. I did not say that. I said that I don't see a solution that will work in all cases. I'd suggest that LyX SHOULD NOT offer to export documents to pdf when they have eps files in them, or at least users need a VERY BIG warning because a lot of users will get in trouble unless they proof read their output very carefully. A bug of this sort, which crops up after a project is finished and printed out and presented to students/teachers, and appears only later in pdf output intended for the Web, is very serious. This is a disadvantage of the modular converter architecture. Since LyX has no control over the used tools, bad things can happen. There is a similar problem with bitmap images: If you specify a 50% scale, it entirely depends on the converter how big the image will be in the output, since it needs to assume a certain resolution (pixels per cm). If tex2pdf works, couldn't LyX incorporate that (its GPL, right?) and cut all usage of the other converters? I don't know how good tex2pdf is, but you can easily create a new pdf4 format and define tex2pdf as a converter tex-pdf4 yourself. Any tex2pdf experts please tell: Should we do that by default in LyX? Any possible problems? Georg
Re: Trouble with eps inclusions in lyx-1.4.1
To: lyx-users@lists.lyx.org From: Georg Baum [EMAIL PROTECTED] Subject: Re: Trouble with eps inclusions in lyx-1.4.1 Date: Fri, 02 Jun 2006 16:37:31 +0200 Paul Johnson wrote: Well, this seems like a serious problem, not one where we should say there's nothing to do. I did not say that. I said that I don't see a solution that will work in all cases. I'd suggest that LyX SHOULD NOT offer to export documents to pdf when they have eps files in them, or at least users need a VERY BIG warning because a lot of users will get in trouble unless they proof read their output very carefully. A bug of this sort, which crops up after a project is finished and printed out and presented to students/teachers, and appears only later in pdf output intended for the Web, is very serious. This is a disadvantage of the modular converter architecture. Since LyX has no control over the used tools, bad things can happen. There is a similar problem with bitmap images: If you specify a 50% scale, it entirely depends on the converter how big the image will be in the output, since it needs to assume a certain resolution (pixels per cm). If tex2pdf works, couldn't LyX incorporate that (its GPL, right?) and cut all usage of the other converters? I don't know how good tex2pdf is, but you can easily create a new pdf4 format and define tex2pdf as a converter tex-pdf4 yourself. Any tex2pdf experts please tell: Should we do that by default in LyX? Any possible problems? I've used it with success since the perl versions (tehere has been a lyx2pdf and tex2pdf bash ones), and contributed a little (Steffen Eversand Oscar Lopez did most of the job involved in the current perl port), and yes, I have a pdf1 format associated to tex2pdf conversion :-) \format pdf1 pdf PDF (tex2pdf) x xpdf \converter latex pdf1 tex2pdf $$i The situations where tex2pdf gets into trouble comes mostly with latex files: use of other packages than graphicx, insertion of graphics with user-defined macros, etc. which kill the parsing for graphics names. Use with LyX seems not concerned as the latex code is clean. Another reason of failure came from unproper constructs used in \title and \author fields (used to produce pdf metadata), but again this should less happen in LyX. In addition to pdf compilation, and with the help of a configuration file (defaults are reasonable), tex2pdf provides full hyperref control, makeindex control, etc. So the command in the converter section is simple, the customization will be in the config file. Presence can be checked and the format and converter commands installed. HTH -- Jean-Pierre
Re: Trouble with eps inclusions in lyx-1.4.1
Jean-Pierre Chretien wrote: With pdfatex, your problem came from a badly configured eps file (disagreement between the .eps extension and the magic number in the file (no EPSF in the first line, which lead lyx to believe that it was a PS file). As I stated, ps2pdf conversion of individual figures could be avoided by giving precedence on extension over magic number when there is disagreement. I don't like that approach, because I have programs that create files with .ps extension that are in reality eps files. Maybe we could make the format detection more liberal: Everything that has a bounding box is recognized as eps in included graphics mode. In export document mode everything is recognized as ps. That would solve this particular problem. As for the ps2pdf conversion alone (DVI-PDF), I wonder if the autorotate switch should be included a default in the converter section. It's easier to remove a switch than to add one which you never heard of. Two converters (one w/autorotate, one without it) is perhaps an overkill. Of course, autorotation could be set on a figure by figure basis in the graphics menu, and on a general basis with a checkbox. Please not, that would only be confusing. If you want to set something on a figure by figure basis you can explicitly rotate it. Georg
Re: Trouble with eps inclusions in lyx-1.4.1
To: lyx-users@lists.lyx.org From: Georg Baum [EMAIL PROTECTED] Subject: Re: Trouble with eps inclusions in lyx-1.4.1 Date: Fri, 02 Jun 2006 17:10:21 +0200 Jean-Pierre Chretien wrote: [...] Of course, autorotation could be set on a figure by figure basis in the graphics menu, and on a general basis with a checkbox. Please not, that would only be confusing. If you want to set something on a figure by figure basis you can explicitly rotate it. Just a suggestion, I'm not going to implement it anyway :-) I added a digest of the thread in the PDF FAQ: http://wiki.lyx.org/FAQ/PDF Fell free to update. Regards. -- Jean-Pierre
Re: Trouble with eps inclusions in lyx-1.4.1
Date: Thu, 1 Jun 2006 22:41:11 -0500 From: Paul Johnson [EMAIL PROTECTED] To: lyx-users@lists.lyx.org Subject: Re: Trouble with eps inclusions in lyx-1.4.1 Well, this seems like a serious problem, not one where we should say there's nothing to do. I'd suggest that LyX SHOULD NOT offer to export documents to pdf when they have eps files in them, or at least users need a VERY BIG warning because a lot of users will get in trouble unless they proof read their output very carefully. A bug of this sort, which crops up after a project is finished and printed out and presented to students/teachers, and appears only later in pdf output intended for the Web, is very serious. Sure, this problem gave me headaches until I discovered the Autorotate switch and patched it in a ps2pdf wrapper (epstopdf includes it by default since TL2005). However, why should LyX behave differently with eps graphics than with other kinds of graphics ? The current paradigm is to build output regardless of the type of graphic source, using internal conversion. With pdfatex, your problem came from a badly configured eps file (disagreement between the .eps extension and the magic number in the file (no EPSF in the first line, which lead lyx to believe that it was a PS file). As I stated, ps2pdf conversion of individual figures could be avoided by giving precedence on extension over magic number when there is disagreement. As for the ps2pdf conversion alone (DVI-PDF), I wonder if the autorotate switch should be included a default in the converter section. It's easier to remove a switch than to add one which you never heard of. Two converters (one w/autorotate, one without it) is perhaps an overkill. Of course, autorotation could be set on a figure by figure basis in the graphics menu, and on a general basis with a checkbox. If tex2pdf works, couldn't LyX incorporate that (its GPL, right?) and cut all usage of the other converters? I've seen it fail, but mostly on latex files not created with lyX, and with older versions of epstopdf. But I use it a lot (manages metadata, hyperref, indexes, glossaries, ... for you, without extra coding in the source). -- Jean-Pierre
Re: Trouble with eps inclusions in lyx-1.4.1
Paul Johnson wrote: Well, this seems like a serious problem, not one where we should say there's nothing to do. I did not say that. I said that I don't see a solution that will work in all cases. I'd suggest that LyX SHOULD NOT offer to export documents to pdf when they have eps files in them, or at least users need a VERY BIG warning because a lot of users will get in trouble unless they proof read their output very carefully. A bug of this sort, which crops up after a project is finished and printed out and presented to students/teachers, and appears only later in pdf output intended for the Web, is very serious. This is a disadvantage of the modular converter architecture. Since LyX has no control over the used tools, bad things can happen. There is a similar problem with bitmap images: If you specify a 50% scale, it entirely depends on the converter how big the image will be in the output, since it needs to assume a certain resolution (pixels per cm). If tex2pdf works, couldn't LyX incorporate that (its GPL, right?) and cut all usage of the other converters? I don't know how good tex2pdf is, but you can easily create a new pdf4 format and define tex2pdf as a converter tex-pdf4 yourself. Any tex2pdf experts please tell: Should we do that by default in LyX? Any possible problems? Georg
Re: Trouble with eps inclusions in lyx-1.4.1
To: lyx-users@lists.lyx.org From: Georg Baum [EMAIL PROTECTED] Subject: Re: Trouble with eps inclusions in lyx-1.4.1 Date: Fri, 02 Jun 2006 16:37:31 +0200 Paul Johnson wrote: Well, this seems like a serious problem, not one where we should say there's nothing to do. I did not say that. I said that I don't see a solution that will work in all cases. I'd suggest that LyX SHOULD NOT offer to export documents to pdf when they have eps files in them, or at least users need a VERY BIG warning because a lot of users will get in trouble unless they proof read their output very carefully. A bug of this sort, which crops up after a project is finished and printed out and presented to students/teachers, and appears only later in pdf output intended for the Web, is very serious. This is a disadvantage of the modular converter architecture. Since LyX has no control over the used tools, bad things can happen. There is a similar problem with bitmap images: If you specify a 50% scale, it entirely depends on the converter how big the image will be in the output, since it needs to assume a certain resolution (pixels per cm). If tex2pdf works, couldn't LyX incorporate that (its GPL, right?) and cut all usage of the other converters? I don't know how good tex2pdf is, but you can easily create a new pdf4 format and define tex2pdf as a converter tex-pdf4 yourself. Any tex2pdf experts please tell: Should we do that by default in LyX? Any possible problems? I've used it with success since the perl versions (tehere has been a lyx2pdf and tex2pdf bash ones), and contributed a little (Steffen Eversand Oscar Lopez did most of the job involved in the current perl port), and yes, I have a pdf1 format associated to tex2pdf conversion :-) \format pdf1 pdf PDF (tex2pdf) x xpdf \converter latex pdf1 tex2pdf $$i The situations where tex2pdf gets into trouble comes mostly with latex files: use of other packages than graphicx, insertion of graphics with user-defined macros, etc. which kill the parsing for graphics names. Use with LyX seems not concerned as the latex code is clean. Another reason of failure came from unproper constructs used in \title and \author fields (used to produce pdf metadata), but again this should less happen in LyX. In addition to pdf compilation, and with the help of a configuration file (defaults are reasonable), tex2pdf provides full hyperref control, makeindex control, etc. So the command in the converter section is simple, the customization will be in the config file. Presence can be checked and the format and converter commands installed. HTH -- Jean-Pierre
Re: Trouble with eps inclusions in lyx-1.4.1
Jean-Pierre Chretien wrote: With pdfatex, your problem came from a badly configured eps file (disagreement between the .eps extension and the magic number in the file (no EPSF in the first line, which lead lyx to believe that it was a PS file). As I stated, ps2pdf conversion of individual figures could be avoided by giving precedence on extension over magic number when there is disagreement. I don't like that approach, because I have programs that create files with .ps extension that are in reality eps files. Maybe we could make the format detection more liberal: Everything that has a bounding box is recognized as eps in included graphics mode. In export document mode everything is recognized as ps. That would solve this particular problem. As for the ps2pdf conversion alone (DVI-PDF), I wonder if the autorotate switch should be included a default in the converter section. It's easier to remove a switch than to add one which you never heard of. Two converters (one w/autorotate, one without it) is perhaps an overkill. Of course, autorotation could be set on a figure by figure basis in the graphics menu, and on a general basis with a checkbox. Please not, that would only be confusing. If you want to set something on a figure by figure basis you can explicitly rotate it. Georg
Re: Trouble with eps inclusions in lyx-1.4.1
To: lyx-users@lists.lyx.org From: Georg Baum [EMAIL PROTECTED] Subject: Re: Trouble with eps inclusions in lyx-1.4.1 Date: Fri, 02 Jun 2006 17:10:21 +0200 Jean-Pierre Chretien wrote: [...] Of course, autorotation could be set on a figure by figure basis in the graphics menu, and on a general basis with a checkbox. Please not, that would only be confusing. If you want to set something on a figure by figure basis you can explicitly rotate it. Just a suggestion, I'm not going to implement it anyway :-) I added a digest of the thread in the PDF FAQ: http://wiki.lyx.org/FAQ/PDF Fell free to update. Regards. -- Jean-Pierre
Re: Trouble with eps inclusions in lyx-1.4.1
>>Date: Thu, 1 Jun 2006 22:41:11 -0500 >>From: "Paul Johnson" <[EMAIL PROTECTED]> >>To: lyx-users@lists.lyx.org >>Subject: Re: Trouble with eps inclusions in lyx-1.4.1 >> >>Well, this seems like a serious problem, not one where we should say >>"there's nothing to do". >> >>I'd suggest that LyX SHOULD NOT offer to export documents to pdf when >>they have eps files in them, or at least users need a VERY BIG warning >> because a lot of users will get in trouble unless they proof read >>their output very carefully. A bug of this sort, which crops up after >>a project is finished and printed out and presented to >>students/teachers, and appears only later in pdf output intended for >>the Web, is very serious. Sure, this problem gave me headaches until I discovered the Autorotate switch and patched it in a ps2pdf wrapper (epstopdf includes it by default since TL2005). However, why should LyX behave differently with eps graphics than with other kinds of graphics ? The current paradigm is to build output regardless of the type of graphic source, using internal conversion. With pdfatex, your problem came from a badly configured eps file (disagreement between the .eps extension and the magic number in the file (no EPSF in the first line, which lead lyx to believe that it was a PS file). As I stated, ps2pdf conversion of individual figures could be avoided by giving precedence on extension over magic number when there is disagreement. As for the ps2pdf conversion alone (DVI->PDF), I wonder if the autorotate switch should be included a default in the converter section. It's easier to remove a switch than to add one which you never heard of. Two converters (one w/autorotate, one without it) is perhaps an overkill. Of course, autorotation could be set on a figure by figure basis in the graphics menu, and on a general basis with a checkbox. >> >>If tex2pdf works, couldn't LyX incorporate that (its GPL, right?) and >>cut all usage of the other converters? I've seen it fail, but mostly on latex files not created with lyX, and with older versions of epstopdf. But I use it a lot (manages metadata, hyperref, indexes, glossaries, ... for you, without extra coding in the source). -- Jean-Pierre
Re: Trouble with eps inclusions in lyx-1.4.1
Paul Johnson wrote: > Well, this seems like a serious problem, not one where we should say > "there's nothing to do". I did not say that. I said that I don't see a solution that will work in all cases. > I'd suggest that LyX SHOULD NOT offer to export documents to pdf when > they have eps files in them, or at least users need a VERY BIG warning > because a lot of users will get in trouble unless they proof read > their output very carefully. A bug of this sort, which crops up after > a project is finished and printed out and presented to > students/teachers, and appears only later in pdf output intended for > the Web, is very serious. This is a disadvantage of the modular converter architecture. Since LyX has no control over the used tools, bad things can happen. There is a similar problem with bitmap images: If you specify a 50% scale, it entirely depends on the converter how big the image will be in the output, since it needs to assume a certain resolution (pixels per cm). > If tex2pdf works, couldn't LyX incorporate that (its GPL, right?) and > cut all usage of the other converters? I don't know how good tex2pdf is, but you can easily create a new pdf4 format and define tex2pdf as a converter tex->pdf4 yourself. Any tex2pdf experts please tell: Should we do that by default in LyX? Any possible problems? Georg
Re: Trouble with eps inclusions in lyx-1.4.1
>>To: lyx-users@lists.lyx.org >>From: Georg Baum <[EMAIL PROTECTED]> >>Subject: Re: Trouble with eps inclusions in lyx-1.4.1 >>Date: Fri, 02 Jun 2006 16:37:31 +0200 >> >>Paul Johnson wrote: >> >>> Well, this seems like a serious problem, not one where we should say >>> "there's nothing to do". >> >>I did not say that. I said that I don't see a solution that will work in all >>cases. >> >>> I'd suggest that LyX SHOULD NOT offer to export documents to pdf when >>> they have eps files in them, or at least users need a VERY BIG warning >>> because a lot of users will get in trouble unless they proof read >>> their output very carefully. A bug of this sort, which crops up after >>> a project is finished and printed out and presented to >>> students/teachers, and appears only later in pdf output intended for >>> the Web, is very serious. >> >>This is a disadvantage of the modular converter architecture. Since LyX has >>no control over the used tools, bad things can happen. There is a similar >>problem with bitmap images: If you specify a 50% scale, it entirely depends >>on the converter how big the image will be in the output, since it needs to >>assume a certain resolution (pixels per cm). >> >>> If tex2pdf works, couldn't LyX incorporate that (its GPL, right?) and >>> cut all usage of the other converters? >> >>I don't know how good tex2pdf is, but you can easily create a new pdf4 >>format and define tex2pdf as a converter tex->pdf4 yourself. Any tex2pdf >>experts please tell: Should we do that by default in LyX? Any possible >>problems? I've used it with success since the perl versions (tehere has been a lyx2pdf and tex2pdf bash ones), and contributed a little (Steffen Eversand Oscar Lopez did most of the job involved in the current perl port), and yes, I have a pdf1 format associated to tex2pdf conversion :-) \format "pdf1" "pdf" "PDF (tex2pdf)" "x" "xpdf" "" \converter "latex" "pdf1" "tex2pdf $$i" "" The situations where tex2pdf gets into trouble comes mostly with latex files: use of other packages than graphicx, insertion of graphics with user-defined macros, etc. which kill the parsing for graphics names. Use with LyX seems not concerned as the latex code is clean. Another reason of failure came from unproper constructs used in \title and \author fields (used to produce pdf metadata), but again this should less happen in LyX. In addition to pdf compilation, and with the help of a configuration file (defaults are reasonable), tex2pdf provides full hyperref control, makeindex control, etc. So the command in the converter section is simple, the customization will be in the config file. Presence can be checked and the format and converter commands installed. HTH -- Jean-Pierre
Re: Trouble with eps inclusions in lyx-1.4.1
Jean-Pierre Chretien wrote: > With pdfatex, your problem came from a badly configured eps file > (disagreement between the .eps extension and the magic number in the file > (no EPSF in the first line, which lead lyx to believe that it was a PS > file). As I stated, ps2pdf conversion of individual figures could be > avoided by giving precedence on extension over magic number when there is > disagreement. I don't like that approach, because I have programs that create files with .ps extension that are in reality eps files. Maybe we could make the format detection more liberal: Everything that has a bounding box is recognized as eps in "included graphics mode". In "export document mode" everything is recognized as ps. That would solve this particular problem. > As for the ps2pdf conversion alone (DVI->PDF), I wonder if the autorotate > switch should be included a default in the converter section. > It's easier to remove a switch than to add one which you never heard of. > Two converters (one w/autorotate, one without it) is perhaps an overkill. > > Of course, autorotation could be set on a figure by figure basis in the > graphics menu, and on a general basis with a checkbox. Please not, that would only be confusing. If you want to set something on a figure by figure basis you can explicitly rotate it. Georg
Re: Trouble with eps inclusions in lyx-1.4.1
>>To: lyx-users@lists.lyx.org >>From: Georg Baum <[EMAIL PROTECTED]> >>Subject: Re: Trouble with eps inclusions in lyx-1.4.1 >>Date: Fri, 02 Jun 2006 17:10:21 +0200 >> >>Jean-Pierre Chretien wrote: [...] >>> Of course, autorotation could be set on a figure by figure basis in the >>> graphics menu, and on a general basis with a checkbox. >> >>Please not, that would only be confusing. If you want to set something on a >>figure by figure basis you can explicitly rotate it. Just a suggestion, I'm not going to implement it anyway :-) I added a digest of the thread in the PDF FAQ: http://wiki.lyx.org/FAQ/PDF Fell free to update. Regards. -- Jean-Pierre
Re: Trouble with eps inclusions in lyx-1.4.1
Well, this seems like a serious problem, not one where we should say there's nothing to do. I'd suggest that LyX SHOULD NOT offer to export documents to pdf when they have eps files in them, or at least users need a VERY BIG warning because a lot of users will get in trouble unless they proof read their output very carefully. A bug of this sort, which crops up after a project is finished and printed out and presented to students/teachers, and appears only later in pdf output intended for the Web, is very serious. If tex2pdf works, couldn't LyX incorporate that (its GPL, right?) and cut all usage of the other converters? PJ On 5/30/06, Georg Baum [EMAIL PROTECTED] wrote: Sven Schreiber wrote: Paul, can eps files be portrait or landscape at all? Yes. The %%Orientation comment is allowed in eps files. Unfortunately it is interpreted differently by different programs (therefore gs has the -dAutoRotatePages= switch): Some programs interpret %%Orientation Landscape as this file is already in landscape orientation, while others interpret it as this file should be in landscape orientation, therefore it should be rotated by 90 degrees. Whatever LyX does with these images will be correct for some and incorrect for others. I don't see a solution for this problem that will work for all eps creators and all viewers. Georg -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas
Re: Trouble with eps inclusions in lyx-1.4.1
Paul Johnson wrote:
Well, this seems like a serious problem, not one where we should say
there's nothing to do.
I'd suggest that LyX SHOULD NOT offer to export documents to pdf when
they have eps files in them, or at least users need a VERY BIG warning
because a lot of users will get in trouble unless they proof read
their output very carefully. A bug of this sort, which crops up after
a project is finished and printed out and presented to
students/teachers, and appears only later in pdf output intended for
the Web, is very serious.
If tex2pdf works, couldn't LyX incorporate that (its GPL, right?) and
cut all usage of the other converters?
PJ
---
http://mintaka.sdsu.edu/GF/bibliog/latex/LaTeXtoPDF.html
Need both PS and PDF? This requires *all* the graphics to be EPS files
Use the traditional method (dvips plus ps2pdf).
Need both DVI and PDF?
Use dvipdfm. Once again, the figures *must* be Encapsulated PS
Need just PDF?
Use pdflatex.
That looks pretty painless; but there's a catch. While the previous
methods employ EPS exclusively as the graphics format, pdflatex won't
accept EPS directly at all: you have to convert all the graphics to
JPEG, PNG, or PDF (!) before compiling.
---
I'd suggest that LyX SHOULD NOT offer to export documents to pdf when
It has always been impossible to export documents containing eps images
to pdflatex. There is no conversion and a warning about an incompatible
format pops up. I don't know how your file escaped. pdflatex is offered
because it is faster when all the graphics are *not* eps. But I did
see a conversion on FC4 with the eps images. I thought it might have
been the viewer that FC5 uses which is evince. Viewers are not equal.
...s{0C__download_weirdRotations_test1-small} [pdflatex error message]
I could not locate the file with any of these extensions:
.png,.pdf,.jpg,.mps [because pdflatex only does these, not eps]
--
2. Tell LaTeX what to expect.
You have to tell the latex program to add instructions for the
post-processors. So your preamble should look like this:
\documentclass[dvips,...]{article} % the dvips is essential
\usepackage[dvips]{graphicx}% to include images
\usepackage{pslatex}% to use PostScript fonts
% redefine float-placement parameters here
\begin{document}
--
3. Include the figures in the *.tex file.
To insert a figure (contained in a file named circle1.eps) into the
text, put something like
\begin{figure}[htp]
\resizebox{\textwidth}{!}{
\includegraphics[width=\textwidth]{circle1}
}
\caption{circle1}
\end{figure}
where you want the figure to appear in the text.
---
I saw in your lyx file that \graphics default was used and I
wondered about \usepackage[dvips]{graphicx} % to include images
but am not sure of the consequence.
PJ: Because a lot of my work depends on being able to create
pdf files that are accurate representations of the dvi/ps files
that LyX creates.
latex dvipsps2pdf
text.tex --- text.dvi --- text.ps text.pdf
Tex2pdf is a command line script that converts TeX/LaTeX and LyX
files to Portable Document format. Tex2pdf does this directly,
without the need for generating a Postscript file.
tex2pdf myfile.tex
SH: Suppose you want to convert a .dvi or .ps file. Either
Tex2pdf will not be the right tool, or will do no better
than ps2pdf. I noticed that Figure 3: Horizontal big one
was displayed in dvi and pdf but not postscript. Displays
for LyX, dvipdfm and Ps2pdf were the same except for
Figure 3: Horizontal big one missing in postscript.
pdflatex generated an error message as is intended since
it isn't meant for eps. So Windows behavior is correct.
Your file is not supposed to display in Linux, but it did.
Regards,
Stephen
Re: Trouble with eps inclusions in lyx-1.4.1
Well, this seems like a serious problem, not one where we should say there's nothing to do. I'd suggest that LyX SHOULD NOT offer to export documents to pdf when they have eps files in them, or at least users need a VERY BIG warning because a lot of users will get in trouble unless they proof read their output very carefully. A bug of this sort, which crops up after a project is finished and printed out and presented to students/teachers, and appears only later in pdf output intended for the Web, is very serious. If tex2pdf works, couldn't LyX incorporate that (its GPL, right?) and cut all usage of the other converters? PJ On 5/30/06, Georg Baum [EMAIL PROTECTED] wrote: Sven Schreiber wrote: Paul, can eps files be portrait or landscape at all? Yes. The %%Orientation comment is allowed in eps files. Unfortunately it is interpreted differently by different programs (therefore gs has the -dAutoRotatePages= switch): Some programs interpret %%Orientation Landscape as this file is already in landscape orientation, while others interpret it as this file should be in landscape orientation, therefore it should be rotated by 90 degrees. Whatever LyX does with these images will be correct for some and incorrect for others. I don't see a solution for this problem that will work for all eps creators and all viewers. Georg -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas
Re: Trouble with eps inclusions in lyx-1.4.1
Paul Johnson wrote:
Well, this seems like a serious problem, not one where we should say
there's nothing to do.
I'd suggest that LyX SHOULD NOT offer to export documents to pdf when
they have eps files in them, or at least users need a VERY BIG warning
because a lot of users will get in trouble unless they proof read
their output very carefully. A bug of this sort, which crops up after
a project is finished and printed out and presented to
students/teachers, and appears only later in pdf output intended for
the Web, is very serious.
If tex2pdf works, couldn't LyX incorporate that (its GPL, right?) and
cut all usage of the other converters?
PJ
---
http://mintaka.sdsu.edu/GF/bibliog/latex/LaTeXtoPDF.html
Need both PS and PDF? This requires *all* the graphics to be EPS files
Use the traditional method (dvips plus ps2pdf).
Need both DVI and PDF?
Use dvipdfm. Once again, the figures *must* be Encapsulated PS
Need just PDF?
Use pdflatex.
That looks pretty painless; but there's a catch. While the previous
methods employ EPS exclusively as the graphics format, pdflatex won't
accept EPS directly at all: you have to convert all the graphics to
JPEG, PNG, or PDF (!) before compiling.
---
I'd suggest that LyX SHOULD NOT offer to export documents to pdf when
It has always been impossible to export documents containing eps images
to pdflatex. There is no conversion and a warning about an incompatible
format pops up. I don't know how your file escaped. pdflatex is offered
because it is faster when all the graphics are *not* eps. But I did
see a conversion on FC4 with the eps images. I thought it might have
been the viewer that FC5 uses which is evince. Viewers are not equal.
...s{0C__download_weirdRotations_test1-small} [pdflatex error message]
I could not locate the file with any of these extensions:
.png,.pdf,.jpg,.mps [because pdflatex only does these, not eps]
--
2. Tell LaTeX what to expect.
You have to tell the latex program to add instructions for the
post-processors. So your preamble should look like this:
\documentclass[dvips,...]{article} % the dvips is essential
\usepackage[dvips]{graphicx}% to include images
\usepackage{pslatex}% to use PostScript fonts
% redefine float-placement parameters here
\begin{document}
--
3. Include the figures in the *.tex file.
To insert a figure (contained in a file named circle1.eps) into the
text, put something like
\begin{figure}[htp]
\resizebox{\textwidth}{!}{
\includegraphics[width=\textwidth]{circle1}
}
\caption{circle1}
\end{figure}
where you want the figure to appear in the text.
---
I saw in your lyx file that \graphics default was used and I
wondered about \usepackage[dvips]{graphicx} % to include images
but am not sure of the consequence.
PJ: Because a lot of my work depends on being able to create
pdf files that are accurate representations of the dvi/ps files
that LyX creates.
latex dvipsps2pdf
text.tex --- text.dvi --- text.ps text.pdf
Tex2pdf is a command line script that converts TeX/LaTeX and LyX
files to Portable Document format. Tex2pdf does this directly,
without the need for generating a Postscript file.
tex2pdf myfile.tex
SH: Suppose you want to convert a .dvi or .ps file. Either
Tex2pdf will not be the right tool, or will do no better
than ps2pdf. I noticed that Figure 3: Horizontal big one
was displayed in dvi and pdf but not postscript. Displays
for LyX, dvipdfm and Ps2pdf were the same except for
Figure 3: Horizontal big one missing in postscript.
pdflatex generated an error message as is intended since
it isn't meant for eps. So Windows behavior is correct.
Your file is not supposed to display in Linux, but it did.
Regards,
Stephen
Re: Trouble with eps inclusions in lyx-1.4.1
Well, this seems like a serious problem, not one where we should say "there's nothing to do". I'd suggest that LyX SHOULD NOT offer to export documents to pdf when they have eps files in them, or at least users need a VERY BIG warning because a lot of users will get in trouble unless they proof read their output very carefully. A bug of this sort, which crops up after a project is finished and printed out and presented to students/teachers, and appears only later in pdf output intended for the Web, is very serious. If tex2pdf works, couldn't LyX incorporate that (its GPL, right?) and cut all usage of the other converters? PJ On 5/30/06, Georg Baum <[EMAIL PROTECTED]> wrote: Sven Schreiber wrote: > Paul, can eps files be portrait or landscape at all? Yes. The %%Orientation comment is allowed in eps files. Unfortunately it is interpreted differently by different programs (therefore gs has the -dAutoRotatePages= switch): Some programs interpret "%%Orientation Landscape" as "this file is already in landscape orientation", while others interpret it as "this file should be in landscape orientation, therefore it should be rotated by 90 degrees." Whatever LyX does with these images will be correct for some and incorrect for others. I don't see a solution for this problem that will work for all eps creators and all viewers. Georg -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas
Re: Trouble with eps inclusions in lyx-1.4.1
Paul Johnson wrote:
Well, this seems like a serious problem, not one where we should say
"there's nothing to do".
I'd suggest that LyX SHOULD NOT offer to export documents to pdf when
they have eps files in them, or at least users need a VERY BIG warning
because a lot of users will get in trouble unless they proof read
their output very carefully. A bug of this sort, which crops up after
a project is finished and printed out and presented to
students/teachers, and appears only later in pdf output intended for
the Web, is very serious.
If tex2pdf works, couldn't LyX incorporate that (its GPL, right?) and
cut all usage of the other converters?
PJ
---
http://mintaka.sdsu.edu/GF/bibliog/latex/LaTeXtoPDF.html
"Need both PS and PDF? This requires *all* the graphics to be EPS files
Use the traditional method (dvips plus ps2pdf).
Need both DVI and PDF?
Use dvipdfm. Once again, the figures *must* be Encapsulated PS
Need just PDF?
Use pdflatex.
That looks pretty painless; but there's a catch. While the previous
methods employ EPS exclusively as the graphics format, pdflatex won't
accept EPS directly at all: you have to convert all the graphics to
JPEG, PNG, or PDF (!) before compiling."
---
> I'd suggest that LyX SHOULD NOT offer to export documents to pdf when
It has always been impossible to export documents containing eps images
to pdflatex. There is no conversion and a warning about an incompatible
format pops up. I don't know how your file escaped. pdflatex is offered
because it is faster when all the graphics are *not* eps. But I did
see a conversion on FC4 with the eps images. I thought it might have
been the viewer that FC5 uses which is "evince". Viewers are not equal.
...s{0C__download_weirdRotations_test1-small} [pdflatex error message]
I could not locate the file with any of these extensions:
.png,.pdf,.jpg,.mps [because pdflatex only does these, not eps]
--
2. Tell LaTeX what to expect.
You have to tell the latex program to add instructions for the
post-processors. So your preamble should look like this:
\documentclass[dvips,...]{article} % the dvips is essential
\usepackage[dvips]{graphicx}% to include images
\usepackage{pslatex}% to use PostScript fonts
% redefine float-placement parameters here
\begin{document}
--
3. Include the figures in the *.tex file.
To insert a figure (contained in a file named circle1.eps) into the
text, put something like
\begin{figure}[htp]
\resizebox{\textwidth}{!}{
\includegraphics[width=\textwidth]{circle1}
}
\caption{circle1}
\end{figure}
where you want the figure to appear in the text.
---
I saw in your lyx file that \graphics default was used and I
wondered about \usepackage[dvips]{graphicx} % to include images
but am not sure of the consequence.
PJ: "Because a lot of my work depends on being able to create
pdf files that are accurate representations of the dvi/ps files
that LyX creates."
latex dvipsps2pdf
text.tex ---> text.dvi ---> text.ps > text.pdf
Tex2pdf is a command line script that converts TeX/LaTeX and LyX
files to Portable Document format. Tex2pdf does this directly,
without the need for generating a Postscript file.
tex2pdf myfile.tex
SH: Suppose you want to convert a .dvi or .ps file. Either
Tex2pdf will not be the right tool, or will do no better
than ps2pdf. I noticed that "Figure 3: Horizontal big one"
was displayed in dvi and pdf but not postscript. Displays
for LyX, dvipdfm and Ps2pdf were the same except for
"Figure 3: Horizontal big one" missing in postscript.
pdflatex generated an error message as is intended since
it isn't meant for eps. So Windows behavior is correct.
Your file is not supposed to display in Linux, but it did.
Regards,
Stephen
Re: Trouble with eps inclusions in lyx-1.4.1
Paul Johnson schrieb: I just ran into a really weird lyx problem on Fedora Core 5 and tetex-3.0-19. It is so interesting I want to share and ask for help: http://pj.freefaculty.org/latex/weirdRotations-lyx.tar.gz That tarball has a lyx file and 3 eps files that I generated with R. Two of the eps files are in landscape mode, one is portrait (horizontal). By default, R generates eps files in landscape mode and using some interfaces for R, it is more-or-less difficult to make them come out in portrait mode. So it might be useful to have a good dependable way in LyX to manage eps files that are in landscape mode. Paul, can eps files be portrait or landscape at all? (In contrast to ps files, where of course the paper orientation matters.) They should have a valid bounding box information, and then in lyx you can rotate them to the orientation you prefer. Maybe your eps files are messed up in that respect? Just a wild guess, Sven
Re: Trouble with eps inclusions in lyx-1.4.1
Date: Mon, 29 May 2006 20:49:49 -0500 From: Paul Johnson [EMAIL PROTECTED] To: lyx-users@lists.lyx.org Subject: Trouble with eps inclusions in lyx-1.4.1 I just ran into a really weird lyx problem on Fedora Core 5 and tetex-3.0-19. It is so interesting I want to share and ask for help: http://pj.freefaculty.org/latex/weirdRotations-lyx.tar.gz [description of undesired behaviour] If you would please download this and test it out, I would be glad to hear if you see the same troubles. Because a lot of my work depends on being able to create pdf files that are accurate representations of the dvi/ps files that LyX creates. I can confirm the behaviour with ps, pdf obtained through ps2pdf and direct compilation with pdflatex. dvipdfm simply does not include figures (I guess it's a known bug, from the messages in the calling shell I see it looks for .eps.Z extensions for the files). In addition, the tex2pdf compilation gets a correct result (I mean, similar to the dvi layout). Here are the amendments I can suggest: * the ps2pdf path is simply corrected by adding the -dAutoRotatePages=/None modifier to the ps2pdf converter (ps2pdf13 here); * the trouble with the direct pdf path comes from the fact that lyx uses ps2pdf13 to convert eps files which are condidered as PS (instead of EPS) because of the first line which is incomplete (see bug 2612). -head -1 *.eps == test1-big.eps == %!PS-Adobe-3.0 == test1-bighor.eps == %!PS-Adobe-3.0 EPSF-3.0 == test1-small.eps == %!PS-Adobe-3.0 so that the conversions read: -lyx -dbg files -e pdf2 weirdRotations.lyx Setting debug level to files [...] Converting from ps to pdf Calling ps2pdf13 '0_tmp_weirdRotations_test1-small.eps' [...] Converting from ps to pdf Calling ps2pdf13 '1_tmp_weirdRotations_test1-big.eps' Converting from eps to pdf Calling /usr/local/TeX/bin/sparc-solaris/epstopdf --outfile='2_tmp_weirdRotations_test1-bighor.pdf' '2_tmp_weirdRotations_test1-bighor.eps' Converting from latex to pdf2 So the pdf produced for the first two images has been autorotated. I guess the PDF Mediabox is incorrect as well. As eps2pdf includes the -dAutoRotatePages=/None modifier, the best way seems to use Rolans Bless' ps2eps filter to normalize your epses. You might use alse tex2pdf, which uses epstopdf to create the pdf files (add a converter to pdf in the preferences). May be bug 2612 could be reopened to force use of epstopdf if the extension is eps, regardless of the first line of the file (od testing existence od a BB). HTH -- Jean-Pierre
Re: Trouble with eps inclusions in lyx-1.4.1
Sven Schreiber wrote: Paul, can eps files be portrait or landscape at all? Yes. The %%Orientation comment is allowed in eps files. Unfortunately it is interpreted differently by different programs (therefore gs has the -dAutoRotatePages= switch): Some programs interpret %%Orientation Landscape as this file is already in landscape orientation, while others interpret it as this file should be in landscape orientation, therefore it should be rotated by 90 degrees. Whatever LyX does with these images will be correct for some and incorrect for others. I don't see a solution for this problem that will work for all eps creators and all viewers. Georg
Re: Trouble with eps inclusions in lyx-1.4.1
Paul Johnson schrieb: I just ran into a really weird lyx problem on Fedora Core 5 and tetex-3.0-19. It is so interesting I want to share and ask for help: http://pj.freefaculty.org/latex/weirdRotations-lyx.tar.gz That tarball has a lyx file and 3 eps files that I generated with R. Two of the eps files are in landscape mode, one is portrait (horizontal). By default, R generates eps files in landscape mode and using some interfaces for R, it is more-or-less difficult to make them come out in portrait mode. So it might be useful to have a good dependable way in LyX to manage eps files that are in landscape mode. Paul, can eps files be portrait or landscape at all? (In contrast to ps files, where of course the paper orientation matters.) They should have a valid bounding box information, and then in lyx you can rotate them to the orientation you prefer. Maybe your eps files are messed up in that respect? Just a wild guess, Sven
Re: Trouble with eps inclusions in lyx-1.4.1
Date: Mon, 29 May 2006 20:49:49 -0500 From: Paul Johnson [EMAIL PROTECTED] To: lyx-users@lists.lyx.org Subject: Trouble with eps inclusions in lyx-1.4.1 I just ran into a really weird lyx problem on Fedora Core 5 and tetex-3.0-19. It is so interesting I want to share and ask for help: http://pj.freefaculty.org/latex/weirdRotations-lyx.tar.gz [description of undesired behaviour] If you would please download this and test it out, I would be glad to hear if you see the same troubles. Because a lot of my work depends on being able to create pdf files that are accurate representations of the dvi/ps files that LyX creates. I can confirm the behaviour with ps, pdf obtained through ps2pdf and direct compilation with pdflatex. dvipdfm simply does not include figures (I guess it's a known bug, from the messages in the calling shell I see it looks for .eps.Z extensions for the files). In addition, the tex2pdf compilation gets a correct result (I mean, similar to the dvi layout). Here are the amendments I can suggest: * the ps2pdf path is simply corrected by adding the -dAutoRotatePages=/None modifier to the ps2pdf converter (ps2pdf13 here); * the trouble with the direct pdf path comes from the fact that lyx uses ps2pdf13 to convert eps files which are condidered as PS (instead of EPS) because of the first line which is incomplete (see bug 2612). -head -1 *.eps == test1-big.eps == %!PS-Adobe-3.0 == test1-bighor.eps == %!PS-Adobe-3.0 EPSF-3.0 == test1-small.eps == %!PS-Adobe-3.0 so that the conversions read: -lyx -dbg files -e pdf2 weirdRotations.lyx Setting debug level to files [...] Converting from ps to pdf Calling ps2pdf13 '0_tmp_weirdRotations_test1-small.eps' [...] Converting from ps to pdf Calling ps2pdf13 '1_tmp_weirdRotations_test1-big.eps' Converting from eps to pdf Calling /usr/local/TeX/bin/sparc-solaris/epstopdf --outfile='2_tmp_weirdRotations_test1-bighor.pdf' '2_tmp_weirdRotations_test1-bighor.eps' Converting from latex to pdf2 So the pdf produced for the first two images has been autorotated. I guess the PDF Mediabox is incorrect as well. As eps2pdf includes the -dAutoRotatePages=/None modifier, the best way seems to use Rolans Bless' ps2eps filter to normalize your epses. You might use alse tex2pdf, which uses epstopdf to create the pdf files (add a converter to pdf in the preferences). May be bug 2612 could be reopened to force use of epstopdf if the extension is eps, regardless of the first line of the file (od testing existence od a BB). HTH -- Jean-Pierre
Re: Trouble with eps inclusions in lyx-1.4.1
Sven Schreiber wrote: Paul, can eps files be portrait or landscape at all? Yes. The %%Orientation comment is allowed in eps files. Unfortunately it is interpreted differently by different programs (therefore gs has the -dAutoRotatePages= switch): Some programs interpret %%Orientation Landscape as this file is already in landscape orientation, while others interpret it as this file should be in landscape orientation, therefore it should be rotated by 90 degrees. Whatever LyX does with these images will be correct for some and incorrect for others. I don't see a solution for this problem that will work for all eps creators and all viewers. Georg
Re: Trouble with eps inclusions in lyx-1.4.1
Paul Johnson schrieb: > I just ran into a really weird lyx problem on Fedora Core 5 and > tetex-3.0-19. It is so interesting I want to share and ask for help: > > http://pj.freefaculty.org/latex/weirdRotations-lyx.tar.gz > > That tarball has a lyx file and 3 eps files that I generated with R. > Two of the eps files are in landscape mode, one is portrait > (horizontal). By default, R generates eps files in landscape mode and > using some interfaces for R, it is more-or-less difficult to make them > come out in portrait mode. So it might be useful to have a good & > dependable way in LyX to manage eps files that are in landscape mode. > Paul, can eps files be portrait or landscape at all? (In contrast to ps files, where of course the "paper" orientation matters.) They should have a valid bounding box information, and then in lyx you can rotate them to the orientation you prefer. Maybe your eps files are messed up in that respect? Just a wild guess, Sven
Re: Trouble with eps inclusions in lyx-1.4.1
>>Date: Mon, 29 May 2006 20:49:49 -0500 >>From: "Paul Johnson" <[EMAIL PROTECTED]> >>To: lyx-users@lists.lyx.org >>Subject: Trouble with eps inclusions in lyx-1.4.1 >> >>I just ran into a really weird lyx problem on Fedora Core 5 and >>tetex-3.0-19. It is so interesting I want to share and ask for help: >> >>http://pj.freefaculty.org/latex/weirdRotations-lyx.tar.gz [description of undesired behaviour] >> >>If you would please download this and test it out, I would be glad to >>hear if you see the same troubles. Because a lot of my work depends >>on being able to create pdf files that are accurate representations of >>the dvi/ps files that LyX creates. I can confirm the behaviour with ps, pdf obtained through ps2pdf and direct compilation with pdflatex. dvipdfm simply does not include figures (I guess it's a known bug, from the messages in the calling shell I see it looks for .eps.Z extensions for the files). In addition, the tex2pdf compilation gets a correct result (I mean, similar to the dvi layout). Here are the amendments I can suggest: * the ps2pdf path is simply corrected by adding the -dAutoRotatePages=/None modifier to the ps2pdf converter (ps2pdf13 here); * the trouble with the direct pdf path comes from the fact that lyx uses ps2pdf13 to convert eps files which are condidered as PS (instead of EPS) because of the first line which is incomplete (see bug 2612). ->head -1 *.eps ==> test1-big.eps <== %!PS-Adobe-3.0 ==> test1-bighor.eps <== %!PS-Adobe-3.0 EPSF-3.0 ==> test1-small.eps <== %!PS-Adobe-3.0 so that the conversions read: ->lyx -dbg files -e pdf2 weirdRotations.lyx Setting debug level to files [...] Converting from ps to pdf Calling ps2pdf13 '0_tmp_weirdRotations_test1-small.eps' [...] Converting from ps to pdf Calling ps2pdf13 '1_tmp_weirdRotations_test1-big.eps' Converting from eps to pdf Calling /usr/local/TeX/bin/sparc-solaris/epstopdf --outfile='2_tmp_weirdRotations_test1-bighor.pdf' '2_tmp_weirdRotations_test1-bighor.eps' Converting from latex to pdf2 So the pdf produced for the first two images has been autorotated. I guess the PDF Mediabox is incorrect as well. As eps2pdf includes the -dAutoRotatePages=/None modifier, the best way seems to use Rolans Bless' ps2eps filter to normalize your epses. You might use alse tex2pdf, which uses epstopdf to create the pdf files (add a converter to pdf in the preferences). May be bug 2612 could be reopened to force use of epstopdf if the extension is eps, regardless of the first line of the file (od testing existence od a BB). HTH -- Jean-Pierre
Re: Trouble with eps inclusions in lyx-1.4.1
Sven Schreiber wrote: > Paul, can eps files be portrait or landscape at all? Yes. The %%Orientation comment is allowed in eps files. Unfortunately it is interpreted differently by different programs (therefore gs has the -dAutoRotatePages= switch): Some programs interpret "%%Orientation Landscape" as "this file is already in landscape orientation", while others interpret it as "this file should be in landscape orientation, therefore it should be rotated by 90 degrees." Whatever LyX does with these images will be correct for some and incorrect for others. I don't see a solution for this problem that will work for all eps creators and all viewers. Georg
Trouble with eps inclusions in lyx-1.4.1
I just ran into a really weird lyx problem on Fedora Core 5 and tetex-3.0-19. It is so interesting I want to share and ask for help: http://pj.freefaculty.org/latex/weirdRotations-lyx.tar.gz That tarball has a lyx file and 3 eps files that I generated with R. Two of the eps files are in landscape mode, one is portrait (horizontal). By default, R generates eps files in landscape mode and using some interfaces for R, it is more-or-less difficult to make them come out in portrait mode. So it might be useful to have a good dependable way in LyX to manage eps files that are in landscape mode. If you open the LyX document and view that in dvi, ps2pdf, pdflatex, and dvipdfm, the treatment of the eps graphics is different in each one. The dvi output is about what I expect, but pdflatex turns the graphs so they are right side up, ps2pdf turns the figure titles on the right side in lanscape mode, and dvipdfm does something else altogether. If I rotate the images so they are right side up in dvi mode, then the pdf output is also excitingly different. And it is not a good kind of excitement. If you would please download this and test it out, I would be glad to hear if you see the same troubles. Because a lot of my work depends on being able to create pdf files that are accurate representations of the dvi/ps files that LyX creates. -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas
Re: Trouble with eps inclusions in lyx-1.4.1
Paul Johnson wrote: I just ran into a really weird lyx problem on Fedora Core 5 and tetex-3.0-19. It is so interesting I want to share and ask for help: http://pj.freefaculty.org/latex/weirdRotations-lyx.tar.gz That tarball has a lyx file and 3 eps files that I generated with R. Two of the eps files are in landscape mode, one is portrait (horizontal). By default, R generates eps files in landscape mode and using some interfaces for R, it is more-or-less difficult to make them come out in portrait mode. So it might be useful to have a good dependable way in LyX to manage eps files that are in landscape mode. If you open the LyX document and view that in dvi, ps2pdf, pdflatex, and dvipdfm, the treatment of the eps graphics is different in each one. The dvi output is about what I expect, but pdflatex turns the graphs so they are right side up, ps2pdf turns the figure titles on the right side in lanscape mode, and dvipdfm does something else altogether. If I rotate the images so they are right side up in dvi mode, then the pdf output is also excitingly different. And it is not a good kind of excitement. If you would please download this and test it out, I would be glad to hear if you see the same troubles. Because a lot of my work depends on being able to create pdf files that are accurate representations of the dvi/ps files that LyX creates. I tested this on Windows 1.3.7v3 and 1.4.2svn and Cygwin1.4.0 It didn't look right. .eps are not supposed to be displayed in pdflatex at all, it is not a supported image (needs converting). Cygwin which uses a Linux like xpdf crashed when viewing under all three modes. Will test later on FC4. That you got a pdflatex display at all and that my CygLyX crashed makes me think that there is something wrong with the .eps file (how they were made). Regards, Stephen
Re: Trouble with eps inclusions in lyx-1.4.1
Paul Johnson wrote: I just ran into a really weird lyx problem on Fedora Core 5 and tetex-3.0-19. It is so interesting I want to share and ask for help: http://pj.freefaculty.org/latex/weirdRotations-lyx.tar.gz I tried this on FC4 which has evince installed by default as the pdf and ps viewers. When I changed the viewer to gv and alzo acroread (linux version needed 1 added library dependency) everything looked a lot better. Though I don't understand why it displayed pdflatex with .eps files. Try changing viewers. Regards, Stephen
Trouble with eps inclusions in lyx-1.4.1
I just ran into a really weird lyx problem on Fedora Core 5 and tetex-3.0-19. It is so interesting I want to share and ask for help: http://pj.freefaculty.org/latex/weirdRotations-lyx.tar.gz That tarball has a lyx file and 3 eps files that I generated with R. Two of the eps files are in landscape mode, one is portrait (horizontal). By default, R generates eps files in landscape mode and using some interfaces for R, it is more-or-less difficult to make them come out in portrait mode. So it might be useful to have a good dependable way in LyX to manage eps files that are in landscape mode. If you open the LyX document and view that in dvi, ps2pdf, pdflatex, and dvipdfm, the treatment of the eps graphics is different in each one. The dvi output is about what I expect, but pdflatex turns the graphs so they are right side up, ps2pdf turns the figure titles on the right side in lanscape mode, and dvipdfm does something else altogether. If I rotate the images so they are right side up in dvi mode, then the pdf output is also excitingly different. And it is not a good kind of excitement. If you would please download this and test it out, I would be glad to hear if you see the same troubles. Because a lot of my work depends on being able to create pdf files that are accurate representations of the dvi/ps files that LyX creates. -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas
Re: Trouble with eps inclusions in lyx-1.4.1
Paul Johnson wrote: I just ran into a really weird lyx problem on Fedora Core 5 and tetex-3.0-19. It is so interesting I want to share and ask for help: http://pj.freefaculty.org/latex/weirdRotations-lyx.tar.gz That tarball has a lyx file and 3 eps files that I generated with R. Two of the eps files are in landscape mode, one is portrait (horizontal). By default, R generates eps files in landscape mode and using some interfaces for R, it is more-or-less difficult to make them come out in portrait mode. So it might be useful to have a good dependable way in LyX to manage eps files that are in landscape mode. If you open the LyX document and view that in dvi, ps2pdf, pdflatex, and dvipdfm, the treatment of the eps graphics is different in each one. The dvi output is about what I expect, but pdflatex turns the graphs so they are right side up, ps2pdf turns the figure titles on the right side in lanscape mode, and dvipdfm does something else altogether. If I rotate the images so they are right side up in dvi mode, then the pdf output is also excitingly different. And it is not a good kind of excitement. If you would please download this and test it out, I would be glad to hear if you see the same troubles. Because a lot of my work depends on being able to create pdf files that are accurate representations of the dvi/ps files that LyX creates. I tested this on Windows 1.3.7v3 and 1.4.2svn and Cygwin1.4.0 It didn't look right. .eps are not supposed to be displayed in pdflatex at all, it is not a supported image (needs converting). Cygwin which uses a Linux like xpdf crashed when viewing under all three modes. Will test later on FC4. That you got a pdflatex display at all and that my CygLyX crashed makes me think that there is something wrong with the .eps file (how they were made). Regards, Stephen
Re: Trouble with eps inclusions in lyx-1.4.1
Paul Johnson wrote: I just ran into a really weird lyx problem on Fedora Core 5 and tetex-3.0-19. It is so interesting I want to share and ask for help: http://pj.freefaculty.org/latex/weirdRotations-lyx.tar.gz I tried this on FC4 which has evince installed by default as the pdf and ps viewers. When I changed the viewer to gv and alzo acroread (linux version needed 1 added library dependency) everything looked a lot better. Though I don't understand why it displayed pdflatex with .eps files. Try changing viewers. Regards, Stephen
Trouble with eps inclusions in lyx-1.4.1
I just ran into a really weird lyx problem on Fedora Core 5 and tetex-3.0-19. It is so interesting I want to share and ask for help: http://pj.freefaculty.org/latex/weirdRotations-lyx.tar.gz That tarball has a lyx file and 3 eps files that I generated with R. Two of the eps files are in landscape mode, one is portrait (horizontal). By default, R generates eps files in landscape mode and using some interfaces for R, it is more-or-less difficult to make them come out in portrait mode. So it might be useful to have a good & dependable way in LyX to manage eps files that are in landscape mode. If you open the LyX document and view that in dvi, ps2pdf, pdflatex, and dvipdfm, the treatment of the eps graphics is different in each one. The dvi output is about what I expect, but pdflatex turns the graphs so they are right side up, ps2pdf turns the figure titles on the right side in lanscape mode, and dvipdfm does something else altogether. If I rotate the images so they are "right side up" in dvi mode, then the pdf output is also excitingly different. And it is not a good kind of excitement. If you would please download this and test it out, I would be glad to hear if you see the same troubles. Because a lot of my work depends on being able to create pdf files that are accurate representations of the dvi/ps files that LyX creates. -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas
Re: Trouble with eps inclusions in lyx-1.4.1
Paul Johnson wrote: I just ran into a really weird lyx problem on Fedora Core 5 and tetex-3.0-19. It is so interesting I want to share and ask for help: http://pj.freefaculty.org/latex/weirdRotations-lyx.tar.gz That tarball has a lyx file and 3 eps files that I generated with R. Two of the eps files are in landscape mode, one is portrait (horizontal). By default, R generates eps files in landscape mode and using some interfaces for R, it is more-or-less difficult to make them come out in portrait mode. So it might be useful to have a good & dependable way in LyX to manage eps files that are in landscape mode. If you open the LyX document and view that in dvi, ps2pdf, pdflatex, and dvipdfm, the treatment of the eps graphics is different in each one. The dvi output is about what I expect, but pdflatex turns the graphs so they are right side up, ps2pdf turns the figure titles on the right side in lanscape mode, and dvipdfm does something else altogether. If I rotate the images so they are "right side up" in dvi mode, then the pdf output is also excitingly different. And it is not a good kind of excitement. If you would please download this and test it out, I would be glad to hear if you see the same troubles. Because a lot of my work depends on being able to create pdf files that are accurate representations of the dvi/ps files that LyX creates. I tested this on Windows 1.3.7v3 and 1.4.2svn and Cygwin1.4.0 It didn't look right. .eps are not supposed to be displayed in pdflatex at all, it is not a supported image (needs converting). Cygwin which uses a Linux like xpdf crashed when viewing under all three modes. Will test later on FC4. That you got a pdflatex display at all and that my CygLyX crashed makes me think that there is something wrong with the .eps file (how they were made). Regards, Stephen
Re: Trouble with eps inclusions in lyx-1.4.1
Paul Johnson wrote: I just ran into a really weird lyx problem on Fedora Core 5 and tetex-3.0-19. It is so interesting I want to share and ask for help: http://pj.freefaculty.org/latex/weirdRotations-lyx.tar.gz I tried this on FC4 which has evince installed by default as the pdf and ps viewers. When I changed the viewer to gv and alzo acroread (linux version needed 1 added library dependency) everything looked a lot better. Though I don't understand why it displayed pdflatex with .eps files. Try changing viewers. Regards, Stephen
