Why are .gif files not supported?

Just to prove the opposite: Direct embedding GIF is possible, though not in PDF, yet in SVG output.

We just have to add a graphicx driver for embedding GIFs (static/animated) to be used with the dvisvgm backend.

For in-lining GIF data into the SVG output, the GIF file must be base64 encoded. Package media4svg provides a command for this that we make use of in the driver code. Also, the dimensions of the GIF must be told to graphics. Pkg graphics accepts <img file base name>.xbb files from which it reads the BoundingBox information. For a 480px * 360px image, the contents of the xbb file reads

%%BoundingBox: 0 0 480 360

Typeset example.tex listed below with

dvilualatex example
dvisvgm --zoom=-1 --bbox=papersize --font-format=woff2 example

or

latex --shell-escape example
dvisvgm --zoom=-1 --bbox=papersize --font-format=woff2 example

or even

xelatex --shell-escape --no-pdf example
dvisvgm --zoom=-1 --bbox=papersize --font-format=woff2 example.xdv

N.B. Firefox fails to play animated GIF embedded in SVG that is itself embedded in a web page (like TeX.SX). It looks like a bug. Use a Blink-based web browser instead, such as Chromium, Chrome, Opera or Edge. Or right-click on the image and open the SVG in a new browser tab.

Input file example.tex.

(Download GIF from https://upload.wikimedia.org/wikipedia/commons/d/d3/Newtons_cradle_animation_book_2.gif)

\documentclass[dvisvgm]{article}

% download `Newtons_cradle_animation_book_2.gif' before typesetting:
%
% https://upload.wikimedia.org/wikipedia/commons/d/d3/Newtons_cradle_animation_book_2.gif

\usepackage[a6paper]{geometry}
\usepackage{graphicx}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% graphic[sx] driver for static/animated GIF inclusion
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\makeatletter
\def\Ginclude@gif#1{%
  \ifluatex\else\baseSixtyFour{#1}\encodedGif\fi%        
  \dimen@\Gin@urx pt%
  \advance\dimen@ by-\Gin@llx pt%
  \edef\Gin@svg@view@width{\strip@pt\dimen@}%
  \dimen@\Gin@ury pt%
  \advance\dimen@ by-\Gin@lly pt%
  \edef\Gin@svg@view@height{\strip@pt\dimen@}%
  \dimen@\Gin@svg@real@height@bp pt%
  \advance\dimen@ by-\Gin@ury pt%
  \edef\Gin@svg@view@base{\strip@pt\dimen@}%
  \Gin@[email protected]\Gin@req@width%
  \Gin@[email protected]\Gin@req@height%
  \raise\strip@pt\Gin@req@height bp\hbox{%
    \special{dvisvgm: raw
      <g transform="translate({?x},{?y})">
        <svg overflow="\ifGin@clip hidden\else visible\fi" width="\strip@pt\Gin@req@width" height="\strip@pt\Gin@req@height"
            viewBox="\Gin@llx\GPT@space\Gin@svg@view@base\GPT@space\Gin@svg@view@width\GPT@space\Gin@svg@view@height">
          <image width="\Gin@svg@real@width@bp" height="\Gin@svg@real@height@bp"
            xlink:href='data:image/gif;base64,{?nl}%
            \ifluatex\directlua{media4svg.base64("#1",72,"{?nl}")}%
            \else\encodedGif\fi'/>
        </svg>
      </g>}%
  }%
}
\let\Gread@gif\Gread@bitmap
\makeatother
\RequirePackage{media4svg} % provides base64-encode utility
\ExplSyntaxOn
\let\baseSixtyFour\msvg_convert_file_to_blob:nN
\ExplSyntaxOff
\DeclareGraphicsRule{.gif}{gif}{.xbb}{}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% provide BoundingBox information in a separate file
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{filecontents}[overwrite,noheader]{Newtons_cradle_animation_book_2.xbb}
%%BoundingBox: 0 0 480 360
\end{filecontents}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{document}

\section{Animated GIF}
\noindent\includegraphics[width=\linewidth]{Newtons_cradle_animation_book_2.gif}

\end{document}

There is an article in TUGboat from 1996 (written by by Keith Reckdahl) that includes a discussion of supporting image formats. The article is from Volume 17 No. 1 and is called Using EPS Graphics in LATEX2ε Documents Part 1. The discussion is centered around dvips, but a similar argument can be made for direct pdf output (see David's comment on this question). Also the historical practise of not implementing direct support in dvips may have influenced choices made for pdflatex and later compilers.

Quote (page 52-53):

10.3 Including Non-EPS Graphic Files

While it is easy to insert EPS graphics into LATEX documents, it is not as straightforward to insert non-EPS graphics (GIF, TIFF, JPEG, PICT, etc.).

[...]

10.3.1 Direct Support for Non-EPS Graphics

It is often requested that LATEX and dvips support the direct inclusion of non-EPS graphic formats, making it as easy as inserting EPS files. While this would be convenient, there unfortunately are some problems which complicate things.

For example, most non-EPS graphic formats use binary files which cannot be read by TEX, which prevents LATEX from determining the size of the non-EPS graphics. Furthermore, supporting non-EPS graphics would also require dvips to incorporate graphics conversion capabilities (GIF-to-PS, TIFF-to-PS, etc.). This would not only require a lot of programming, it would also require more maintenance in the future.

Rather than directly incorporating graphics conversion routines, dvips provides a mechanism of calling external conversion programs. This mechanism can be accessed from LATEX by use [of] the command argument of \DeclareGraphicsRule. This has the benefit of being more flexible than direct support, and since it keeps the graphics conversion uncoupled from the DVI-to-PS conversion, users are free to choose their own graphics conversion program.

Another interesting historical approach is described in an article from 1991, where photos in GIF format are converted into a font (!) for direct inclusion into LaTeX documents.

Tags:

Graphics

Includegraphics

Animate

Recent Posts