Redmine

Definitely +1 if it takes less memory :)

But I also wanted to take a look into doing all the image processing and saving stuff on the front end instead. Now that you can create canvas objects with 2d and webgl contexts as variables of javascript, it makes all these image generation and manipulations super easy even on the front end and thus there is little to no reason to bother a server with image processing. These tools already integrated in browsers (even IE11), require no libraries at all and definitely should be used. Imho server should just supply the required links to resources, JS should pick it up to process and store the processed into cache to request next time from the cache instead of resizing all the time (for best optimization).

And that would also be -1 back-end dependency.

Max Johansson wrote:

But I also wanted to take a look into doing all the image processing and saving stuff on the front end instead. Now that you can create canvas objects with 2d and webgl contexts as variables of javascript, it makes all these image generation and manipulations super easy even on the front end and thus there is little to no reason to bother a server with image processing. These tools already integrated in browsers (even IE11), require no libraries at all and definitely should be used. Imho server should just supply the required links to resources, JS should pick it up to process and store the processed into cache to request next time from the cache instead of resizing all the time (for best optimization).

Do you mean that the patch should not be committed and we should wait for someone to submit a JavaScript-based patch?

Generating gantt PNG images with JavaScript is a nice option but I think it is better to go with mini_magic for now because no one is currently working on JavaScirpt-based gantt export. This mini-magick-based patch can be delivered in 4.1.0, but no one knows when a JavaScript-based patch will be submitted. Of course, it is really nice if someone submits a JavaScript-based patch in the future.

I also agree to commit this patch as we don't have a working JS alternative by now and it will definitely take it's time to develop and test it. In the meantime it's a nice improvement.
+1

Go, Bernhard, should we run some tests with both libraries (with new version of rmagick)? Also, I'm observing that rmagick is going to release a new version soon with a lot of refactoring and has new maintainers.

According to Travis, minimagick doesn't run the tests on ruby 2.6, should we create a PR before changing to it?

Go, sorry, I meant, I totally agree with committing the change to mini magic for now as current solution, I just wanted to also inform that this could definitely be improved even more in the future by trying out JS. I have other things at the moment, but surely, I'll take a look at it in the future. :)

RMagick 3.0.0 has released on 2019-02-16 but it does not support ImageMagick 7.0 yet. In addition, it narrowed the supported version. The minimum supported version of ImageMagick has raised from 6.4.9 to 6.8.9.

Marius BALTEANU wrote:

According to Travis, minimagick doesn't run the tests on ruby 2.6, should we create a PR before changing to it?

I have just sent a pull request.
https://github.com/minimagick/minimagick/pull/475

RMagick 3.0.0 has released on 2019-02-16 but it does not support ImageMagick 7.0 yet. In addition, it narrowed the supported version. The minimum supported version of ImageMagick has raised from 6.4.9 to 6.8.9.

I don't oppose replacing rmagick with minimagick.
But It seems that this isn't quite persuasive enough.

As described in the comment, ImageMagick 6.8.9 was released at nearly 4 years ago.
https://github.com/rmagick/rmagick/issues/392#issuecomment-466100509

And Redmine 3.4.0 released 2 years ago.
Do you think Redmine has to work with ImageMagick 6.8.8 or former?

Goh Matsumoto wrote:

Do you think Redmine has to work with ImageMagick 6.8.8 or former?

Yes, I think so because some major Linux distributions still bundle older ImageMagick. For example, CentOS 7.6 and Amazon Linux AMI 2018.03 bundles ImageMagick 6.7.8.9.

You cannot install Redmine on such distributions without a trick like "bundle install --without rmagick". But I think it is difficult for admins who are not familiar with Ruby to find the solution. The installation process should be as simple as possible.

Rails 6 is deprecating the MiniMagick backend and replacing the library with ImageProcessing gem. More details can be found in the Changelog.

Marius BALTEANU wrote:

Rails 6 is deprecating the MiniMagick backend and replacing the library with ImageProcessing gem. More details can be found in the Changelog.

I didn't know that. Thanks.

Although Rails 6 does not directly depend on mini_magick, image_processing gem seems to require mini_magick. Please see: https://rubygems.org/gems/image_processing/versions/1.8.0

