1

Motivation

I want to use emojis in Manim, an animation software which uses LaTeX for rendering in the background. The pipeline is:

  1. generate a TeX file
  2. run dvilualatex on it to convert it to DVI
  3. run dvisvgm to convert the DVI to SVG

I found out that the twemojis package imports a PDF for each emoji. While PDF cannot be imported directly, it is easy to batch-convert all the emojis to EPS, so this sounds like a reasonable approach. However, it is not as simple as it might seem – for some reason, the spacing around the imported EPS files have really weird spacing around them.

Step-by-step reproduction

  1. Download the twemojis package: https://mirrors.ctan.org/macros/latex/contrib/twemojis.zip
  2. Unzip it, go to ./pdf-twemojis and choose one emoji – for example 1f622.pdf
  3. Convert it to EPS using pdftops -level3 -eps 1f622.pdf 1f622.eps
  4. Create a minimal example.tex file:
\documentclass[preview]{standalone}
\usepackage[T1]{fontenc}
\usepackage[dvisvgm]{graphicx}
\begin{document}
Hello \includegraphics[height=\baselineskip]{./1f622.eps} world.
\end{document}
  1. Convert it to DVI using dvilualatex example.tex
  2. Convert it to SVG using dvisvgm example.dvi
  3. The resulting file has a weird space:
    SVG output

.

This seems to be a problem with dvilualatex, not dvisvgm. Viewing the DVI file in Okular produces a similarly broken result:
DVI in Okular

The entire source folder of this example is available here.

Question

What is causing this weird spacing and how do I get rid of it? I could just place a large negative space after every emoji, but it feels very hacky and likely to break once I change the size of the font or the environment (eg. to equation or align).

7
  • Manim offers three compiler options: latex, pdflatex and lualatex. I don't know what exact commands are called for the other two, so I can't test it outside of Manim, but the result in Manim has the same weird spacing for each option. I would prefer to stick to the TeX → DVI → SVG pipeline, since if I wanted to use a different one, I'd have to fork Manim and reimplement a lot of stuff.
    – m93a
    Oct 24, 2021 at 19:29
  • Removing \usepackage[T1]{fontenc} didn't change the output SVG, it just made the intermediate DVI unopenable in Okular.
    – m93a
    Oct 24, 2021 at 19:32
  • I think the compiler options in Manim are just confusingly named – I'm pretty sure that each method compiles to DVI and then uses dvisvgm to convert to SVG. For example, choosing the lualatex option compiles using the dvilualatex command.
    – m93a
    Oct 24, 2021 at 19:39
  • 1
    if I remove the preview option your workflow works for me. Oct 24, 2021 at 19:42
  • @DavidCarlisle I didn't quite follow the development, but imho dvisvgm can handle luatex + open type fonts since last year. Oct 24, 2021 at 20:14

1 Answer 1

4

The preview calculation appears off. If you surround it with \fbox to debug the size it works, even if you make the fbox rule invisibly thin:

enter image description here

\documentclass[preview]{standalone}
\usepackage[T1]{fontenc}
\usepackage[dvisvgm]{graphicx}
\setlength\fboxrule{1sp}
\begin{document}
Hello \fbox{\includegraphics[height=\baselineskip]{1f622.eps}} world.
\end{document}
2
  • It works, thank you! But do you have any idea why? O.o
    – m93a
    Oct 24, 2021 at 20:18
  • 2
    @m93a no sorry I didn't trace, I added \fbox just to see whether the extra space came inside or outside the box, just to start debugging where it came from. But there was no space, so I set the rule width to 0 but the space came back, so set it to 1sp and gave up but posted the answer.... Oct 24, 2021 at 20:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .