AsciiMath support

[GrimPixel]

I would like to add the AsciiMath formula and display it on the node.

[KennedyRichard]

Hello, Mr. GrimPixel,

Thankfully, that is already feasible with the new features to be released in the new version (edit: this version is available already, it was released 02 weeks after this reply was posted). You can render the formula using your own custom nodes (with the help of third-party libraries, for instance) and use default nodes provided by Nodezator (in the version to be released) to display the data in the graph.

By the way, I'm not delaying the release, it is just that I cannot predict the number of tasks because, as I finish the changes, I often identify improvement opportunities, sometimes find bugs and have to test everything that is added/fixed. It is all for the sake of delivering a more complete end product for the users, so it is worth the wait.

Getting back to the topic, in summary, since the next version will allow users to display both text and pygame-ce surfaces in the graph beside the nodes, all users have to do to visualize a rendered AsciiMath formula, for instance, is to convert the rendered formula to a surface. Of course, parsing and rendering the formula is a separate problem and the users have to either write the code to do so or use third-party libraries to do the rendering. However, since Python is pretty popular, there is usually code already written for this kind of thing.

Fortunately, since I've been working on converting data into pygame surfaces since a long time, and more recently have been working on implementing some nodes that help the user do that for this next Nodezator version, I made a quick research regarding this request of yours in specific and found out that there is a more or less straightforward way to do that.

If you install the Python libraries py_asciimath and sympy (I just pip installed them), you can use py_asciimath to convert your ASCIIMath formula into Latex and feed the Latex code to sympy which can convert it into png data which can then be converted into a pygame-ce surface. You can also use additional Latex commands to control render settings like the font size.

I even managed to put together a quick and dirty first working prototype yesterday. It has a lot of nodes, but the vast majority are very tiny atomic operations or quick hacks. The entire graph can be easily encapsulated into 02 to 03 custom nodes. You can see this first rough prototype in this video:

ascii_experiment.mp4

For the rendering performed by sympy to work though you need to install Latex in your system, since it uses the latex command internally to do the rendering. This may be a very large download, since the Latex ecosystem has a lot of libraries/utilities/fonts/etc. The download was 3GB in my GNU/Linux system (I use the Xubuntu distro). Naturally, there are Windows/Mac versions, too.

I'll refactor the code into a couple of custom nodes and give them to you, but for now I'd like to keep focusing on finishing my work on the next version. So, please, wait a bit more.

In the meantime, let me know if you need anything else, and of course, feel free to keep the questions/feedback/requests coming. I'll answer each of them as soon as healthily possible.

Peace.

[GrimPixel]

Thank you for your always detailed reply. It explained everything well. Great quality comes from human's inside.
I am planning on creating my own nodepack “Equationary”, covering all formulae from primary school to college. Before starting, I think it is better to learn about your thoughts on the structure of a nodepack in regard to #61 #62 and maybe #60, so unnecessary reworks can be avoided.
There is no need to hurry for me. I have other works to do before starting the nodepack creation.

So far, the ideal solution in my opinion is

directory:

Equationary
└─ algebra
  └─ coefficient_1__coefficient_2__coefficient_3__quadratic_roots.py
└─ geometry
  └─ circle
    ├─ area__radius.py
    ├─ area__diameter.py
    └─ area__circumference.py

file area__radius.py:

def _(A:float, r:float):
    if A is None and None not in [r]:
        return π * r ** 2
    if r is None and None not in [A]:
        return sqrt( A / π )

[KennedyRichard]

Hello, Mr. GrimPixel,

I just answered the discussions you listed in the reply above (60 to 62). Considering my answers to them and what you wrote above, I'd recommend that, once you finish your tasks and have time, you create your node pack right away without fearing any possible reworks, because they will very likely be minimal.

Although I plan to enable the possibility of placing node scripts directly into the category folders, it will be sometime until I do that, because I have other higher priority tasks to tackle in the project, including the revision of a PR related to node packs as well.

However, by then, the only change you'll have to do is to move the node scripts out of the node script folders like this:

# how your node pack will be now
Equationary
└─ circle
   ├─ area__radius
   |  └─ __main__.py
   ├─ area__diameter
   |  └─ __main__.py
   └─ area__circumference
      └─ __main__.py
└─ ...

# how it will be after
Equationary
└─ circle
   ├─ area__radius.py
   ├─ area__diameter.py
   └─ area__circumference.py
└─ ...

In other words, you'll just be moving up the scripts in lieu of the folders they contain.

Also, I don't intend to allow nested categories like you've shown in your ideal solution (circle subcategory within the geometry category):

Equationary
└─ algebra
  └─ coefficient_1__coefficient_2__coefficient_3__quadratic_roots.py
└─ geometry
  └─ circle
    ├─ area__radius.py
    ...

It is not a bad idea but it has a lot of implications for the design that would need to be addressed. For instance, node scripts are treated as completely independent packages, which means they may contain additional Python modules that can be used by __main__.py. For instance, this is completely possible to do right now:

# a node pack structure:
a_node_pack
└─ a_category
  └─ a_node_script
     └─ __main__.py
     └─ a_module.py

