pdflatex and includegraphics

[Qian Yun]

Fixing the various minor problems with exporting "ps" image
might take a while.

In the mean time, I'd like to discuss another aspect of
book.pdf generation.

I guess no one uses book.dvi or book.ps? Using pdflatex
to generate pdf directly is faster and produces better result
according to some sources.

(Luatex supports unicode, but we don't require it, yet.)

The problem is that pdflatex can't use ps image directly,
but we already have awk script to do the xpm->ps conversion.
We can do xpm->pdf (or ps->pdf when we generate ps image directly.)
Then we use the \includegraphics command from "graphicsx"
package to replace the out-dated "epsf" package.

With minimal effort we can support pdflatex, while maintaining
compatibility with current latex->dvips->ps2pdf process.

Not a TeX expert my self, so how to define the equivalent thing
with includegraphics?

\def\epsfsize#1#2{.24\textheight}
\let\spadepsffilesave\epsffile
\def\epsffile[#1]#2{\begin{center}\spadepsffilesave[#1]{#2}\end{center}}


- Qian

[Nasser M. Abbasi]

You can use .ps images with pdflatex.  see  this  and note that you need the option  --shell-escape

It will automatically convert .ps to pdf when running pdflatex

--Nasser

[Waldek Hebisch]

On Sun, Feb 04, 2024 at 07:24:15PM +0800, Qian Yun wrote:
> Fixing the various minor problems with exporting "ps" image
> might take a while.
>
> In the mean time, I'd like to discuss another aspect of
> book.pdf generation.
>
> I guess no one uses book.dvi or book.ps?

"no one uses" is a riscy statement: personaly for viewing I have
some preference to use .dvi, since .dvi viewer used to be
lightweight and responsive. Personaly, given .pdf I see no
need for .ps, but who knows what other folks may want. OTOH,
I think that there is no need to produce them by default.

> Using pdflatex
> to generate pdf directly is faster and produces better result
> according to some sources.

Yes, generating .pdf without going trough .ps is better.

> (Luatex supports unicode, but we don't require it, yet.)
>
> The problem is that pdflatex can't use ps image directly,
> but we already have awk script to do the xpm->ps conversion.
> We can do xpm->pdf (or ps->pdf when we generate ps image directly.)
> Then we use the \includegraphics command from "graphicsx"
> package to replace the out-dated "epsf" package.
>
> With minimal effort we can support pdflatex, while maintaining
> compatibility with current latex->dvips->ps2pdf process.
>
> Not a TeX expert my self, so how to define the equivalent thing
> with includegraphics?
>
> \def\epsfsize#1#2{.24\textheight}
> \let\spadepsffilesave\epsffile
> \def\epsffile[#1]#2{\begin{center}\spadepsffilesave[#1]{#2}\end{center}}

AFAICS the first line really sets a parameter of "epsf" package,
name suggest that this is image size. AFAIK includegraphics allows
specifying image size, with "good" eps file size can be read from
the image.

The second and third line redefine '\epsffile' command so that
images are centered. That looks dirty to me: I would normally
define a new command or use explicit '\begin{center}' and
'\end{center}'

--
Waldek Hebisch

[Qian Yun]

The common usage is \epsffile[0 0 295 295]{xxx.ps}.

[0 0 295 295] is viewport? You said something about bounding box, are
they related? Is Gdraws_setDimension in Gfun.c supposed to do this?

- Qian