More predictable handling of large images

[KristianLyng]

I've got some significant graphics generated with dot. When I generate HTML, they look fine, but in the PDF, they tend to be far too small. Typically taking up half the width of the page, instead of filling out. On the other hand, other images fill out perfectly.

To give you an idea: The OK images can have resolution such as 911x598, while the ones that fail right now have 1117x1799, 818x808 and 1123x964. You can see this on http://varnishfoo.info/varnishfoo.pdf (if it hasn't been solved by the time you read this bug).

I tried doing things like :width: 100%, but that made things even worse. If the width was too big, I just got warnings about 10 or more empty pages. And besides, I would really like to avoid mucking around with :width:, since that will also affect other formats than PDF.

If anyone cares enough to give me a pointer as to where the problem might be, I don't mind working the source code. But before I even start, I think some discussion as to what's actually going on would be in place. And possibly what the desired behavior should be, because it's not entirely obvious to me.

[KristianLyng]

Forgot to mention that the dot-graphs are all rendered to PNG, as are all other images.

[pmaupin]

Part of the problem might be that the image has margins. But out of curiosity, why would you render to PNG?

If you render to PDF (or to SVG and then use inkscape to generate a PDF), you can get a vector image that looks good when you scale the PDF.

[KristianLyng]

I can certainly do svg, but then it comes back to cross-format support (html). I haven't really tested svg support in browsers for the last ten years... I will give it a shot, but that really is more of a workaround than a fix.

And there's the issue of :width: 100% acting really bad too though. I am assuming it got confused when width caused it to exceed the page height.

[pmaupin]

You may be right about the confusion, in which case the SVG may not be helpful.

[KristianLyng]

Using -e inkscape to get the svgs, it works closer to what I would have expected. I think this also underlines that there's something wonky with the image scaling here though. I would have expected the same scaling behavior, assuming the picture was larger than it needed to be.

With -e inkscape and svg, the image will "correctly" take the entire page if needed. For the graphs that were not taller than the page, this works perfectly, just the way I want it. For the one graph that's taller than the page, the problem is now that there's no room for any header or anything, but that I can work with at least.

[KristianLyng]

Also, when I tried using .. figure:: instead, I'm back to the whole "reportlab.platypus.doctemplate.LayoutError: More than 10 pages generated without content - halting layout. Likely that a flowable is too large for any frame." issue. Considering this is an SVG now, scaling shouldn't really be an issue at all, but it obviously is.

[KristianLyng]

And one more detail: The document does:

Header

.. image: ...

When the image takes an entire page, these lines end up taking three pages when combined with -b2 : 1. blank page, 1. page for the header and 1. page for the actual image. I might have expected two, but three is clearly a bug.

[pmaupin]

"Considering this is an SVG now, scaling shouldn't really be an issue at all, but it obviously is."

This is actually not surprising considering what you have described -- if interested, see the discussion below the possible workaround.

Possible workaround:

Now that you have transitioned to using a PDF file for input (the file output by inkscape), you might be able to tweak the image easier. Unfortunately, if you are using the same rst file for both web and PDF, this might be difficult or impossible.

If you can use the tweak, it would be by appending a location viewport for the image into the filename, e.g. instead of "foo.svg" you can use "foo.svg#viewrect=,,,"

The units are in points or, if you are using the latest version of pdfrw, you can also specify them in fractions (<= 1) of the image.

This allows you to subset your image. If it is taller than a page and is not objectionable to split it, you can create two different images from it on two separate pages in your document.

Discussion:

I don't think rst2pdf or reportlab actually resample raster images -- I think they let the PDF viewer do the scaling -- but even if I am wrong about this, the issue you are describing appears to have to do with confusion inside rst2pdf/reportlab about the image size and how to place it in the document, not with the contents of the image itself.

The fact that SVG images are vector-based doesn't really play a part in this process (although it might peripherally seem so if the units or offsets are slightly different). What the vector format does is insure that, once the image is in a PDF document, it can be displayed nicely at any resolution.

The way you have described the problem, it sounds like there is a platypus bug, or at a minimum, a bad interaction between rst2pdf and platypus, when it comes to resizing images.

The rst2pdf code paths between svg and png are slightly different, so this bug might merely be easier to provoke with a png.