# Why are .gif files not supported?

Is it because of licensing issues? Because of the file format? Some other reason?

• Because .gif is a strange collection of many formats and no one bothered building support for it into pdfLaTeX (would have to be done similar to how png is handled, because, afaik, gif can't be directly put into the pdf unlike some other image formats). Jan 26 at 9:02
• jpg and pdf can be fairly easily embedded in pdf gif can not. Nor can png but at least png is just a single bitmap that can be converted to a pdf bitmap converting gif to a video format embeddable in pdf is tricky (and has changed over time as video in pdf support has been somewhat variable) so is much better left to an external program. Jan 26 at 9:06
• Wasn't gif also covered by patents for many years? Jan 26 at 10:06
• @DavidCarlisle iirc, gif was original just a container format, and the animated gifs were added to that, so gif can also be "just a single bitmap", but doesn't have to. Handling gif correctly seems much more complicated :) Jan 27 at 9:28

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.

\documentclass[dvisvgm]{article}

% download Newtons_cradle_animation_book_2.gif' before typesetting:
%

\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%
\edef\Gin@svg@view@width{\strip@pt\dimen@}%
\dimen@\Gin@ury pt%
\edef\Gin@svg@view@height{\strip@pt\dimen@}%
\dimen@\Gin@svg@real@height@bp pt%
\edef\Gin@svg@view@base{\strip@pt\dimen@}%
\Gin@req@width0.99626\Gin@req@width%
\Gin@req@height0.99626\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"
\ifluatex\directlua{media4svg.base64("#1",72,"{?nl}")}%
\else\encodedGif\fi'/>
</svg>
</g>}%
}%
}
\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
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%BoundingBox: 0 0 480 360
\end{filecontents}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{document}

\section{Animated 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.