graphics

Pourquoi les fichiers .gif ne sont pas pris en charge

C'est une question que je me pose depuis un certain temps et je n'ai pas trouvé de réponse.

Est-ce à cause de problèmes de licence ? À cause du format du fichier ? Une autre raison ?

Juste pour prouver le contraire : l'intégration directe de GIF est possible, certes pas en PDF, mais en sortie SVG.

Nous devons simplement ajouter une règle graphicx qui traite le GIF (statique/animé) comme un autre format bitmap (en plus de PNG et JPEG) avec un <img file base name>.xbb l'utilisateur contenant les informations de la boîte englobante :

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

Pour une image 480px * 360px, le contenu du fichier xbb lit

%%BoundingBox: 0 0 480 360

Pour les données GIF intégrées dans la sortie SVG, le fichier GIF doit être encodé en base64. Le package media4svg fournit une commande pour cela que nous utilisons pour modifier le code du pilote graphicx pour les bitmaps ( \Ginclude ).


(Nécessite pkg media4svg , v0.9 2022-08-12.)

Typeset example.tex listé ci-dessous avec

dvilualatex example
dvisvgm --zoom=-1 --bbox=taille du papier --font-format=woff2 exemple

or

latex --shell-escape example
dvisvgm --zoom=-1 --bbox=taille du papier --font-format=woff2 exemple

or even

xelatex --shell-escape --no-pdf exemple
dvisvgm --zoom=-1 --bbox=taille du papier --font-format=woff2 example.xdv

NB Firefox ne parvient pas à lire le GIF animé intégré dans SVG qui est lui-même intégré dans une page Web (comme TeX.SX). Cela ressemble à un bogue. Utilisez plutôt un navigateur Web basé sur Blink, tel que Chromium, Chrome, Opera ou Edge. Ou cliquez (droit) sur l'image pour ouvrir le SVG dans un onglet de navigateur qui lui est propre.


Fichier d'entrée example.tex .

(Télécharger GIF depuis 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}



Il y a un article dans TUGboat de 1996 (écrit par Keith Reckdahl) qui inclut une discussion sur la prise en charge des formats d'image. L'article provient du volume 17 n° 1 et s'intitule Utilisation des graphiques EPS dans les documents LATEX2ε Partie 1 . La discussion est centrée sur dvips , mais un argument similaire peut être avancé pour la sortie pdf directe (voir le commentaire de David sur cette question). De plus, la pratique historique de ne pas implémenter le support direct dans dvips peut avoir influencé les choix faits pour pdflatex et les compilateurs ultérieurs.

Citation (page 52-53):

10.3 Inclure des fichiers graphiques non EPS

S'il est facile d'insérer des graphiques EPS dans des documents LATEX,il n'est pas aussi simple d'insérer des graphiques non-EPS (GIF,TIFF,JPEG,PICT,etc.).

[...]

10.3.1 Prise en charge directe des graphiques non EPS

Il est souvent demandé que LATEX et dvips supportent l'inclusion directe de formats graphiques non-EPS,rendant l'insertion aussi facile que celle de fichiers EPS.Bien que cela soit pratique,il y a malheureusement quelques problèmes qui compliquent les choses.

Par exemple,la plupart des formats graphiques non-EPS utilisent des fichiers binaires qui ne peuvent pas être lus par TEX,ce qui empêche LATEX de déterminer la taille des graphiques non-EPS.De plus,le support des graphiques non-EPS nécessiterait également que dvips incorpore des capacités de conversion graphique (GIF vers PS,TIFF vers PS,etc.).Cela nécessiterait non seulement beaucoup de programmation,mais aussi plus de maintenance à l'avenir.

Plutôt que d'incorporer directement des routines de conversion graphique,dvips fournit un mécanisme permettant d'appeler des programmes de conversion externes.Ce mécanisme est accessible depuis LATEX en utilisant l'argument de commande de \DeclareGraphicsRule.Cette méthode présente l'avantage d'être plus souple que la prise en charge directe,et comme elle permet de dissocier la conversion graphique de la conversion DVI vers PS,les utilisateurs sont libres de choisir leur propre programme de conversion graphique.

Une autre approche historique intéressante est décrite dans un article de 1991 , où les photos au format GIF sont converties en une police (!) pour une inclusion directe dans des documents LaTeX.