Handle EPS images

[pkgw]

Tectonic doesn't support PostScript or EPS images: xdvipdfmx gets them into PDF files by running an external "distiller" command to convert them to PDF, which is something that we absolutely don't want to do, because Tectonic aims to be self-contained and embeddable.

If xdvipdfmx converts to PDF, presumably that’s the only technique that works, so we’d have to implement that in order to support (E)PS images. Sounds like a lot of work, unfortunately. Ideas welcome!

[durka]

I mean, you call out to latex and bibtex, right? Seems like calling out to epstopdf as well isn't so terrible.

[pkgw]

No, we don't. I need to find a way to communicate this more clearly, but all of the TeX and bibtex engine code is integrated into Tectonic — it's a self-contained system.

[durka]

What does "integrated" mean exactly though? It wasn't ported to rust...

[pkgw]

The relevant C code is compiled and linked into the Rust binary and called from the Rust code — no external binaries are invoked.

[durka]

Ah I see. Would it be possible to do the same with Ghostscript? That's what epstopdf really is.

[pkgw]

In principle, yes, but there are two reasons I lean against that path:

1. I'm pretty sure that Ghostscript is very large with a lot of interactions with the broader OS environment, which would make it a lot of work to embed.
2. I think it is fair to consider this as being beyond the scope of Tectonic, anyway. I think it makes more sense to have people convert formats before running the Tectonic engine. If this needs to be done in an automated way I'd say that the right approach is to use a build tool like ninja.

[pablojimpas]

Is there any workaround for this to date?

This is an issue that prevents me from migrating my projects to tectonic

[pkgw]

Well, the situation still hasn't changed. In fact, one thing I've come to appreciate over time is that Ghostscript is generally considered to be a pretty significant security hazard these days, so I wouldn't even consider bundling it within Tectonic anymore.

My recommendation is that if you need to do image conversions such as EPS → PDF, those should happen outside of Tectonic rather than within it. So, basically, set things up to do that conversion as part of your build process before you launch Tectonic. Traditionally, the TeX ecosystem has had an opposite approach of having the engine launch tools on the fly, but I think it's not a good approach in general; it's analogous to an approach where your C compiler tries to invoke yacc for you, rather than you driving the overall build process with something like make.

One helpful thing here is that if your document has a command that looks like \includegraphics{foo}, by default Tectonic will look for foo.pdf, while a more traditional engine will look for foo.eps. So if you don't want to hardcode the file format in your TeX code, you should often be able to leave it ambiguous.

[pablojimpas]

Thanks, @pkgw! I will look into better ways of handling my build process to produce PDFs or SVGs then. I'm using EPS mainly coming from the output of PlantUML diagrams, so it should be an easy change since apparently PlantUML also generates PDFs.

[pkgw]

Glad to hear it. If anyone has any use cases where the generate-PDF-externally approach really seems unworkable, that would be good to know about, but I think I'm going to close this since I'm now fairly convinced that we shouldn't add built-in support for EPS processing.