ManimPango should be a plugin

[eulertour]

There are a number of problems with our integration with Pango that are detrimental to library's code hygiene. Only one community member understands the code, how to build it, and how to deploy it. It's caused difficulty for installation and development from the time it was first added to as recently as #1075, but more than either than those it just isn't necessary for manim's use.

We developed the plugin system but continually find reasons not to use it, even in instances like this that it was designed for. I'm fine with keeping it in the pypi package, but leaving ManimPango in the main code doesn't make much sense to me.

As an aside, there are a number of additions that we should probably consider moving into plugins as well, such as jupyter integration and (more of) the webgl renderer now that #1075 is merged.

[naveen521kk]

There are a number of problems with our integration with Pango that are detrimental to library's code hygiene.

Can you elaborate?

Only one community member understands the code, how to build it, and how to deploy it.

@PhilippImhof also has knowledge about that

It's caused difficulty for installation and development from the time it was first added to as recently as #1075

What were the problems you faced in #1075? I don't see any reports on the problem in installation problems of ManimPango.

it just isn't necessary for manim's use.

Manim should have at least one Text Rendering Engine either LaTeX or Pango, and we are encouraging in our docs that LaTeX are optional so Pango should be included in the Core of Manim IMO, as in how it is now.

We developed the plugin system but continually find reasons not to use it, even in instances like this that it was designed for. I'm fine with keeping it in the pypi package, but leaving ManimPango in the main code doesn't make much sense to me.

Are you thinking of depreciating Text and remove it from the Core library and make a plugin to provide it? Will, it not break things? ManimPango being used in the upstream repo also, I think there was no issue there, other than https://github.com/3b1b/manim/issues/1391 which was fixed in the recent release(https://github.com/ManimCommunity/ManimPango/issues/27).

I would something like manim-rubikscube is fit to be a plugin because many people don't find it useful enough to have it in the Core Library. But, if you think about Text it is a thing which is used pretty much everywhere.

As an aside, there are a number of additions that we should probably consider moving into plugins as well, such as jupyter integration and (more of) the webgl renderer now that #1075 is merged.

In that case, what do you think should be part of the core library?

[PhilippImhof]

I fully agree with @naveen521kk: Manim should offer at least one way of integrating text without the need of a LaTeX installation. And this functionality should be included in Manim's core. For as much as I love LaTeX, we have to admit that it is "big" and that e.g. installing und using custom fonts with LaTeX is not easy for everyone.

[behackl]

When it comes to problems that users run into, we actually get a lot more reports about issues with TeX than with Pango; the situation with Pango really has improved dramatically since ManimPango has been introduced.

While I'm not active in ManimPango development, I do have a basic understanding about how it works as well.

If you ran into issues with it in #1075 then I am sure we can fix them. But I am firmly against removing it as a core feature (apart from the fact that it is not clear to me which problem that would solve -- whatever you ran into in #1075 would have to be resolved even if support for Text was delegated to a plugin).

[WampyCakes]

I agree with Naveen's assessment of when the plugin system is useful. I think it makes more sense to have things like jupyter (or in this case a text engine) in the core of manim. If it's (among other things) delegated to a plugin, chances are high that it will not receive much attention and therefore no longer work with later versions of manim. When something like the rubikscube is outside the scope of the manim core, that's when plugins make the most sense. But I think a lot of current and future features belong more in the library than in plugins.

I also reinforce behackl's observation that there are more issues reported with tex than pango as I've noticed the same.

[eulertour]

There's a lot to go over here and text isn't the best medium, so I'd prefer to do this on discord or a voice call. To get started here, we can focus on this

Only one community member understands the code, how to build it, and how to deploy it.

@PhilippImhof also has knowledge about that

From looking at the commit history almost all contributions from @PhilippImhof have been minor bugfixes; nearly every line was written by @naveen521kk. It also involves use of the CPython and Pango APIs, both of which will be slow to work with since they use C and the project is primarily in Python. This is a single point of failure, which is indicative of poor code hygiene.

[PhilippImhof]

From looking at the commit history almost all contributions from @PhilippImhof have been minor bugfixes; nearly every line was written by @naveen521kk.

That's normal, he started the whole thing. There was a time nearly every line of Manim was written by Grant. @naveen521kk started ManimPango, because Pango was abandoning their Python bindings. We had discussions on Discord about what to do. Among the different alternatives, no one suggested removing text capabilities from Manim IIRC.

ManimPango was done somewhat in a hurry, in order to have something to get started with and keep Manim's text functionality running with no interruption. Now that things have settled a bit, @naveen521kk and I are doing a complete refactoring and cleanup. I am currently planning for that.

It also involves use of the CPython and Pango APIs, both of which will be slow to work with since they use C and the project is primarily in Python.

Slow to work with, as opposed to lightning fast LaTeX which we currently use for text and which would be the only way to include text into an animation once we remove ManimPango? Also, speed has never been an issue before and text (be it Cairo or Pango) has been in Manim for a while now. Sorry, but that sounds like a straw man.

This is a single point of failure, which is indicative of poor code hygiene.

That's true, this point is definitely yours.

However, one objective of the refactoring mentioned above is to make it easier for ManimPango to be used in other Python projects where people want to draw formatted text. Once this happens, ManimPango will probably get more attention and more people will be able to keep up its development.

Also, if we keep text functionality in Manim's core, the community will do its best to maintain the code if @naveen521kk and I should get hit by the well-known bus. After all, we all managed to get into Grant's Manim code which was a much bigger code base and, with all due respect, not extremely well documented.

[naveen521kk]

There's a lot to go over here and text isn't the best medium, so I'd prefer to do this on discord or a voice call.

I can only come for a call next week.

From looking at the commit history almost all contributions from @PhilippImhof have been minor bugfixes; nearly every line was written by @naveen521kk.

