Latex compilation and svg error

[SalekDev]

Bug - Part 1

Relates to #2440. A few days ago i stumbled upon a strange bug when compiling a latex file. The error ocurrs in the module utils/tex_file_writing.py in the function full_tex_to_svg(), it pops out from the constructor of Tex. Specifically it is the line 108

process = subprocess.run(
        [
            compiler,
            *(['-no-pdf'] if compiler == "xelatex" else []),
            "-interaction=batchmode",
            "-halt-on-error",
            f"-output-directory={temp_dir}",
            tex_path
        ],
        capture_output=True,
        text=True
    )

When executing this process it fails miserably despite previously being able to write the complete latex file:

tex_path.write_text(full_tex)          # Writes the file properly

Meaning that both tex_path and temp_dir (which relates to the declaration tex_path = temp_dir / "working.tex") are correct paths. I debugged it a little for a while but it didn't make much sense and it also didn't help that the error message was not explicit at all.

Solution

A few days later I now come back to the issue and the problem was simply that python or latex was getting confused with the directories. Replacing the command with

process = subprocess.run(
        [
            compiler,
            *(['-no-pdf'] if compiler == "xelatex" else []),
            "-interaction=batchmode",
            "-halt-on-error",
            "working.tex"
        ],
        capture_output=True,
        text=True,
        cwd=temp_dir
    )

Fixed it for me.

python version: 3.13.12
manimgl version: 1.7.2
Latex:
pdfTeX 3.141592653-2.6-1.40.29 (TeX Live 2026)

Bug - Part 2

After having solved the latex compilation issue (so the only change I made to my local copy of manim is the above substitution), now I run into the issue of an svg not creating properly. I haven't looked exhaustively into the issue but upon a quick inspection while debugging I noticed the first time the function latex_to_svg() runs it outputs a non-empty svg xml. The first time it runs is inside the parent constructor of Tex() in line 69:

super().__init__(
            tex_string,
            use_labelled_svg=use_labelled_svg,
            isolate=isolate,
            **kwargs
        )

ends up calling

def get_svg_string_by_content(self, content: str) -> str:
           return latex_to_svg(content, self.template, self.additional_preamble, short_tex=self.tex_string)

However right after when running get_tex_mob_scale_factor() the call latex_to_svg("0", show_message_during_execution=False) gives an empty svg. This is:

super().__init__(
            tex_string,
            use_labelled_svg=use_labelled_svg,
            isolate=isolate,
            **kwargs
        )

        self.set_color_by_tex_to_color_map(self.tex_to_color_map)
        self.scale(get_tex_mob_scale_factor() * font_size)

that last line calls:

@lru_cache(maxsize=1)
def get_tex_mob_scale_factor() -> float:
    # Render a reference "0" and calibrate so that font_size_for_unit_height
    # gives a height of 1 manim unit. Compensates for platform dvisvgm differences.
    font_size_for_unit_height = manim_config.tex.font_size_for_unit_height

    svg_string = latex_to_svg("0", show_message_during_execution=False)

    svg_height = get_svg_content_height(svg_string)
    return 1.0 / (font_size_for_unit_height * svg_height)

and svg_string ends up being an xml containing an empty svg.
Another weird thing is the following: when latex_to_svg("0", show_message_during_execution=False) gets called it leads to the second time of full_tex_to_svg() being called. The first time full_tex_to_svg() is called is to create my latex text and this second time it should create a tex document with a "0". However, the execution seems to completely skip the second time full_tex_to_svg() is called because the debugger does not stop at the breakpoints the second time but the first time it does.
I'm fairly new to this so forgive me if I'm making some sort of mistake or misunderstanding but I feel like it is a strange error.

python version: 3.13.12
manimgl version: 1.7.2
Latex:
pdfTeX 3.141592653-2.6-1.40.29 (TeX Live 2026)
dvisvgm version: 3.6

