@aminya
I'm not sure we have to go this way, because this 8G value would apply to ALL users.

Several questions:

• What if a user's machine does not offer 8GB? I'm afraid the program will not run.
• If we do not explicitly set a maximum value, what the user will get? Perhaps a percentage of the maximum memory. I don't know.
• Is there a way for the end user to override the -Xmx option? Perhaps via the environment variable JAVA_TOOL_OPTIONS. Could you try on your side, by setting this variable to "-Xmx8G" and observe the behavior?

I think the last option would be the best solution. If it works...

@aminya
I'm not sure we have to go this way, because this 8G value would apply to ALL users.

Several questions:

• What if a user's machine does not offer 8GB? I'm afraid the program will not run.
• If we do not explicitly set a maximum value, what the user will get? Perhaps a percentage of the maximum memory. I don't know.
• Is there a way for the end user to override the -Xmx option? Perhaps via the environment variable JAVA_TOOL_OPTIONS. Could you try on your side, by setting this variable to "-Xmx8G" and observe the behavior?

I think the last option would be the best solution. If it works...

I've noticed that the app tends to freeze when attempting to convert books longer than 30 pages. I can provide a demonstration if needed.

In general, modern 64-bit applications are designed to utilize memory efficiently, and it's the operating system's responsibility to manage that memory rather than the application itself. If we need to establish a limit, it would be wise to align it with the standards set by the OS based on the hardware capabilities.

While introducing an environment variable could be beneficial, it appears to be an uncommon practice among applications. Typically, manual memory capping is only necessary in specific web server scenarios.

I believe that the current default memory setting is rather conservative, which may hinder performance for the majority of users who have significantly more RAM. Older computers can still utilize previous versions of the software if necessary.

In general, modern 64-bit applications are designed to utilize memory efficiently, and it's the operating system's responsibility to manage that memory rather than the application itself. If we need to establish a limit, it would be wise to align it with the standards set by the OS based on the hardware capabilities.

So, in practice, how should we configure the installer? We could try to simply remove the upper limit, and let the OS/JVM do their best...
If you wish, I can draft a release without that upper limit, so that you can try it and see how it behaves. OK for trying this?

@aminya

I just made a simple test this morning, setting the upper limit to 20G (a memory amount I don't have on my PC, limited to ca. 8G).
The application seems to run OK.

I didn't try to really use a huge amount of memory, though.
I guess that if I try to indeed process an enormous score interactively, something will turn wrong at some point in the transcription.

Therefore, your PR (setting Xmx8G) is OK for me.

This being said, why not going further by setting it to Xmx20G, as I tried?
Or, just removing any upper limit?
What do you think?

I manually reported your modification (-Xmx8G) in the packaging/build.gradle file
on the "development" branch (we never work on the "master" branch directly).
See 24c389f

Closing the PR.

Thank you for merging. Cherry picking works