docx: use proper DPI for fallback PNG

[edwintorok]

Pandoc calls rsvg-convert by specifying only a DPI. But that causes rsvg-convert to try to guess a pixel size as documented in its manpage.

Quite often that will result in a very low dpi (much lower than 72).
That is actually a useful diagnostic tool to see when the fallback image is used instead of SVG, but there should be a way to override this from the command-line.

Here is how a document using the SVG_logo from pandoc's test/command looks like.

test.md:

![Caption test](images/SVG_logo){fig-alt="Alt test" width="5in"}

Convert with:
/usr/bin/pandoc --default-image-extension=svg img.md -t docx -o img.docx --trace

This is how it looks like in the free version of Office.com:

LibreOffice 7.6.4.1:

Google Docs:

The PNG produced has only 100x100 pixels (matching the SVG's viewbox):

$ unzip -o img.docx
$ file word/media/rId23.png
word/media/rId23.png: PNG image data, 100 x 100, 8-bit/color RGBA, non-interlaced

And the --dpi flag of pandoc has no effect, you can specify a DPI of 1000 and it'll still produce the exact same image.

Solution

Pandoc needs to tell rsvg-convert the desired size in the document, at least when it is known in inches or pixels.
Add the image attributes to the mediabag to allow access to this information in the fallback conversion code.

Currently this is only done when something like a markdown source is used, I haven't updated all the other readers to extract the image attributes.

It'd be good if it also did this when the image is specified as a percentage of pagesize, but I couldn't figure out how to do the asks pagewidth inside PandocMonad.

And now it looks OK everywhere:
Google Docs:

LibreOffice:

Office:

Workarounds:

• Convert SVG to .EMF:

$ inkscape images/SVG_logo.svg --export-filename images/SVG_logo.emf
$ pandoc --default-image-extension=emf img.md -t docx -o img.docx --trace

That will look better, but still have jagged edges everywhere except Office365.
The advantage is that this format doesn't need any PNG fallbacks, and remains an actual vector format.
Still out of all the current options, this is currently (with an unpatched pandoc) the best way I could find to embed vector images.

• Use ODT instead

That will look the best with LibreOffice:

But Google Docs will convert to some unknown DPI when opened and still look bad

[edwintorok]

Draft pull request, because I'm not sure how you'd like to address this in the readers of other formats.
And storing all the attributes may be too much, perhaps we should store just the desired size in pt in the mediabag instead.

BTW the ODT may need a fallback image stored too, if not when you open and save in LibreOffice it'll add one, but it'll be a very low resolution one too.

[edwintorok]

I think this is ready for review now:

• it doesn't require changes in the Lua API
• almost no changes to writers other than Docx
• properly supports width percentages
• creates multiple fallback images for different sizes as needed
• test added for SVG->PNG fallback generation

One disadvantage that I can see:

• requires small change to PandocMonad API

I'd like to hear your thoughts on whether this is going in the right direction

[jgm]

Two quick comments:

• pageWidth as a Maybe Int -- what are the units here? That wasn't clear to me.
• I'm not persuaded we need a change in the PandocMonad API for this. The change is added runConversion (which is just a thin wrapper around pipeProcess, and actually not limited to conversions, but quite a general function for running any program). runConversion is only used once in this PR, and we could just use pipeProcess directly there to do the same thing, as far as I can see.

I'd like to see a more minimal patch without the PandocMonad change, or a stronger rationale for adding runConversion.

[edwintorok]

Thanks, I'll add some comments about pagewidth, I think the units are points.

Another approach that I considered (that avoids modifying PandocMonad) is to add a getPageWidth to Docx.hs, although this will perform some operations twice (parsing the reference.docx to figure out the size). The code to do that parsing can be factored out into a separate top-level function but it'll get called twice.
I cannot call pipeProcess directly because that is in the IO monad, and the Docx writer runs in the Pandoc monad.

[jgm]

Oh, I see now; you changed the type of svgToPng so it works with PandocMonad instead of MonadIO.

[jgm]

What troubles me is that runConversion is just very close to runAnyProgram. For example, you could do runConversion("rm","anyFile.txt",mempty).

If we were okay with that, it would be cleaner, I think, just to require PandocMonad instances to be instances of MonadIO (so liftIO works); we could define an instance for pure monads that just throws an error. I've considered that at times, but always shied away.

An alternative would be just to add svgToPng to PandocMonad. This wouldn't be a universal escape hatch for running programs.

[edwintorok]

I understand the desire the restrict what you can do (to avoid bugs and security issues).

I can make the change to use svgToPng in the pandocmonad, shouldn't take long.

[edwintorok]

The updated API changing commit is here: 682f972

I made both width and height optional to keep this commit smaller and the interface more flexible (should you want to revert back to the old behaviour then just pass Nothing, Nothing, the API doesn't have to be changed again).

I don't particularly like that there is a 4-tuple here instead of 4 arguments, but I couldn't figure out how to implement the various instances and lift for 4 arguments (all other APIs here take only 1 argument).

Should I introduce a data record here to hold those 4 arguments instead?

[jgm]

With one argument you can do e.g.

  putCommonState = lift . putCommonState

but with four something like this should work:

  svgToPng w x y z = lift $ svgToPng w x y z

[edwintorok]

but with four something like this should work:

  svgToPng w x y z = lift $ svgToPng w x y z

Oh that is surprisingly simple, I was too caught up in trying to keep the LHS short.

I pushed a fixup, see whether you like it better or not.

[jgm]

I lost track of this somewhere along the way -- do you want to rebase against current main?

[jgm]

My impression is that this PR is close to ready, and just needs some rebasing and touching up.
Are you still intending to work on it?

[edwintorok]

Sorry been very busy. I'll try to take a look after Christmas.