Note: This all happens when just calling the Tex constructor.
PS: Windows 11 OS

[Varniex]

Hi @SalekDev, I've been working with Typst (fairly easy to install and no "package" related stuff) in ManimGL for about two months. This PR works well. Would you like to give it a try? and if you encounter any bug, please free to report it. Thanks!

[SalekDev]

Ok I will give it a try and report what I find, thanks

[SalekDev]

@Varniex I just installed it and used your class TypstTex and exactly the same problem happens. First, Python (or Windows 11) trips out when you tell it to compile the file at tex_path and export to svg_path in your function typst_tex2svg(). Changing the command to

process = subprocess.run(
            ["typst", "compile", "--format", "svg", "working.typ", "working.svg"],
            capture_output=True,
            text=True,
            cwd=temp_dir
        )

fixes the issue for me.

But then again when calling get_tex_mob_scale_factor() of tex_mobject.py:

@lru_cache(maxsize=1)
def get_tex_mob_scale_factor() -> float:
    # Render a reference "0" and calibrate so that font_size_for_unit_height
    # gives a height of 1 manim unit. Compensates for platform dvisvgm differences.
    font_size_for_unit_height = manim_config.tex.font_size_for_unit_height
    svg_string = latex_to_svg("0", show_message_during_execution=False)
    svg_height = get_svg_content_height(svg_string)
    return 1.0 / (font_size_for_unit_height * svg_height)

the svg_string generated is empty. I suspect it has something to do with the way stuff is getting cached but I don't know how this works exactly. Before, without using your typst implementation, I thought that the sequential calling of full_tex_to_svg() (in the constructor Tex()) was causing some caching issues on the second call because the first call (when creating the latex svg itself) it worked no problem but the second time it is called in latex_to_svg("0", show_message_during_execution=False) the debugger skips every single breakpoints inside full_tex_to_svg() for some reason.

And now with typst the svg of the actual tex is created fine after my first fix but the critical point is still full_tex_to_svg() in the return line of latex_to_svg("0", show_message_during_execution=False) because it still creates an empty svg seemingly because program skips full_tex_to_svg() completely due to some caching bugs. So it finally fails in the final lines of get_tex_mob_scale_factor() when trying to calculate the svg height.

Also, is the svg created by typst supposed to look like this?:

I feel like it shouldn't but idk. It was the result of TypstTex("x y z")

[Varniex]

No, the SVG shouldn't look like this. usepackage only used by LaTeX not Typst.

Did you add typst template in tex_templates.yml and specify the template as typst? And, the code in the files typst_tex_mobject.py and typst_tex_symbol_count.py should work (without using the functions from tex_mobject.py). Please confirm you have these changes in your system.

[SalekDev]

Ok yeah i changed the template to typst now. And yes none of your code that generates the svg requires the functions of tex_mobject.py, it is get_tex_mob_scale_factor() the problematic function that runs in the constructor of Tex() and since you inherit Tex it still causes issues in my system. Specifically the call latex_to_svg("0", show_message_during_execution=False) since it returns an empty svg because it seems like it skips the execution of the svg file compilation.

[SalekDev]

I see now, it seems like my code didn't merge your branch properly since you have a constant for the scale factor instead of running get_tex_mob_scale_factor() and I don't, I will change that and that should hopefully fix everything, thanks

[Varniex]

Sure! Let me know if that fixes the problem. Just use the code in its entirety and it'll work.

[SalekDev]

Now I get an error in set_symbol_count() right at the end of the constructor. It says

elif match.group("script") or (match.group("command") and num == 0):
                                   ~~~~~~~~~~~^^^^^^^^^^^
IndexError: no such group

[Varniex]

Oh! right. Try replacing it with "cmd" in both lines 176 and 189. I shortened the name of the group and forgot to change here. My bad.

[SalekDev]

Yeah I figured but I wanted to make sure. Thanks! Now it has worked for these last few attempts, you just saved my school project. Thank you very much