I'm trying to use Emacs to visualise very large UML diagrams created by PlantUML [1]. In PNG form these diagrams have over 20000x1300 - in fact, the reason why I moved from PNG to SVG for their generation is that I could not find the right value for PLANTUML_LIMIT_SIZE. At any rate, they generate correctly in SVG and also open correctly using Google Chrome (see [2] for an example diagram from my git repo). However, when I try to visualise them in Emacs, after a long time, I get a 30x30 size and a blank square.

So my question is: are there any settings I need to toggle in order to display very large SVG files using image-mode, or did I perhaps hit some kind of limitation?

Update 1: Please note that I can display regular (small) SVG images correctly, including smaller PlantUML diagrams.

Update 2: I'm using Emacs 27.1 on Debian GNU/Linux testing.

Update 3: I have read through the code of image-mode [3] and I cannot see any obvious conditional handling for SVG based on size. However, I am not an elisp expert so I probably missed something.

Update 4: I ran emacs with -q to figure out if this was a problem of my config, and it supplied me with a much more informative message:

Invalid image size (see ‘max-image-size’)

I then subsequently set this variable to some very large values:

(setq max-image-size 162704)

However, this only changed the error:

Error parsing SVG image ‘(image :type svg :file PATH_TO_IMAGE/dogen.text.svg :scale 1 :max-width 643 :max-height 324)’

[1] https://plantuml.com/

[2] https://raw.githubusercontent.com/MASD-Project/dogen/master/projects/dogen.text/modeling/dogen.text.svg

[3] https://github.com/emacs-mirror/emacs/blob/master/lisp/image.el


OK I think I got to the bottom of this. So, to recap, if you want images with either width or height which are larger than the default, you can update max-image-size, e.g.:

(setq max-image-size 20000)

You can see how this variable is used in Emacs C code [1]. However, Emacs uses librsvg for SVG support, and in its code you will find this [2]:

 if (scaled_width > 32767 || scaled_height > 32767) {
                g_printerr (_("The resulting image would be larger than 32767 pixels on either dimension.\n"
                              "Librsvg currently cannot render to images bigger than that.\n"
                              "Please specify a smaller size.\n"));
                exit (1);

To prove this is indeed the case, you can use libsvg directly via the command line, like so:

$ rsvg-convert --unlimited -d 1000 -p 1000 -w 35000 -h 38456  -o output.png dogen.text.svg
The resulting image would be larger than 32767 pixels on either dimension.
Librsvg currently cannot render to images bigger than that.
Please specify a smaller size.

For details as to why this limit exists, Sven Neumann explained [3]:

librsvg uses cairo for rendering and the image size limit exists in cairo. As far as I understand cairo's main goal is to provide rendering for the desktop, taking advantage of display hardware acceleration if possible. Limiting the target surface size to what can be expressed as 16bit integers allows some optimizations and given the target of the cairo rendering library performance is very important. Of course for the librsvg use case this limit is unfortunate and we would love to get rid of it. That is certainly not an easy task though

Finally, I believe the reason why you do not see this error coming out of emacs is due to the way errors are being handled in image.c:

  fn_g_object_unref (rsvg_handle);
  /* FIXME: Use error->message so the user knows what is the actual
     problem with the image.  */
  image_error ("Error parsing SVG image `%s'", img->spec, Qnil);

In summary, as things stand, max-image-size will work up to a limit of 32767. I'm yet to prove that, as it requires reorganising my diagrams.

[1] https://emacsformacosx.com/emacs-bzr/trunk/src/image.c

[2] https://gitlab.gnome.org/JustMonika/librsvg/-/blob/master/rsvg-convert.c

[3] https://gitlab.gnome.org/GNOME/librsvg/-/issues/658#note_1035036


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.