graphics

¿Por qué no se admiten los archivos .gif?

Esta es una pregunta que me hago desde hace tiempo y no he encontrado respuesta.

¿Es por cuestiones de licencias? ¿Por el formato de los archivos? ¿Alguna otra razón?


Solo para demostrar lo contrario: la incrustación directa de GIF es posible, ciertamente no en PDF, pero sí en salida SVG.

Solo tenemos que agregar una regla graphicx que trate GIF (estático/animado) como otro formato de mapa de bits (además de PNG y JPEG) con un <img file base name>.xbb proporcionado por el usuario que contiene la información del cuadro delimitador:

\DeclareGraphicsRule{.gif}{bitmap}{.xbb}{}

Para una imagen de 480px * 360px, el contenido del archivo xbb dice

%%BoundingBox: 0 0 480 360

Para insertar datos GIF en la salida SVG, el archivo GIF debe estar codificado en base64. El paquete media4svg proporciona un comando para esto que usamos para modificar el código del controlador graphicx para mapas de bits ( \Ginclude ).


(Requiere pkg media4svg , v0.9 2022-08-12.)

Typeset example.tex enumerados a continuación con

dvilualatex example
dvisvgm --zoom=-1 --bbox=tamaño del papel --font-format=woff2 ejemplo

or

latex --shell-escape example
dvisvgm --zoom=-1 --bbox=tamaño del papel --font-format=woff2 ejemplo

or even

xelatex --shell-escape --no-pdf ejemplo
dvisvgm --zoom=-1 --bbox=tamañopapel --font-format=woff2 ejemplo.xdv

NB Firefox no puede reproducir GIF animados incrustados en SVG que está incrustado en una página web (como TeX.SX). Parece un error. En su lugar, utilice un navegador web basado en Blink, como Chromium, Chrome, Opera o Edge. O (derecho) haga clic en la imagen para abrir el SVG en una pestaña propia del navegador.


Archivo de entrada example.tex .

(Descargue el GIF desde 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}
\DeclareGraphicsRule{.gif}{bitmap}{.xbb}{}

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

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% patch graphics backend driver `dvisvgm.def' to physically embed
% bitmaps into DVI
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\makeatletter
\let\Ginclude\Ginclude
\def\Ginclude#1{%
  \baseSixtyFour{#1}{72}{{?nl}}\bitmap%
  \Ginclude{%
    data:image/\expandafter\remove\Gin;;base64,{?nl}%
    \bitmap}%
}
\def\remove.#1;{#1}
\makeatother

\RequirePackage{media4svg} % provides base64-encode utility
\ExplSyntaxOn
\cs_new:Npn\baseSixtyFour#1#2#3#4{
  \sys_if_engine_luatex:TF{
    \xdef#4{\directlua{media4svg.base64("#1",#2,"#3")}}
  }{
    \msvg_convert_file_to_blob:nnnN{#1}{#2}{#3}#4
  }
}
\ExplSyntaxOff
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{document}

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

\end{document}



Hay un artículo en TUGboat de 1996 (escrito por Keith Reckdahl) que incluye una discusión sobre los formatos de imagen compatibles. El artículo es del Volumen 17 No. 1 y se llama Uso de gráficos EPS en documentos LATEX2ε Parte 1 . La discusión se centra en dvips , pero se puede hacer un argumento similar para la salida directa en pdf (ver el comentario de David sobre esta pregunta). Además, la práctica histórica de no implementar soporte directo en dvips puede haber influido en las elecciones realizadas para pdflatex y compiladores posteriores.

Cita (página 52-53):

10.3 Inclusión de archivos gráficos que no sean EPS

Mientras que es fácil insertar gráficos EPS en documentos LATEX,no es tan sencillo insertar gráficos no EPS (GIF,TIFF,JPEG,PICT,etc.).

[...]

10.3.1 Soporte directo para gráficos que no son EPS

A menudo se pide que LATEX y dvips soporten la inclusión directa de formatos gráficos no EPS,haciéndolo tan fácil como insertar archivos EPS.Aunque esto sería conveniente,lamentablemente hay algunos problemas que complican las cosas.

Por ejemplo,la mayoría de los formatos gráficos que no son EPS utilizan archivos binarios que no pueden ser leídos por TEX,lo que impide que LATEX determine el tamaño de los gráficos que no son EPS.Además,el apoyo a los gráficos que no son EPS también requeriría que dvips incorporara capacidades de conversión de gráficos (GIF-a-PS,TIFF-a-PS,etc.).Esto no sólo requeriría mucha programación,sino también más mantenimiento en el futuro.

En lugar de incorporar directamente rutinas de conversión de gráficos,dvips proporciona un mecanismo de llamada a programas de conversión externos.Se puede acceder a este mecanismo desde LATEX utilizando el argumento de comando de \DeclareGraphicsRule.Esto tiene la ventaja de ser más flexible que el soporte directo,y como mantiene la conversión de gráficos desacoplada de la conversión DVI a PS,los usuarios son libres de elegir su propio programa de conversión de gráficos.

Otro enfoque histórico interesante se describe en un artículo de 1991 , donde las fotos en formato GIF se convierten en una fuente (!) para su inclusión directa en documentos LaTeX.