PhilippImhof was the author of MarkupText see https://github.com/ManimCommunity/ManimPango/pull/1 the history shows like that because I recently moved files https://github.com/ManimCommunity/ManimPango/pull/31. Also, he reviews every code I write, see the PR section, other than the CI configuration.

Also, I was the one to write all the packaging scripts, which anyone can read and understand easily.

It also involves use of the CPython and Pango APIs, both of which will be slow to work with since they use C and the project is primarily in Python. This is a single point of failure, which is indicative of poor code hygiene.

ManimPango is a separate project and it isn't an extension build inside of Manim. Consider it like how you will do Pillow or pycairo or for the matter any C extensions. Would you say them slow and not use them? Or you would say, the project is primarily python so it shouldn't be used? (that looks crazy!).

[eulertour]

Consider it like how you will do Pillow or pycairo or for the matter any C extensions.

These are maintained by their own teams and presumably have several people supporting them. The same isn't true of ManimPango.

Also, I was the one to write all the packaging scripts, which anyone can read and understand easily.

This is subjective, you could just as well say the entire library can be read and understood easily.

PhilippImhof was the author of MarkupText...

I consider a having part of library written in a more difficult language that most of the team doesn't use, and maintained by one person who does nearly everything and another who makes <1 contribution a month to be poor code hygiene. It's fine if you disagree with that, but that'd probably be a reasonable evaluation for most people.

[PhilippImhof]

Consider it like how you will do Pillow or pycairo or for the matter any C extensions.

These are maintained by their own teams and presumably have several people supporting them. The same isn't true of ManimPango.

Not yet. As I wrote above, other projects might be interested in using ManimPango, especially with the end-of-life of Pango's Python bindings.

I consider a having part of library written in a more difficult language that most of the team doesn't use, and maintained by one person who does nearly everything and another who makes <1 contribution a month to be poor code hygiene. It's fine if you disagree with that, but that'd probably be a reasonable evaluation for most people.

I still do not disagree (as you might have read in my comment above). However, I come to a different conclusion.

My starting point is that Manim should have text functions that do not depend on LaTeX. (Anyone is free to disagree.) Then we need something to do that. We used to have Pango with its Python bindings. Unfortunately, this is no longer maintained. We then looked whether something else was readily available. This was not the case. So @naveen521kk started ManimPango. If one day he cannot or does not want to maintain it anymore, we will do the same again: We will ask ourselves whether Manim needs text functions and if it does we will either find ways to maintain ManimPango or look for an alternative which might exist by then.

Removing ManimPango and all text functions from the core just for the fear that one day it might be unmaintained will definitely not help in having more people want to engage with that part of the code.

Also MarkupText has gotten more features and together with my recent contribution to Pygments it will soon improve code rendering in animations as well. Some people never use anything else than LaTeX for their texts. That's fine, but remember we are building a community tool and our own use patterns are not necessarily valid for everyone.

[eulertour]

My starting point is that Manim should have text functions that do not depend on LaTeX.

I can't come even this far; everything that attracted people to manim was accomplished with only Latex, and most people who use manim don't use it with Latex. There's a substantial natural overlap between people who use Latex and people who use manim, and since it allows for rendering equations and manim is primarily used for STEM, most projects using manim will end up using it anyway.

The benefits that come with using vanilla text are nice to have, but given the choice between one of them to support in the main code I don't see why you would choose regular text.

[behackl]

everything that attracted people to manim was accomplished with only Latex

I've seen various projects on computer science-y stuff like algorithm visualization which often make use of Text (and in particular Code), and little to no Tex.

[eulertour]

virtually everything*

[naveen521kk]

Also, I was the one to write all the packaging scripts, which anyone can read and understand easily.

This is subjective, you could just as well say the entire library can be read and understood easily.

Anyone with some amount of knowledge on building C stuff can understand that.

I consider a having part of library written in a more difficult language that most of the team doesn't use, and maintained by one person who does nearly everything and another who makes <1 contribution a month to be poor code hygiene. It's fine if you disagree with that, but that'd probably be a reasonable evaluation for most people.

Well in that case, according to you, all the glsl stuff you added in #1075 and the WebGL(javascript) stuff are of poor code hygiene. Because AFAIK only @eulertour and Grant have knowledge about them and they do literally everything. In that case shouldn't all that be a plugin because of "poor code hygiene"?

You can say that part of code is used by everyone so, it should be in Core of Manim, yeah true, but what if you aren't there to maintain it? That is the case you are talking about now.

In either case, there are two maintainers here on ManimPango, one myself and @PhilippImhof, and I also think @behackl should have some experience with Cython, because IIRC, is from sagemath which uses Cython.

Essentially, for me having something which will work without the installation of LaTeX seems to be better for me. LaTeX is huge and is slow, and we use to call them from the command line, where there could be a lot of problems.

[PhilippImhof]

I think this all should come with no bad feelings whatsoever. @eulertour is certainly right in saying that ManimPango needs more people involved (or at least being capable of maintaining it). This might be true for other parts of Manim, but that is not a reason to not address it.

IMHO we should maintain the planned course of action, i.e. refactor ManimPango as planned. Then we can give other community devs the opportunity to have a closer look at it (of course, they are already free to do so now, but we should probably make this more explicit) and give them the ability to maintain it if need be. Also, after the refactoring, other projects might start using it and this could lead to having even more people involved.

Removing Text and MarkupText from Manim's core would be a bad choice IMHO.

[eulertour]

Well in that case, according to you, all the glsl stuff you added

I'm sure you know why that'd be a bad decision.

