1. My reading of tectonic is that it still downloads TexLive? Do you really not have pdflatex on your system path?

2. I don't think its too hard to change text.usetex to include an executable name instead of simply a boolean. OTOH it will increase our maintenance burden when folks claim things don't work.

My reading of tectonic is that it still downloads TexLive?

Tectonic downloads .sty according to what your document uses - that's the main feature of it - you don't have to deal with tlmgr or use your Linux package manager to manage tex dependencies - it all happens automatically!

Do you really not have pdflatex on your system path?

I do have now, but getting the generated tex file to compile wasn't trivial, due to type1ec.sty and type1cm.sty - it took me an hour or so to figure out how to get these the right packages available, without downloading all of Texlive to my computer. This experience can be different among users of different distributions, but reading #16911 made me feel I'm not the only one.

I do have now, but getting the generated tex file to compile wasn't trivial, due to type1ec.sty and type1cm.sty - it took me an hour or so to figure out how to get these the right packages available, without downloading all of Texlive to my computer. This experience can be different among users of different distributions, but reading #16911 made me feel I'm not the only one.

But that seems an orthogonal issue to whether tectonic works? Personally I agree that it is a bit user-hostile for us to require on a non-standard package, but I'm not sure if that is on us, or on TexLive for not including it by default. I guess your point is that tectonic would have magically taken care of this for you, but that doesn't help our many non-tectonic users.

I guess your point is that tectonic would have magically taken care of this for you, but that doesn't help our many non-tectonic users.

That's part of the point but it's not accurate. Generating tex documents that with Tectonic will produce similar results to what's produced now, is simpler because it uses xetex, UTF-8 and modern OpenType fonts - meaning that generating such it won't even require the type1*.sty packages. It will only require fonts, which we can leave for the user to configure in case our default choice doesn't exist.

What about introducing another rcParam, like text.texengine or something that defaults to pdflatex?

Possibly with a finite number of options (pdflatex, xetex, ...). Benefit: it is easier to adapt the tex-file based on the option. Drawback: one cannot specify an exact path (or some parsing to extract the engine from c:\Program Files\...\pdflatex.exe is required).

But, yes, it can make sense to make the engine configurable in the light of potential benefits from fonts, UTF8 and xetex/lualatex. At the same time, there is for sure a risk for more issues popping up and more support required.

Probably it can make sense to subclass TexManager into PDFLatexManager and XetexManager for clearer separation. I think one challenge is how to deal with people (thinking they are) wanting to use xetex, but still want to use the old way of specifying fonts.

We currently don't support xetex or pdftex (and therefore likely can't support tectonic either), due to #20262 (comment). It would be nice to fix that, but it's not a trivial piece of engineering either (as outlined in that comment). If someone wants to have a go at that, I could probably provide some very high-level mentoring (the first step would be to get familiar with the current implementation of dviread)...

@doronbehar #29807 should help moving in that direction (by first supporting xetex itself), but from a quick look tectonic is more complicated to support because it does not record full font paths and (from what I've found...) may not expose an external API to query its internal font path database. Essentially, this is the issue described at tectonic-typesetting/tectonic#1019 (the "AFAIK .dvi files unfortunately only list the base name of the font files (e.g. font.otf and not /path/to/font.otf), so after Tectonic (or XeTeX) is done, dvisvgm has to look up the files again." part: actually xetex records full font paths so we're fine, only tectonic doesn't). If you're still interested in this, maybe you can try to get the issue fixed on tectonic's side?

From a brief investigation: it appears that tectonic searches the file via io.input_open_name
https://github.com/tectonic-typesetting/tectonic/blob/c2ae25ff1facd9e9cce31b48944b867773f709ec/crates/engine_spx2html/src/initialization.rs#L93-L96
but there's no command line API to access that. There's tectonic -X bundle search to check that the file exists and tectonic -X bundle cat to dump the contents of the file
https://github.com/tectonic-typesetting/tectonic/blob/c2ae25ff1facd9e9cce31b48944b867773f709ec/src/bin/tectonic/v2cli/commands/bundle/mod.rs#L102-L115
but modifying the codebase throughout to support file streams instead of file paths seems a bit heavy; frankly it would be simpler if they just directly recorded the file path (or at least provided a CLI command to print it, but even that seems quite adhoc).