Re: [MiKTeX] Including .eps file in MiKTeX

[Alan G I. <ai...@am...>]

On Fri, 11 Jan 2008, "Cornelius C. Noack" apparently wrote:
> You should use \includegraphics instead. 

While I agree with this recommendation, things are a bit 
more complex, I believe.  See the PS below.

That said, I'm guessing the real problem is that the EPS 
file is non-standard (i.e., is missing a bounding box or
has added a binary preview).

Cheers,
Alan Isaac

PS According to Robin Fairbairns:

    The packages graphics, graphicx and epsfig were all released in their
    present form at the same time (summer 1994).  epsfig is capable of
    generating some confusion because a package of the same name existed before
    that time (it was written as a joint replacement for the
    long-established, and somewhat buggy, epsf and psfig packages); the
    old epsfig doesn't have the characteristics we have come to rely on.

    The graphics package forms the basic kernel of the whole bundle: it
    converts graphics primitive commands into \special commands[*] for the
    device drivers that the bundle supports.

    The graphicx package adds a user interface, and makes possible the
    merging of commands (like scale and rotate: which in graphics need to
    be composed, and hence produce a longer sequence of commands both at
    the TeX level and potentially also at the driver level).

    To first order, the epsfig package simply provides a different user
    interface, which it translates into graphicx-like commands.

    There _are_ trade-offs.  graphics' user interface is very
    "traditional tex", with little sophistication.  graphicx and epsfig
    use a key-value syntax which is noticeably more difficult (and hence
    cpu-intensive) for the packages to decode.

    graphicx is middle of the road as far as decoding
    complexity goes, but has useful extra power in its graphical
    expressiveness by comparison with graphics.
    (Also, if you never learned psfig, epsfig's psfig-like syntax won't excite you much.)