But the issue is deeper than simply putting more effort into ManimPango, since that effort would be better spent on facilitating the migration to OpenGL and the possibilities it makes available. When breakages are virtually guaranteed, our documentation coverage is dropping as the library's complexity is growing, and devs are becoming less and less familiar with how the library works, it doesn't make much sense to incur the opportunity cost of putting more effort into text rendering.

The fact that OpenGL opens up lots of possibilities through interaction and 3D rendering makes the problem that much worse.

[naveen521kk]

Well as @PhilippImhof said already there are plans to provide a stable API that can be used outside of Manim as there isn't a project in PyPI like ManimPango to render text say to an Image or SVG file, and also the wheels which makes it so that it is easily installable. It can be used in Pillow and also in other Project which doesn't have these capabilities directly. As in what I meant to say ManimPango is a separate project which Manim depends on, and it should be fine to have in the Core. About maintainability, I would say that after I and @PhilippImhof do a refactor, other projects could depend on it and other developers could also help in maintaining it. Depreciating or removing a feature, that actually works without any issue, which opens a lot of possibilities that would make Manim generate videos in other languages easily, for example, Arabic or something isn't that great. You can argue that they can use LaTeX but it isn't a thing made for that, and it is heavy and slow, and people would need special knowledge on how to, I myself don't know that.

[eulertour]

Well as @PhilippImhof said already there are plans to provide a stable API...

What do you mean by a "stable" API? I didn't know there was anything unstable about the API right now.

that actually works without any issue...

This just isn't true.

would make Manim generate videos in other languages easily, for example, Arabic

Even as someone who has never attempted to write Arabic in Latex, I'm going to guess that this isn't very difficult with Latex.

[naveen521kk]

Well as @PhilippImhof said already there are plans to provide a stable API...

What do you mean by a "stable" API? I didn't know there was anything unstable about the API right now.

https://github.com/ManimCommunity/ManimPango/issues/28

that actually works without any issue...

This just isn't true.

I haven't heard of any problems that haven't been fixed.

[naveen521kk]

I don't want or not have any interest in taking this discussion further. If you want it as a plugin do the needs of making it a plugin.

[leotrs]

I have not read the entire thing, but I do want to highlight this fact:

I consider a having part of library written in a more difficult language that most of the team doesn't use, and maintained by one person who does nearly everything and another who makes <1 contribution a month to be poor code hygiene. It's fine if you disagree with that, but that'd probably be a reasonable evaluation for most people.

Well in that case, according to you, all the glsl stuff you added in #1075 and the WebGL(javascript) stuff are of poor code hygiene.

I'm sure you know why that'd be a bad decision.

The first comment ends with a sentence that basically says "most people would agree with me". I highly dislike the tone of this message. @eulertour if your contributions are met with pushback, it is your job to convince us by using arguments. It does not matter whether "most people" would agree with you. When we are talking about commiting changes to the library, the only people that matter are the dev team. If you can say that "most of the dev team" agrees with you, then that's fine. Otherwise, "most people would agree" is an invalid argument in my book.