Maybe the change in Rails adds image_processing as a wrapper for libvips or mini_magick.

Goh Matsumoto wrote:

I don't oppose replacing rmagick with minimagick.
But It seems that this isn't quite persuasive enough.

Some distributions, like openSUSE Leap 15.0, does not ship ImageMagick 6 anymore. Currently, there is no official way to install ImageMagick 6 on Leap 15.0, 15.1, and Tumbleweed. Hence, it is not possible to install Redmine with `rmagick` since it won't build against ImageMagick 7.

EDIT: By the way, this patch is working perfectly and, even installing ImageMagick6 in openSUSE (latest version), I am getting and error when exporting Gantt to PNG.

Go MAEDA wrote:

Goh Matsumoto wrote:

Do you think Redmine has to work with ImageMagick 6.8.8 or former?

Yes, I think so because some major Linux distributions still bundle older ImageMagick. For example, CentOS 7.6 and Amazon Linux AMI 2018.03 bundles ImageMagick 6.7.8.9.

You cannot install Redmine on such distributions without a trick like "bundle install --without rmagick". But I think it is difficult for admins who are not familiar with Ruby to find the solution. The installation process should be as simple as possible.

rmagick 3.1.0 seems to extend the range of support for ImageMagick.

ImageMagick 6.7.7 or later

Redmine's PDF output feature uses the rbpdf library, now.
The image processing of the rbpdf library has parts depending on RMagick.
If Redmine migrates to minimagick, (and in environments where RMagick is not installed), PDF will not display images other than 8bit PNG (GIF, JPEG, non 8bit PNG).

Jun NAITOH wrote:

Redmine's PDF output feature uses the rbpdf library, now.
The image processing of the rbpdf library has parts depending on RMagick.
If Redmine migrates to minimagick, (and in environments where RMagick is not installed), PDF will not display images other than 8bit PNG (GIF, JPEG, non 8bit PNG).

Thank you for pointing it out. I didn't know that the PDF export feature depends on RMagick.

I have changed my mind by knowing that. We had better not to commit the patch for now because replacing RMagick with MiniMagick because may break the PDF export feature.

Ronan Chagas wrote:

Goh Matsumoto wrote:
EDIT: By the way, this patch is working perfectly and, even installing ImageMagick6 in openSUSE (latest version), I am getting and error when exporting Gantt to PNG.

I just got rmagick 2.16.0 with ImageMagic 6.8.8.1 running on OpenSUSE Leap 15.1 by installing these packets (most of theme from the Leap 42.3 repository):
ImageMagick-6.8.8.1-82.1.x86_64.rpm
ImageMagick-config-6-SUSE-6.8.8.1-82.1.x86_64.rpm
ImageMagick-devel-6.8.8.1-82.1.x86_64.rpm
libIlmImf-Imf_2_1-21-2.1.0-10.3.1.x86_64.rpm
libMagick++-6_Q16-3-6.8.8.1-82.1.x86_64.rpm
libMagickCore-6_Q16-1-6.8.8.1-82.1.x86_64.rpm
libMagick++-devel-6.8.8.1-82.1.x86_64.rpm
libMagickWand-6_Q16-1-6.8.8.1-82.1.x86_64.rpm
libwebp5-0.4.3-9.3.x86_64.rpm

The Gantt PNG export works now.

Go MAEDA wrote:

Thank you for pointing it out. I didn't know that the PDF export feature depends on RMagick.

I have changed my mind by knowing that. We had better not to commit the patch for now because replacing RMagick with MiniMagick because may break the PDF export feature.

• Compatible with RMagick 4.0.
• Added MiniMagick support. (MiniMagick can be used as an alternative to RMagick.)

If one could update the wiki regarding installation and upgrade, please. Are the devel packages of Image/GraphicsMagick required? Is there anything special to keep in mind on upgrade? I do not know enough about Ruby stuff.

Robert Schneider wrote:

If one could update the wiki regarding installation and upgrade, please. Are the devel packages of Image/GraphicsMagick required? Is there anything special to keep in mind on upgrade? I do not know enough about Ruby stuff.

This was confusing to me as well. Reading the official install/upgrade docs, it appears those packages are required, but looking at the discussion here I get the impression that they're not.