# contents of __main__.py:

from .a_module import utility_function

def my_node_callable(a, b):
    c = a * b
    return utility_function(c)

main_callable = my_node_callable

# contents of a_module.py

def utility_function(...):
    ... # logic here

In other words, your node script folder can grow as much as you'd like and have a complex structure.

If I were to allow nested categories though, I'd have to come up with a way to differentiate common modules from node scripts which would require code parsing which is in and of itself very troublesome and prone to error. That's the gist of it, but I can explain further if you wish.

If you have the need for subcategories, maybe it would be better to create multiple node packs. For instance: equationary_geometry, equationary_algebra, etc.

Changing the subject, I intend to post the ASCIIMath related nodes I mentioned to you in my previous reply very soon, maybe even today. It will probably take only a few minutes to put everything together.

As always, I'm here to answer all your questions and address all your concerns. Let me know if I forgot to address anything and if you still have questions/suggestions or if you disagree with anything. Thank you again for your continued feedback.

Peace.

[GrimPixel]

Thank you for your efforts. I have the clues and can start it now.
In one of my related repositories, the subcategory has reached 8 levels for clarity. It is acceptable to place them in one level of subcategory, as they can be moved later without problem when subcategories are supported.

I imagined even farther: when the Equationary formula get loaded, the AsciiMath content gets loaded side by side.

[KennedyRichard]

No problem, I'm here to help. Just to clarify, though, there isn't plans to support subcategories in Nodezator, I think my reply explains this in detail.

This might change in the future though, since it is something to which I didn't give enough thought. But, for now, I'd say it is unlikely. It is better to move forward with the assumption that subcategories won't be implemented in Nodezator. Although it isn't set in stone. It is just that, as I explained, subcategories would be more trouble that what it is worthy. Rather, it is best to postpone any thoughts about them altogether, specially since Nodezator lacks a lot of more urgent features like group nodes.

[KennedyRichard]

Hello, Mr. GrimPixel,

Here are the nodes I created:

Don't forget that for them to work you must have latex installed in your system, as well as the py_asciimath and sympy libraries (just check my first reply in this discussion for extra instructions).

As the names imply, you can just feed your ASCIIMath code into asciimath2latex and then feed the resulting latex code to the latex2surface node. You can use some nodes available by default in Nodezator to visualize/save the surface.

To visualize the surface, use the view_surface node (popup menu > general viewer nodes > view_surface), but I recommend to use the increase_surf_border node first (popup menu > pygame-ce > Encapsulations > increase_surf_border), with the color set to white. This way the final surface will have a bit of padding, as demonstrated in the video below:

asciimath_nodes_demo_final.mp4

(I'll publish this demo on social media and other channels of the Indie Python project as well)

Whenever users want to save the surface as an image file, they just have to feed the surface into the save_surf_to_file node (popup menu > pygame-ce > pygame.image > save_surf_to_file).

Here are the node scripts (you or anyone can use this code as you see fit, I won't license it since it is just calls to external libraries and even if it had any code I created myself I would put it in the public domain just like Nodezator and any code from the Indie Python project, so really, just do what you want with it):

For asciimath2latex:

### third-party import
from py_asciimath.translator.translator import ASCIIMath2Tex



## translator callable
latex_from_asciimath = ASCIIMath2Tex(log=False, inplace=True).translate


## main callable

def asciimath2latex(asciimath_code:str='') -> [
    {'name': 'latex_code', 'type': str}
]:
    return latex_from_asciimath(
        asciimath_code,
        displaystyle=True,
        from_file=False,
        pprint=False,
    )


main_callable = asciimath2latex

For latex2surface:

### standard library import
from io import BytesIO


### third-party imports

## pygame-ce

from pygame import Surface

from pygame.image import load as load_image


## sympy
from sympy import preview



def latex2surface(
    latex_code: str = '',
    font_size_prefix : {
        'widget_name': 'option_menu',
        'widget_kwargs': {
            'options': [
                'none',
                r'\tiny',
                r'\scriptsize',
                r'\footnotesize',
                r'\small',
                r'\normalsize',
                r'\large',
                r'\Large',
                r'\LARGE',
                r'\huge',
                r'\Huge',
            ],
        },
        'type': str,
    } = r'\Large',
) -> [
    {'name': 'surface', 'type': Surface}
]:

    ### add font size prefix if requested

    if font_size_prefix != 'none':
        latex_code = font_size_prefix + latex_code

    ### create bytes stream and populate it with bytes
    ### representing rendered PNG file

    bytes_io = BytesIO()

    preview(
        latex_code,
        output='png',
        viewer='BytesIO',
        outputbuffer=bytes_io,
    )

    ### change the stream position to start of stream
    ### (this way the bytes can be read properly)
    bytes_io.seek(0)

    ### convert bytes stream (a file-like object), into
    ### a surface
    surface = load_image(bytes_io, 'file.png')

    ### close the bytes stream, since we won't need it anymore
    bytes_io.close()

    ### finally return the surface
    return surface


main_callable = latex2surface

As always, let me know if you need anything else.

Peace.

[GrimPixel]

This is wonderful. I'll try it out soon.