TeX - LaTeX Asked by rpapa on April 18, 2021
This is a question that I have been asking myself for a while and I have not found an answer.
Is it because of licensing issues? Because of the file format? Some other reason?
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
defGinclude@gif#1{%
ifluatexelsebaseSixtyFour{#1}encodedGiffi%
dimen@Gin@urx pt%
advancedimen@ by-Gin@llx pt%
edefGin@svg@view@width{strip@ptdimen@}%
dimen@Gin@ury pt%
advancedimen@ by-Gin@lly pt%
edefGin@svg@view@height{strip@ptdimen@}%
dimen@Gin@svg@real@height@bp pt%
advancedimen@ by-Gin@ury pt%
edefGin@svg@view@base{strip@ptdimen@}%
Gin@[email protected]@req@width%
Gin@[email protected]@req@height%
raisestrip@ptGin@req@height bphbox{%
special{dvisvgm: raw
<g transform="translate({?x},{?y})">
<svg overflow="ifGin@clip hiddenelse visiblefi" width="strip@ptGin@req@width" height="strip@ptGin@req@height"
viewBox="Gin@llxGPT@spaceGin@svg@view@baseGPT@spaceGin@svg@view@widthGPT@spaceGin@svg@view@height">
<image width="Gin@svg@real@width@bp" height="Gin@svg@real@height@bp"
xlink:href='data:image/gif;base64,{?nl}%
ifluatexdirectlua{media4svg.base64("#1",72,"{?nl}")}%
elseencodedGiffi'/>
</svg>
</g>}%
}%
}
letGread@gifGread@bitmap
makeatother
RequirePackage{media4svg} % provides base64-encode utility
ExplSyntaxOn
letbaseSixtyFourmsvg_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}
noindentincludegraphics[width=linewidth]{Newtons_cradle_animation_book_2.gif}
end{document}
Correct answer by AlexG on April 18, 2021
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.
Answered by Marijn on April 18, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP