remove_stray_braces: \{ should not be taken into account

[mz71]

TexMobject("\{") gives an error, because the string "\\{" goes through the function remove_stray_braces which balances the unbalanced { to make a "\{}", which gives a Latex error.

The same thing applies to TexMobject("\}").

A quick fix would be to add those lines to the remove_stray_braces, although this should be consulted with more knowledgable person in Latex (or Python as a matter of fact):

num_lefts_bogus, num_rights_bogus = [
            tex.count(char)
            for char in ['\\{','\\}']
        ]
        num_lefts -= num_lefts_bogus
        num_rights -= num_rights_bogus

[cobordism]

From the LaTeX side, a \{ could also be typeset as \lbrace.
Thus before remove_stray_braces is called here: https://github.com/ManimCommunity/manim/blob/master/manim/mobject/svg/tex_mobject.py#L57
we could replace \{ with \lbrace and keep remove_stray_braces as is.

The nice part is that this function is already called "modify_special_strings" :)

[mz71]

Okay, so I digged up (as always at Stack Exchange) and it turns out that \lbrace is invalid in text mode. If I use

TexMobject("\text{ \{ }")

changing it to \lbrace would be an Latex error. So I must disagree with @cobordism solution :(

[cobordism]

\ensuremath{\lbrace} ?

or (like in stackexchenge): \ifmmode\lbrace\else\textbraceleft\fi

[behackl]

I think remove_stray_braces should be removed, we should encourage users to write syntactically correct TeX.

[leotrs]

Agreed

…

On Sun, Nov 15, 2020, 2:43 PM Benjamin Hackl ***@***.***> wrote: I think remove_stray_braces should be removed, we should encourage users to write syntactically correct TeX. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#225 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAILYAH2YI5PTIKVQSUS3DDSQAVMNANCNFSM4POC2WYA> .

[cobordism]

what is remove_stray_braces supposed to do? Is it really only to correct stupid errors, or does it have something to do with multiple arguments like

Tex(r"\here is some \textbf{bold text", r" that comes in} two parts")

?

[behackl]

Good question: you are right, it is being used when groups are split up like that:

>>> Tex(r"\textbf{well hello", " there}")
[11/15/20 21:05:58] INFO     Writing "\textbf{well hello there}" to             tex_file_writing.py:81
                             media/Tex/44afcc03ed68efd5.tex                                           
appended }
[11/15/20 21:05:59] INFO     Writing "\textbf{well hello}" to                   tex_file_writing.py:81
                             media/Tex/604cb5db637fd0b5.tex                                           
prepended {
                    INFO     Writing "{there}" to                               tex_file_writing.py:81
                             media/Tex/adc1dd29273e5700.tex                                           
Tex('\\textbf{well hello there}')

(note the appended } and prepended { lines in the log, I've added those with prints.)

This means we should probably keep it (although the rendered tex strings actually make me wonder whether the behavior of rendering all three, \textbf{well hello there}, \textbf{well hello} and {there}, is correct. Do you think this seems okay, @cobordism?

[cobordism]

it is being used when groups are split up like that:

I thought as much.

This means we should probably keep it (although the rendered tex strings actually make me wonder whether the behavior of rendering all three, \textbf{well hello there}, \textbf{well hello} and {there}, is correct.

So yeah. it is strange. Here is the best I can make of it.
The only actual tex that gets shown in the manim video, it the compilation of the entire string. However, the substrings are compiled individually and my guess is that this is used to identify which parts of the whole svg correspond to the substrings.

In your example we know that {there} will not be bold, but well hello there and well hello will be bold... and yet Tex(r"\textbf{well hello", " there}")[1] will be the word "there" in bold.

I never figured out exactly how this works...

[behackl]

I never figured out exactly how this works...

I just had a brief look: essentially, MathTex.break_up_by_substrings is responsible for that; it splits the fully rendered string into multiple submobjects by counting how many objects the SVGs rendered from the substrings have. In the example above, \textbf{well hello there} is rendered, then \textbf{well hello} is rendered and the number of objects imported from the corresponding SVG is counted (something like 4+5 = 9 in this case?), then the first 9 objects from the full string are grouped together. And so on.

This explains #209: Manim does not know in which order things appear in the SVG, and thus cannot apply the colors in the correct order.

I am actually surprised this works as well as it does.

[behackl]

Closing this for now, the original issue has been (sort of) resolved via #240.