Specifying Local TeX packages and classes

[jcarpi]

Bug description

I have organization-internal document classes that I'd like to use with Quarto. I can render to a latex output, and then build the PDF myself, but I'd ideally like to render .qmd files to PDFs all in one step.

Specifying a path to documentclass causes Quarto to search for the path on TeXLive if latex-auto-install is enabled. If latex-auto-install is disabled, then a corrupted PDF file is generated (the file cannot be opened).

I have a global TEXINPUTS variable set, which works with latexmk, but Quarto does not seem to use that variable.

Is there any way to specify local LaTeX packages and classes?

[cderv]

Is there any way to specify local LaTeX packages and classes?

Does it work if you have your class file locally to the .qmd file ?

I have a global TEXINPUTS variable set, which works with latexmk, but Quarto does not seem to use that variable.

How is your TEXINPUTS set up ? Is this on your OS environment variables ?

@dragonstyle Are we respecting TEXINPUTS ?
Or do we need to use another variable like latex-input-path somewhere in YAML ?

[dragonstyle]

A couple notes:

• We have an options latex-input-paths which accepts an array of paths to add to TEXINPUTS. This doesn't currently appear in the PDF reference or documentation - whether or not we find another bug here, I will keep this issue open to be sure we add this.

• I expect TEXINPUTS to be respected (in fact, that is how we make the latex-input-paths available - we prepend any user provided paths)

I did see that we were unnecessarily setting TEXINPUTS when there were no user provided paths, so it is possible that this is affecting something. I made a change to the behavior and a new pre-release is on the way with this change (should be 1.2.183).

[cderv]

This doesn't currently appear in the PDF reference or documentation

@dragonstyle general thoughts : maybe we should have a dev version (or pre-release version) of the reference pages ? (probably more realistic than a dev version of the all doc).

This would help find those new features maybe.

[dragonstyle]

It would be very nice to have something like this (or perhaps even a version in the YAML schema that we can use to denote when a property become supported or ceased being supported). That would make it easy to generate version specific reference or a global reference that contains release information about availability... We still don't really have a great / consistent approach to documentation versions.

In this case, I also just forgot to add it to the schema definitions (and it was still functional since it would be used in an open portion of the schema). I just added it, so it will appear the next time we generate the reference doc.

[jcarpi]

Thank you all for your quick responses — sorry this reply is so late. I did find another solution. I changed the pdf-engine to latexmk, which then respected TEXINPUTS. Maybe xelatex, and other TeX engines simply don't check for TEXINPUTS? By that I mean, is TEXINPUTS a latexmk exclusive "thing"?

Seems like other topics are discussed here too, so I'm glad this issue triggered a good discussion! Sorry if it was a "false" issue (read the possible latexmk exclusivity comment above).

[dragonstyle]

By switching that engine to latexmk, you're bypassing our execution of the PDF generation, so perhaps you're just dodging the configuration issue that we have. If you can reproduce the issue, I'd love to see how as it would be great to fix this issue - I'll mark this closed for now, but if you have an easy way to reproduce this I would very much appreciate it!