New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bfirsh opened this Issue Dec 8, 2017 · 4 comments

Comments

Projects
None yet
3 participants
@bfirsh
Contributor

bfirsh commented Dec 8, 2017

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

This comment has been minimized.

Owner

brucemiller commented Dec 8, 2017

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

This comment has been minimized.

Contributor

bfirsh commented Dec 8, 2017

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

This comment has been minimized.

Owner

brucemiller commented Dec 8, 2017

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.

@dginev dginev added bug minor labels Dec 8, 2017

@dginev dginev added this to the LaTeXML-0.8.4 milestone Dec 8, 2017

@brucemiller

This comment has been minimized.

Owner

brucemiller commented Feb 13, 2018

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.

@dginev dginev modified the milestones: LaTeXML-0.8.4, LaTeXML-0.8.3 Feb 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment