ManimPango should be a plugin #1102
Comments
Can you elaborate?
@PhilippImhof also has knowledge about that
What were the problems you faced in #1075?
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.
Are you thinking of depreciating 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
In that case, what do you think should be part of the core library? |
|
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. |
|
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). |
|
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. |
|
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
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. |
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.
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.
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. |
I can only come for a call next week.
PhilippImhof was the author of Also, I was the one to write all the packaging scripts, which anyone can read and understand easily.
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!). |
These are maintained by their own teams and presumably have several people supporting them. The same isn't true of ManimPango.
This is subjective, you could just as well say the entire library can be read and understood easily.
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. |
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 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. |
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. |
I've seen various projects on computer science-y stuff like algorithm visualization which often make use of |
|
virtually everything* |
Anyone with some amount of knowledge on building C stuff can understand that.
Well in that case, according to you, all the 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. |
|
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 |
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. |
|
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. |
What do you mean by a "stable" API? I didn't know there was anything unstable about the API right now.
This just isn't true.
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. |
I haven't heard of any problems that haven't been fixed. |
|
I don't want or not have any interest in taking this discussion further. |
|
I have not read the entire thing, but I do want to highlight this fact:
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? |
|
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. |
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.
I agree with this.
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:
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. |
To be crystal clear:
On the point of the tone being too harsh, I don't think this level of tone moderation is sustainable. |
|
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
naveen521kk and PhilippImhof's Rebuttals:ManimPango and
|
|
Thank you for summarizing, @kilacoda!
Given that |
As @friedkeenan said, I simply don't see the evidence for this.
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.
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 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.
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.
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. |
|
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. |
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. |
|
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. |
|
From a third person perspective, based on the following assumptions:
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. 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. 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. |
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? |
I think we're using ModernGL though, which while compatible with PyOpenGL, might complicate things, although I can't say for sure. |
|
My bad, I did not know what package we were using. AFAICS at the first glance, ModernGL does not support text rendering: moderngl/moderngl-window#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 |
|
Maybe @einarf could help us out and provide some clarity on this matter. |
|
Cross platform text rendering is mostly done through 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. |
|
This discussion was so hot 🔥 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), 3b1b/manim#1391 3b1b/manim#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. |
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 |
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.)
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. |
Again, OpenGL has nothing to do with ManimPango or rather
I agree. But still, there is a long way to go there.
The previous implementation of |
|
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 |
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!
Alright, thanks. That was confusing me for a bit. |
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.
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 |
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.
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:
Yes, OpenGL doesn't care about Text rendering engines or bindings that interface with text-rendering engines. |
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
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 |
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.
And in your opinion, how long will it take before ManimPango gets a stable API? |
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.
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. |
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:
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. |
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 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 |
Essentially there isn't a
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.
Currently, I would say there are three implementations of text-rendering where two are needed for the core library.
Out of these, there should be We would possibly decide in a call on Discord soon ™️(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. |
|
This issue was discussed in yesterday's meeting and agreed that for now, ManimPango will stay until the plugin system is made better than how it is currently and one day eventually every other Mobject will be as a plugin and the core contain only the basic Mobject and the Renderer, Camera, Scene setup. |
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.
The text was updated successfully, but these errors were encountered: