--graphicsmap is not respected if destination file of different format already exists

[bfirsh]

Given a basic document with \includegraphics pointing at a PDF:

$ latexml --format=html5 --dest=dest/index.html input/main.tex

LaTeXML will convert the PDF to PNG and reference it as expected. Now, when I run this without deleting the destination directory:

$ latexml --format=html5 --graphicsmap pdf.svg --dest=dest/index.html input/main.tex

I expect it to convert the PDF to SVG and reference that. Instead, the destination file will still reference the PNG.

Presumably there is some sort of mechanism that checks if the graphic has already been converted, but it is not being invalidated by a different --graphicsmap option.

[brucemiller]

Hmm, yeah; but is this a bug or feature request, I wonder; Basically the intent of --graphicsmap was to list possible mappings between image types, rather than to express a preference for a particular type. And yeah, a previous conversion takes precedence (as long as it is an acceptable type), since image conversions are typically so slow.

As you found, a workaround, perhaps counter-intuitive, is to remove the destination directory and start fresh.

[There is a weak sort of expression of preference embedded in the code, but isn't sensibly configurable, atm; and probably it would still think that an existing conversion would be preferable.
Since I get resistance to new command-line options (reasonably so), exposing this is waiting for a nicer configuration setup to get implemented]

[bfirsh]

Regardless of the intent behind the flag, it was certainly unexpected behaviour. I would expect running latexml to always produce the same output, regardless of what was already in the output dir.

Anyway - a minor problem, but I thought it was worth filing. :)

[brucemiller]

Not an unreasonable expectation, really. Probably we need a more specific way of saying what you want, but perhaps also the cache-invalidation should be a bit smarter.

[brucemiller]

Grumble... Fixing this invalidates all the existing image caches, but it actually makes sense and is more expectable behaviour. So, fixed! Thanks for the report.