Font size calculation for text and MathTex is very confusing

[rambip]

Hello there !

I'm currently working on manim-web, a js port of this amazing project.
I noticed that the font-size logic was different, so I wanted to investigate to be sure the behavior is the same.

But looking at the source-code of manim, I'm very confused. I think this would be a good opportunity to rewrite, simplify, comment, and rename variables in the code regarding this logic.

I consider contributing, but I have some questions I would like to clarify before.

From what I understand, the pipeline for MathTex is:

1. render the source string to Tex, DPI then SVG. You get an arbitrary size measured empirically (~10 units in the SVG world ?)
2. extract the paths of the SVG, do NOT normalize them
3. call self.font_size = self._font_size which in turns call the setter
4. the setter does self.scale(font_val / self.font_size), where font_size is a getter
5. the font_size getter returns the confusing self.height / self.initial_height / SCALE_FACTOR_PER_FONT_POINT where SCALE_FACTOR_PER_FONT_POINT=1/960.

So that means the output height is SVG_COMPUTED_HEIGHT * (INPUT_FONT_SIZE / (1 / SCALE_FACTOR_PER_FONT_POINT)), which means SCALE_FACTOR_PER_FONT_POINT is a combination of 2 things: "X svg points should be Y pt" and "Y pts should be Z units in manim"

And the pipeline for Text is:

1. compute size = self._font_size and size /= TEXT2SVG_ADJUSTMENT_FACTOR where TEXT2SVG_ADJUSTMENT_FACTOR = 4.8 (

   manim/manim/mobject/text/text_mobject.py

   Lines 801 to 803 in af70b6f

   	size = self._font_size
   	line_spacing = self.line_spacing
   	size /= TEXT2SVG_ADJUSTMENT_FACTOR

   )
2. Use manimpango to extract svg from text with size=size
3. call self.scale(TEXT_MOB_SCALE_FACTOR) where TEXT_MOB_SCALE_FACTOR=0.05

And for one obscure reason the font-size is defined as:

@property
    def font_size(self) -> float:
        return (
            self.height
            / self.initial_height
            / TEXT_MOB_SCALE_FACTOR
            * 2.4
            * self._font_size
            / DEFAULT_FONT_SIZE
        )

with a hardcoded 2.4 value

For this one, I'm still trying to make sense of it.

Questions

• is it true that the svg paths returned by Tex are not normalized ? It's a probably naive question but why ?
• has SCALE_FACTOR_PER_FONT_POINT been set empirically or is there a reason ?
• what does the size argument of manimpango do ? Why is there scaling after svg generation ?
• I suspect the 2.4 has been added just because 2.4 / TEXT_MOB_SCALE_FACTOR is exactly 48, the default font size. Since they cancel out, why not just do self.height / self.initial_height * self._font_size ?
• Wouldn't it be cleaner to have the same logic for Tex and SVG ? Render SVG in SVG point space, and do the same scaling afterward with one single SCALE_FACTOR_PER_SVG_FONT_POINT constant ?

Notes:

• manim/manim/mobject/text/tex_mobject.py

  Line 101 in bbdcda1

  self.font_size = self._font_size

  has both font_size as a setter and _font_size, quite hard to make sense of
• _font_size could be renamed _required_font_size, and assertions could be added so that the person reading the code knows what properties to expect in the code
• SCALE_FACTOR_PER_FONT_POINT should be renamed SCALE_FACTOR_PER_SVG_FONT_POINT at least
• TEXT_MOB_SCALE_FACTOR is defined in this file: https://github.com/ManimCommunity/manim/blob/main/manim/mobject/text/text_mobject.py . If it is really needed, it should go to the constants.py file
• the size argument of manimpango is not documented

---

I hope my walkthrough is understandable, It was quite an adventure 😅

[uwezi]

Not a real core developer, but I am a bit familiar with font sizes and their problems between different output types, so I can give at least some comments.

• Manim was not planned, it was developed dynamically and I assume all of this goes back to Grant Sanderson's original code. Honestly I don't know why there is any Text() rendered in Pango at all, because everything can be done (better) using LaTeX, though at the cost of speed when rendering for the first time.
• LaTeX and the SVG export are truly scaled, LaTeX internally uses a scaling which is established in the printing business and gives a quite exact, physically measured font size when being printed on paper - however, when viewed on electronic devices with continuous built-in scaling, the relation between an exact text size and the appearance on a screen gets completely wiped out. Reading the same document on a computer screen or a mobile device will most certainly result in the user choosing different physical heights of the letters, unlike a printed book, where the size is fixed once and for all.
• so the scaling inside the SVG is related to how large something would appear when printed at a 1:1 scaling onto paper
• computer screens and operating systems usually give some ppi or dpi setting which gives a relation between pixel height and physical screen height, but since the user still can choose how wide or high something is displayed on the screen by just rescaling the window, this setting is not at all related to the physical size the user sees or interacts with
• the Pango library handles text sizes in the form of bitmapped graphics, not vectorized as LaTeX does, thus it uses a completely different concept - its scaling is based on how many pixels on the screen at a 1:1 zoom factor (image pixels to physical pixels on the screen) would make up the character, but since the resolution of screens widely differ, it does not give any relevant information about the physical size it appears to the user, neither in absolute numbers nor in a ratio to the screen height/width
• Manim at least tries to give comparable output sizes for these two completely different approaches - it fails since the true size of Pango-rendered characters also strongly depend on the font itself, while for LaTeX the text size is mostly independent on the font used, since the fonts themselves are scaled to give the typographic units of pt, em, ex and so on meaningful scaling.
• Manim creates video files which in turn are defined by their resolution (720p,....) and thus has merge the two different worlds together somehow - at the same time the output should take up the same relative amount on the screen independent on whether the scene was rendered at 720p or 4K resolution.