The second comment brings up a fact that I want to echo. All the JS renderer and the openGL renderer cannot currently be maintained by anyone other than @eulertour. (Please correct me if I'm wrong.) By @eulertour's own words, this is poor code hygiene.

The third sentence also rubs me the wrong way. I understand this sentence as "it is obvious you are wrong". @eulertour I must ask you in the future to provide arguments rather than say such things.

@naveen521kk I respect your decision to not take part of this discussion, but that alone doesn't solve the issue that this thread is supposed to address. I believe a consensus was reached by @eulertour and @naveen521kk on discord. Can you please update this thread with that consensus so that other interested parties can chime in?

[friedkeenan]

I think even saying "most of the dev team would agree with me" is still tonally iffy. For starters, this issue shows that there is disagreement in the first place, and so that statement cannot be taken as true without further evidence, because as it is, it's just your estimation that most would agree with you, and I don't like how that frames the conversation into "Most devs agree with me and therefore disagree with you". Second of all, the original phrasing of "that'd probably be a reasonable evaluation for most people" implicitly conveys that the opposing evaluation is not reasonable, whether you intended to convey that or not. I think something like "I don't think my evaluation is unreasonable" would work just as well while being less tonally iffy.

[eulertour]

The first comment ends with a sentence that basically...

There are three things to say about this.

First, you can replace the end of the sentence with "most of the dev team" and I still stand by it, I'd just rather make a more general solution than a more specific one.

Second, the tone of the sentence is extremely mild, and I don't think it's possible even to have disagreements if they have to be worded more lightly than that.

Third, I've said before that if every other member of the dev team decided to make it preventatively difficult to merge commits I'd continue to merge commits anyway, and I still stand by that. My fundamental goal in this project is to do what's best for manim, and convincing people comes downstream from that.

The second comment brings up a fact that I want to echo...

I agree with this.

The third sentence also rubs me the wrong way...

First, the argument is basically that failure to implement OpenGL rendering at the same time that Grant is pushing to make Manim more of a community tool constitutes an existential threat to ManimCE. I can elaborate more if you want me to.

Second, if this rubs you the wrong way then what @naveen521kk said prior should do the same:

Well in that case, according to you, all the glsl stuff you added in #1075 and the WebGL(javascript) stuff are of poor code hygiene.

what if you aren't there to maintain it? That is the case you are talking about now.

If someone else speaks to me with a harsh tone I'll generally take that as license to respond in kind. In this particular case the tone of my response is more mild than the tone I was responding to.

[eulertour]

this issue shows that there is disagreement in the first place

To be crystal clear:

1. I don't think anyone disagrees with what I said there, and the statement isn't to say that anyone disagrees with anyone.
2. The statement I was referring to isn't the topic of this thread, it's a more general one about code hygiene. To address the later responses, I absolutely agree that the OpenGL code exhibits bad code hygiene for the exact same reasons.

On the point of the tone being too harsh, I don't think this level of tone moderation is sustainable.

[kilacoda-old]

Ok, so to summarise both sides' arguments here amidst all this bickering about tone and stuff (feel free to edit if I miss anything):

EulerTour's assertions:

ManimPango (and with it Text) should be removed from the core library and redelegated as an external optional dependency/plugin, because:

• ManimPango caused problems in some installations, particularly Windows installations when it was first launched in both upstream and downstream installs
• There are only 2 members of the team (namely naveen521kk and PhilippImhof) with knowledge of how MP works, which is bad code hygeine
• Supporting Pango forces us to maintain our own set of bindings written in C, which most of the dev team is not well-versed with.
• Text causes problems with the OpenGL renderer
• Most of what can be done with Text can be done with LaTeX, hence supporting Text is somewhat redundant.

naveen521kk and PhilippImhof's Rebuttals:

ManimPango and Text should remain in the core library as is the current status quo, because:

• The problems caused by Pango/ManimPango have been solved with subsequent releases, and both upstream and downstream installs work fine on a majority of platforms.
• By that logic, only 1 person (EulerTour) is working on the WebGL/OpenGL renderers (EulerTour agrees with this point)
• Same argument, most of the dev team is not well versed with OpenGL as well (potential solution: both sides educate us on their respective topics; suggested by leotrs)
• (couldn't find a reply to this point :/)
• LaTeX is not fit for every use case, such as right-to-left text, using system fonts etc. For such situations, Text (and its derivatives, such as MarkupText) are valuable alternative solutions, and hence it would be a bad idea to remove them from core manim.

[behackl]

Thank you for summarizing, @kilacoda!

Text causes problems with the OpenGL renderer

Given that Text, just as Tex mainly does stuff to provide a SVG which we then use via SVGMobject, I would think that as soon as we support rendering SVGMobject, both Tex and Text should work. I think this was also briefly discussed in Discord.

[leotrs]

The first comment ends with a sentence that basically...

There are three things to say about this.

First, you can replace the end of the sentence with "most of the dev team" and I still stand by it, I'd just rather make a more general solution than a more specific one.

As @friedkeenan said, I simply don't see the evidence for this.

Second, the tone of the sentence is extremely mild, and I don't think it's possible even to have disagreements if they have to be worded more lightly than that.

Once again, like many times in the past, I find your response unacceptable. It seems like whenever you are met with pushback, your response is to deny there is anything to be discussed at all, and you default to assuming you are always right. In this particular instance, you say that the sentence is "extremely mild" right after I told you I have a problem with it. Instead of talking about it, or admitting that it could have been phrased more clearly, or showing me that I'm wrong, or even engaging with my complaint in good faith, all you are doing is saying "there is nothing wrong here" and trying to move on. This exchange basically boils down to me saying "this bothers me" and you replying with "it shouldn't bother you". Your response tells me that you do not care whether you say something that bothers me and that you do not even try to engage in a conversation about your ways, and I take high issue with that from a teammate.

Third, I've said before that if every other member of the dev team decided to make it preventatively difficult to merge commits I'd continue to merge commits anyway, and I still stand by that. My fundamental goal in this project is to do what's best for manim, and convincing people comes downstream from that.

But this, more than anything, is what I disagree with the most. Here you are telling us two things. First, that you believe it is good form (hygiene?) to decide what changes to make, and to merge your changes in spite of what "every other member of the dev team" may think. Second, implied by the first, that you can single-handedly decide what's best for manim on your own. I wholeheartedly reject both notions.

But also, you say that convincing other people comes downstream. Downstream of what exactly may I ask? When in your workflow does it matter to work and communicate with your teammates? How long after you've commited your changes do we all have to wait for your explanation of YOUR wishes about OUR library?

Your stance here just tells me that we have fundamental differences about what it means to work together as a team on the same FOSS project, and I believe we have (finally) reached a place where we have to solve these differences before moving forward with the project. I am going to tag the team bc I need everybody's opinion on this point @ManimCommunity/core

The third sentence also rubs me the wrong way...

First, the argument is basically that failure to implement OpenGL rendering at the same time that Grant is pushing to make Manim more of a community tool constitutes an existential threat to ManimCE. I can elaborate more if you want me to.

The existence of 3b1b/manim has always been an existential threat to manim ce and I don't see why OpenGL changes or accelerates that. We got quite a bit of momentum while manim ce had no trace of OpenGL and 3b1b did. If all of this is coming from a place of existential angst, then perhaps we could have saved a lot of time by communicating what you intended to do before doing it.

Second, if this rubs you the wrong way then what @naveen521kk said prior should do the same:

Well in that case, according to you, all the glsl stuff you added in #1075 and the WebGL(javascript) stuff are of poor code hygiene.

what if you aren't there to maintain it? That is the case you are talking about now.

If someone else speaks to me with a harsh tone I'll generally take that as license to respond in kind. In this particular case the tone of my response is more mild than the tone I was responding to.

I do not sense a trace of harshness in that quote by @naveen521kk. However I am willing to be shown otherwise, as I admit that text communications over the internet are difficult.

On the point of the tone being too harsh, I don't think this level of tone moderation is sustainable.

Either we work civilly as a team, or we do not have a team. Working in teams requires moderation. If we cannot sustain the amount of moderation required, we cannot work as a team. What are you going to do in the future to work better as a team?

EDIT: I will be AFK for at least the next 8 hours.

[behackl]

One thing I would like to add regarding the discussion on tone: everyone please keep in mind that many people here don't speak English as a first language. Not everyone has the same feeling for English as native speakers have, and choosing words in a way such that an unintentional tone is transported can happen rather easily.

[PhilippImhof]

Your stance here just tells me that we have fundamental differences about what it means to work together as a team on the same FOSS project, and I believe we have (finally) reached a place where we have to solve these differences before moving forward with the project. I am going to tag the team bc I need everybody's opinion on this point

I could not agree more, be it with the interpretation of what has been said or with the conclusion. We must find a way to take important decisions as a community. If we cannot manage to decide on our community project as a community, we … probably are not a community.

[jsonvillanueva]

We've gone too long without a community dev meeting and we should really schedule them regularly a few days before the releases anyways just to ensure things are going well. Even if only a few people can show up, it'd be helpful to have talking points to refer to (like the one @kilacoda posted, or @PhilippImhof in Discord). Given the current circumstance/perceived heat from this issue, I move we meet this weekend, but I think we should regularly default to meeting the weekend before the next scheduled release. I'll link it in Discord as well.

It's important to keep in mind long term goals for Manim v1.0.0 and to some degree, I agree with the differing visions -- having of course my own vision -- of what a stable API in ManimCE looks like. A large number of things in Manim could be plugins (i.e. WebGL/Jupyter/ManimPango/OpenGL), but whether they should be is a team decision and actually doing the work to make the plugin (i.e. the real questions of WHO will do it by WHEN and WHY need to be considered in that decision) is time from the team spent refactoring/documenting/peer reviewing code without adding new useful functionality/features other than extra installation steps for the end-user.

I feel voice discussions with someone taking the minutes/writing notes would be quicker and hopefully save us any issues with perceived tone (I imagine we're all trying to behave well). We are a team with limited time so the more we can align our visions, cooperate, and ultimately get along, the quicker we can release OUR stable community edition.

[Aathish04]

From a third person perspective, based on the following assumptions:

1. Manim will move entirely from Cairo Based rendering to OpenGL rendering as a default, because of the advantages provided by OpenGL.
2. One will be able to switch between renderers via installing plugins and importing from them.
3. Usage of Non-LaTeX based Text rendering is important in Manim and not something which "isn't necessary for manim's use"

My views are as follows:

On Whether ManimPango should be a Plugin.

Cairo-manim relies on ManimPango to write text that is not LaTeX based. This is beneficial to the library and massively simplifies getting non-English text to be displayed without finagling about with LaTeX. Some people may find working with LaTeX easy, and yes, the target audience of Manim will probably have experience with LaTeX, but the ease with which one can use Text makes me feel that it's worth keeping ManimPango in the core library as long as we are still in the liminal stages of moving from Cairo to OpenGL.

We are moving to OpenGL anyway. I recall some discussion on Discord about having a Modular Renderer. I haven't been active enough in the community (exams and school, sorry!) to check if this has already been done, but if the rendering logic has completely been separated from the backend (cairo/opengl) itself, it should be easy to make plugins that change the renderer as the end user would require, that keep the entire communication that's done between the backend and manim in the plugin. Once OpenGL becomes the default backend, we can strip Cairo completely from ManimCE and package all of it into a plugin, and call it something like "manim-cairo-rend", "manim-cairo-rend" will have those of Manim's current dependencies that exist only to facilitate use of Cairo and PangoCairo, such as ManimPango. We can then get rid of ManimPango as a dependency for core manim.

Basically, I say we should keep the status quo for as long as it takes for OpenGL to become the default, all the while making sure that we can move everything Cairo related into a plugin, which itself will have dependencies such as ManimPango.Once OpenGL is reasonably stable and we can completely switch to it as the default, we can move everything cairo over to a plugin.

On Tone and Comms over the Net.

Disagreements happen. I'm pretty liberal on my views with this, but I personally am fine with sarcasm etc. However, for the sake of clear communication, I say we should be as explicit as possible and refrain from implying things without actually stating them. Statements like "I'm sure you know why that'd be a bad decision." come off kind kind of condescending, though I'm sure that wasn't the commenter's intent. Explicit communication at all times. It doesn't matter if you're repeating yourself several times over, just say what you want explicitly.

On the other hand, statements like this,this and this, on discord that, (to me) sound like they essentially boil down into ultimatums are completely unacceptable.

[PhilippImhof]

Once OpenGL becomes the default backend, we can strip Cairo completely from ManimCE and package all of it into a plugin, and call it something like "manim-cairo-rend", "manim-cairo-rend" will have those of Manim's current dependencies that exist only to facilitate use of Cairo and PangoCairo, such as ManimPango. We can then get rid of ManimPango as a dependency for core manim.

As I understand it, text rendering in OpenGL is possible through PyOpenGL. The text will be rendered as a bitmap instead of a vector format. (Which is not a big deal, because the video is a bunch of pixels anyway.)

However I am not sure whether it is actually necessary to do text rendering in OpenGL. In order to keep LaTeX based text, we will need a way to import from SVG (or similar) and we probably want to keep the ability to import vector graphics anyway. In that case, I do not know what we have to gain from rendering the text in OpenGL as opposed to Pango which creates an SVG. Basically, I just see the advantage of having fewer dependencies. Speed maybe? But again, I am by no means an OpenGL expert.

In any case, we would still need another way of rendering text for people using the current (by then probably: legacy) backend, no? So we would have to maintain two ways of rendering text, OpenGL in the core and Pango as a plugin?

[kilacoda-old]

text rendering in OpenGL is possible through PyOpenGL

I think we're using ModernGL though, which while compatible with PyOpenGL, might complicate things, although I can't say for sure.

[PhilippImhof]

My bad, I did not know what package we were using. AFAICS at the first glance, ModernGL does not support text rendering: https://github.com/moderngl/moderngl-window/issues/25

That might complicate things, but as I said -- from my naive perspective as a non-expert -- that's not a big thing, as we can just import MarkupText and the like in the same way as we do for LaTeX. There will definitely be no LaTeX support in OpenGL ;-)

[kilacoda-old]

Maybe @einarf could help us out and provide some clarity on this matter.

[einarf]

Cross platform text rendering is mostly done through freetype-py. It mainly relies on building an atlas or texture array of glyphs. This is simple enough for latin1 text, but will add challenges for other character sets. Pango is using harfbuzz (https://github.com/harfbuzz/harfbuzz) to get the text shaping right. (Probably also LaTex)

You get a lot of free stuff using a text shaping library. It's a very complicated affair. Also, if you want bitmapped fonts to look crisp in any size you might need to delve into distance fields. Text shaping libraries renders the text to the specified size every time to make it perfect. I don't even want to imagine how much work is involved in all this. I'd rather use a text shaping library 😅

When people mention PyOpenGL and text rendering they often refer to GLUT text rendering. That was deprecated more than a decade ago and is not sutiable to render text today.

Also: Making text redering pluggable is a good idea.

[naveen521kk]

This discussion was so hot :fire: when I was busy for the whole day, sorry for this late reply

To explain all this, OpenGL by itself doesn't have or is a text rendering engine (as explained by @einarf, thanks!), and ManimPango is required for OpenGL renderer also. So, this thread isn't about removing ManimPango because we have the OpenGL renderer, but rather this is about the problems that caused the downstream (3b1b version), https://github.com/3b1b/manim/issues/1391 https://github.com/3b1b/manim/issues/1387, and thinking whether that same problem will happen here.

On the other hand, maintaining ManimPango isn't that simple and requires quite some work for my side and as well as from @PhilippImhof (thanks!), and doing all those for being as a plugin, which may not be used by everyone, seems too much to me, and would be hard for me to maintain it.

[Aathish04]

In any case, we would still need another way of rendering text for people using the current (by then probably: legacy) backend, no? So we would have to maintain two ways of rendering text, OpenGL in the core and Pango as a plugin?

You get a lot of free stuff using a text shaping library. It's a very complicated affair. Also, if you want bitmapped fonts to look crisp in any size you might need to delve into distance fields. Text shaping libraries renders the text to the specified size every time to make it perfect. I don't even want to imagine how much work is involved in all this. I'd rather use a text shaping library 😅

To explain all this, OpenGL by itself doesn't have or is a text rendering engine (as explained by @einarf, thanks!), and ManimPango is required for OpenGL renderer also.

I believe that we should attempt to reduce both our dependencies and the amount of things we have to actively maintain. If there's a tried and tested method for Text rendering in OpenGL, (like Pango's python bindings for Cairo (not ManimPango) before they stopped maintaining it) then we should use that alone instead of ManimPango.

This is mainly because I believe this community was made to improve manim; not for building text-layout libraries just because Manim offers the ability to include Text in animations or, for the sake of example, making GUI libraries just because we will build GUIs for Manim in the future. As such, our focus "should" (it's a pretty strong word but I can't think of another one) be on Manim and unless we absolutely have to, not on whatever it may depend upon.

As long as there's no better option for Text rendering in Manim, we can keep ManimPango in the library. If OpenGL Manim makes use of it as well, it must only be because there are no better options available.

@naveen521kk , I read your conversation with @einarf on this ModernGL issue which referenced this issue in ManimPango and your conversation with @PhilippImhof. If you both really do plan on making ManimPango open to more use than than just for Manim, there's an argument to be made that it's not purely for Manim anymore and doesn't need to have Manim in its name/be related to manim at all. Furthermore, if you intend on doing this, I believe a better course of action would simply be for you to take over maintenance of cairocffi entirely from their current maintainers, or alternatively to fork it, make every change that you did to ManimPango on that fork (except the name change), and archive ManimPango because, like I said, it's not purely for Manim anymore and the rest of the ManimCommunity shouldn't be expected to maintain it (not that they currently are maintaining it, but you get my point). The advantages there are: more people already know about cairocffi (so there'll be a sort of demand) and will be more likely to become co-maintainers/contributors, and you won't have to deal with the demands of manim and whether it "needs" a feature or not before you implement it in cairocffi/ManimPango.

Also, @naveen521kk @PhilippImhof I read on cairocffi's github page that they are a drop-in replacement for pycairo. We have pycairo as one of our dependencies, so why do we need ManimPango at all? Can't we just use purely pycairo?

[PhilippImhof]

As long as there's no better option for Text rendering in Manim, we can keep ManimPango in the library. If OpenGL Manim makes use of it as well, it must only be because there are no better options available.

I agree with that. We should use the best option available and although I have put in quite some work, I would not mind dropping something, if (after thorough analysis) we find a better option. It is generally bad advice to keep something just because of the effort that has been put into it. (Reminds me of sunk costs somehow.)

If you both really do plan on making ManimPango open to more use than than just for Manim, there's an argument to be made that it's not purely for Manim anymore and doesn't need to have Manim in its name/be related to manim at all.

Again, I agree. If current ManimPango eventually becomes a "Python library for converting text to SVG", I think it would be sensible to make it a standalone project and maybe even change its name in order to emphasize that it is a general-purpose tool ready to be used in other projects. Although it might be kept for historical reasons, of course. Bear in mind that IMO we are currently far from that point, though.

[naveen521kk]

As long as there's no better option for Text rendering in Manim, we can keep ManimPango in the library. If OpenGL Manim makes use of it as well, it must only be because there are no better options available.

Again, OpenGL has nothing to do with ManimPango or rather Text. https://github.com/ManimCommunity/manim/issues/1102#issuecomment-802198553

If you both really do plan on making ManimPango open to more use than than just for Manim, there's an argument to be made that it's not purely for Manim anymore and doesn't need to have Manim in its name/be related to manim at all.

I agree. But still, there is a long way to go there.

Furthermore, if you intend on doing this, I believe a better course of action would simply be for you to take over maintenance of cairocffi entirely from their current maintainers, or alternatively to fork it, make every change that you did to ManimPango on that fork (except the name change), and archive ManimPango because, like I said, it's not purely for Manim anymore and the rest of the ManimCommunity shouldn't be expected to maintain it (not that they currently are maintaining it, but you get my point).

cairocffi is a replacement for pycairo and isn't binding to Pango. So, cairocffi and ManimPango are entirely different.

Also, @naveen521kk @PhilippImhof I read on cairocffi's github page that they are a drop-in replacement for pycairo. We have pycairo as one of our dependencies, so why do we need ManimPango at all? Can't we just use purely pycairo?

The previous implementation of Text was based on pycairo but later that didn't work out because it is just a toy API and we have to look out for other implementation. We found Pango as in pangocffi but that created a lot of other problems, installation on Windows was broken because of that. That was fixed by ManimPango.

[naveen521kk]

To explain further, first, Pango is part of GNOME libraries and the only python binding they officially offer is pygobject and none of the cffi bindings like cairocffi and pangocffi is maintained by Gnome itself. About using pygobject, it can't be used directly on Windows, and it would be too much for people to install full GTK+ for just rendering a text in Manim, and those were the reasons for me not using it.

Second, about using the cffi bindings, it caused many DLL problems as we previously used that and have a specific section for troubleshooting, https://docs.manim.community/en/v0.1.1/installation/troubleshooting.html#windows-oserror-dlopen-failed-to-load-a-library-pango which many a time doesn't work properly on Windows.

Let me explain what is the difference between all the cffi and ManimPango itself. First, cairocffi and pangocffi use https://cffi.readthedocs.io/en/latest/ which is like ctypes which means it searches for shared objects like .dll in the case of Windows and when it is unable to find things it crashes and that was a reason ManimPango by itself becomes an actual C extension rather than a cffi binding. So, both cairocffi and ManimPango are entirely different.

[Aathish04]

Again, OpenGL has nothing to do with ManimPango or rather Text.

Yes, OpenGL by itself doesn't have a text-rendering engine, but there must be several third-party engines that work with OpenGl that we don't have to maintain. Freetype+Harfbuzz, like @einarf mentioned could be used in place of ManimPango, and that might be beneficial in the long term since they have a much wider developer base! I also found https://github.com/rougier/freetype-gl which at first glance seems like exactly what we are looking for with regards to text rendering on OpenGL manim, albeit it's entirely in C and C++.

cairocffi is a replacement for pycairo and isn't binding to Pango. So, cairocffi and ManimPango are entirely different.

Alright, thanks. That was confusing me for a bit.

[naveen521kk]

Yes, OpenGL by itself doesn't have a text-rendering engine, but there must be several third-party engines that work with OpenGl that we don't have to maintain. Freetype+Harfbuzz, like @einarf mentioned could be used in place of ManimPango, and that might be beneficial in the long term since they have a much wider developer base!

Pango already uses it. It uses Cairo+Harfbuzz to render Text in an SVG file. If you want to use Freetype+Harfbuzz then you would be implementing another version of Pango in python and that would be too much work. Currently what ManimPango does is using the C API which Pango provides, and make it possible to call these from Python using Python-C API.

I also found https://github.com/rougier/freetype-gl which at first glance seems like exactly what we are looking for with regards to text rendering on OpenGL manim, albeit it's entirely in C and C++.

Are you asking to create another C extension? We would anyway have a way to draw SVG files in OpenGL, in that case, it seems too much to use freetype-gl. ManimPango creates SVG files which can be shown on OpenGL.

[Aathish04]

Currently what ManimPango does is using the C API which Pango provides, and make it possible to call these from Python using Python-C API.

Right. If we find another library like Pango, compatible with OpenGL that has a wider user base or is generally "better", then we should look into moving to it, regardless of what ManimPango does.

Are you asking to create another C extension? We would anyway have a way to draw SVG files in OpenGL, in that case, it seems too much to use freetype-gl. ManimPango creates SVG files which can be shown on OpenGL.

Nope. I'm saying that similar to freetype-gl, if there's a better way to render text than using ManimPango, we should consider it. It doesn't have to be freetype-gl or any library I mentioned in particular, which I mentioned for the sake of giving examples.

This goes back to your comment here:

Again, OpenGL has nothing to do with ManimPango or rather Text.

Yes, OpenGL doesn't care about Text rendering engines or bindings that interface with text-rendering engines. My point is that if there is a better, "preferred" way to render text via OpenGL, which is not ManimPango, we should implement that/use libraries that implement that.

[naveen521kk]

Right. If we find another library like Pango, compatible with OpenGL that has a wider user base or is generally "better", then we should look into moving to it, regardless of what ManimPango does.

I don't understand why you are saying ManimPango can't be used with OpenGL. It can be used without any problem, what actually happens is ManimPango created an SVG file with the Text as SVG paths which is later parsed by Manim and displayed on the screen. See 3b1b's repo Text for a working example.

Yes, OpenGL doesn't care about Text rendering engines or bindings that interface with text-rendering engines. My point is that if there is a better, "preferred" way to render text via OpenGL, which is not ManimPango, we should implement that/use libraries that implement that.

I would say once ManimPango has a stable API it can be used with other projects also and could be the preferred way to render text as @einarf already said. Currently, there is freetype-py but it is the same as how CairoText is currently is, no support for RTL texts etc.

[Aathish04]

I don't understand why you are saying ManimPango can't be used with OpenGL

That's not what I said. I said that if there is a better library that we do not have to maintain, then instead of ManimPango, that's the one we should use.

This is because this community was made to improve manim; not for building text-layout libraries just because Manim offers the ability to include Text in animations or, for the sake of example, making GUI libraries just because we will build GUIs for Manim in the future. As such, our focus "should" (it's a pretty strong word but I can't think of another one) be on Manim and unless we absolutely have to, not on whatever it may depend upon.

I would say once ManimPango has a stable API it can be used with other projects also and could be the preferred way to render text as @einarf already said. Currently, there is freetype-py but it is the same as how CairoText is currently is, no support for RTL texts etc.

And in your opinion, how long will it take before ManimPango gets a stable API?

[naveen521kk]

That's not what I said. I said that if there is a better library that we do not have to maintain, then instead of ManimPango, that's the one we should use.

This is because this community was made to improve manim; not for building text-layout libraries just because Manim offers the ability to include Text in animations or, for the sake of example, making GUI libraries just because we will build GUIs for Manim in the future. As such, our focus "should" (it's a pretty strong word but I can't think of another one) be on Manim and unless we absolutely have to, not on whatever it may depend upon.

Again, ManimPango isn't a text-layout library, it is just a binding to Pango. I have done that search long back before implementing ManimPango, and I couldn't find anything in python, which can handle RTL texts. One thing, I found was libraqm but that is again, not for python, and has fewer features than Pango, as in you would have to pass the font file each time you render something as is impossible to render into an SVG directly. Again, that would mean a C binding.

And in your opinion, how long will it take before ManimPango gets a stable API?

That needs a lot of work and maybe should take around a month.

[Aathish04]

That needs a lot of work and maybe should take around a month.

Awesome. Given this info, I'm in agreement with what @behackl said over on discord.

Once ManimPango stabilises and allows use for other purposes, let's rename it to something more generic (maybe pypango or MPango, to acknowledge that it was related to manim?) and Pango related instead of putting the emphasis on Manim.

We can keep ManimPango (or whatever it's called after its name changes) as a dependency if required.

[einarf]

Once ManimPango stabilises and allows use for other purposes, let's rename it to something more generic (maybe pypango or MPango, to acknowledge that it was related to manim?) and Pango related instead of putting the emphasis on Manim.

We can keep ManimPango (or whatever it's called after its name changes) as a dependency if required.

From an "outside" perspective:

Doesn't it make more sense to keep ManimPago as a plugin respositry that depends on a pypango package containing the core functionality (eventually...)? Come up with a standard api the text layout plugins needs to follow? I'm guessing the ManimPango repository is more like an evolving experiment that could turn into something great?

People are free to make other plugins following the standard api. They could even be selected based on platform if needed. What text layout plugin should be default can be based on the typical criterias:

• Stability
• Ease of installation for end users <- Often highly underestimated!
• Performance
• Platforms

Pick whatever is reasonable based on this. Ease of installation in development is secondary to easy of installation for the end users. The former can be solved by having a dev setup guide.

Also: Creating a library using freetype-py and harfbuzz I suspect is expontentially more work than just relying on a true and tried text layout library.

[Aathish04]

Doesn't it make more sense to keep ManimPago as a plugin respositry that depends on a pypango package containing the core functionality (eventually...)? Come up with a standard api the text layout plugins needs to follow? I'm guessing the ManimPango repository is more like an evolving experiment that could turn into something great?

The reason a fair few people in the Dev team think keeping ManimPango as a core dependency is worthwhile was discussed in the first few comments on this issue. The most important points were:

Manim should offer at least one way of integrating text without the need of a LaTeX installation. And this functionality should be included in Manim's core. For as much as I love LaTeX, we have to admit that it is "big" and that e.g. installing und using custom fonts with LaTeX is not easy for everyone. -> @PhilippImhof

LaTeX is not fit for every use case, such as right-to-left text, using system fonts etc. For such situations, Text (and its derivatives, such as MarkupText) are valuable alternative solutions, and hence it would be a bad idea to remove them from core manim. -> @kilacoda via his summary of that conversation between @eulertour and @naveen521kk.

Having something like Text work out of the box without dealing with LaTeX is what most of the people in this conversation want. Getting rid of it in a release would seem almost unnecessary.

Though now that I think of it, having a standard api for text layout plugins so that anyone can write their own ones does sound enticing. Maybe we could have a "default" one as well, to make sure Text works OOTB if we go the plugin approach?

[naveen521kk]

Doesn't it make more sense to keep ManimPago as a plugin respositry that depends on a pypango package containing the core functionality (eventually...)? Come up with a standard api the text layout plugins needs to follow?

Essentially there isn't a pypango package. ManimPango is a C extension that interacts with Pango C API. Also, we don't have a standard API for text layout plugins to follow. All we have for plugins is https://docs.manim.community/en/v0.4.0/installation/plugins.html where manim will automatically import a plugin if it is defined in a config file. The idea of coming up with a standard API for Text seems to be a nice idea. Essentially, the class need to inherit from SVGMobject and then, have a function text2svg, that's all it needs to.

I'm guessing the ManimPango repository is more like an evolving experiment that could turn into something great?

Yup! It all started 3 months ago when I was searching for a better text rendering system and found Pango, and now it is as good as works on every system and can be easily installed with pip.

Pick whatever is reasonable based on this. Ease of installation in development is secondary to easy of installation for the end users. The former can be solved by having a dev setup guide.

Currently, I would say there are three implementations of text-rendering where two are needed for the core library.

• Tex, LaTeX
• Text <- where ManimPango is used
• CairoText, the previous implementation of Text using plain Cairo.

Out of these, there should be Tex and Text while the other isn't required. Now, this issue is about having only Tex and removing everything else from the Core library and making it a plugin.

We would possibly decide in a call on Discord soon :tm:(possibly this week?) about this issue. If you want you can join us on discord @einarf, most probably we will do an announcement before we do the call.