Personally I almost never rely on the font size scaling in my videos. Instead I render almost all text using LaTeX at the standard font size and then I scale text blocks to a certain proportion of my video frame size by using functions like .scale_to_fit_width or .scale_to_fit_height(). This only results in problems when trying to mix the output of several different text-based objects on the scene at the same time, when I have used font-size scaling in LaTeX to preserve the scaling between the different, independent objects.

[uwezi]

class fontSizes(Scene):
    def construct(self):
        rows = VGroup(
            VGroup(
                Text("asdfgASDFG", font_size=fs).move_to([-.5,0,0],aligned_edge=RIGHT),
                Text(f"{fs}", font_size=16),
                Tex(r"asdfgASDFG", font_size=fs).move_to([+.5,0,0],aligned_edge=LEFT)
            )
            for fs in [10,20,30,40,50,60,70,80,90,100]
        ).arrange(DOWN,buff=0.05)
        for row in rows:
            row.shift(LEFT*row[1].get_center()[0])
        self.add(rows)

[rambip]

Not a real core developer, but I am a bit familiar with font sizes and their problems between different output types, so I can give at least some comments.

* Manim was not planned, it was developed dynamically and I assume all of this goes back to Grant Sanderson's original code. Honestly I don't know why there is any `Text()` rendered in Pango at all, because everything can be done (better) using LaTeX, though at the cost of speed when rendering for the first time.

* LaTeX and the SVG export are truly scaled, LaTeX internally uses a scaling which is established in the printing business and gives a quite exact, physically measured font size when being printed on paper - however, when viewed on electronic devices with continuous built-in scaling, the relation between an exact text size and the appearance on a screen gets completely wiped out. Reading the same document on a computer screen or a mobile device will most certainly result in the user choosing different physical heights of the letters, unlike a printed book, where the size is fixed once and for all.

* so the scaling inside the SVG is related to how large something would appear when printed at a 1:1 scaling onto paper

* computer screens and operating systems usually give some ppi or dpi setting which gives a relation between pixel height and physical screen height, but since the user still can choose how wide or high something is displayed on the screen by just rescaling the window, this setting is not at all related to the physical size the user sees or interacts with

* the Pango library handles text sizes in the form of bitmapped graphics, not vectorized as LaTeX does, thus it uses a completely different concept - its scaling is based on how many pixels on the screen at a 1:1 zoom factor (image pixels to physical pixels on the screen) would make up the character, but since the resolution of screens widely differ, it does not give any relevant information about the physical size it appears to the user, neither in absolute numbers nor in a ratio to the screen height/width

* Manim at least tries to give comparable output sizes for these two completely different approaches - it fails since the true size of Pango-rendered characters also strongly depend on the font itself, while for LaTeX the text size is mostly independent on the font used, since the fonts themselves are scaled to give the typographic units of pt, em, ex and so on meaningful scaling.

* Manim creates video files which in turn are defined by their resolution (720p,....) and thus has merge the two different worlds together somehow - at the same time the output should take up the same relative amount on the screen independent on whether the scene was rendered at 720p or 4K resolution.

Personally I almost never rely on the font size scaling in my videos. Instead I render almost all text using LaTeX at the standard font size and then I scale text blocks to a certain proportion of my video frame size by using functions like .scale_to_fit_width or .scale_to_fit_height(). This only results in problems when trying to mix the output of several different text-based objects on the scene at the same time, when I have used font-size scaling in LaTeX to preserve the scaling between the different, independent objects.

Thank's !
I understand some of the code a bit more clearly now:

1. For Tex

SCALE_FACTOR_PER_FONT_POINT=1/960 is exactly 0.5/10/48. We know that:

• The default fontsize set by manim is 48
• Tex default fontsize is exactly 10pt
• 1pt for Latex corresponds to $\alpha$ pixel-units in SVG (probably 1.333)
  That means that one "default manim fontsize" will be $\frac{1}{2}\alpha$ units on the screen.

2. Now for Text

We know that:

• manim scales down the default font size from 48 to 10 with TEXT2SVG_ADJUSTMENT_FACTOR = 4.8
• manimpango uses pt by default (we can know it from this line: https://github.com/ManimCommunity/ManimPango/blob/e525054638330f62c46ec2e0ce65d5800b45e5a8/manimpango/cmanimpango.pyx#L287)
• then, the same pt->px conversion is applied with $\alpha$
• then it's scaled with TEXT_MOB_SCALE_FACTOR=0.05

That means that one "default manim fontsize" will be $0.05 \times 10 \alpha = \frac{1}{2} \alpha$

Great ! I feel like I just solved a math puzzle 😄

---

If I contribute a PR, I will probably use these constants:

• TEX_DEFAULT_FONTSIZE_PT=10
• PT_TO_PX_SVG=1.33 (or check what is actually used)
• MANIM_FONTSIZE_IN_WORLD_SPACE=0.5*PT_TO_PX_SVG