Skip to content
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

customizing the name of the output file when converting from standard input #435

Open
efx opened this issue Aug 16, 2019 · 4 comments
Open

customizing the name of the output file when converting from standard input #435

efx opened this issue Aug 16, 2019 · 4 comments

Comments

@efx
Copy link
Contributor

@efx efx commented Aug 16, 2019

As a developer I would like to customize the default filename for PDF output when converting a LaTex file from standard input.

steps

  1. cat my-document.tex | tectonic -
  2. notice the output file is always texput.pdf. The documentation explains this is the default.

It would be helpful to be able to customize the output file name or have an option to steam the PDF to standard out. I am batch processing LaTeX files and as part of looping will need to operate on individual files. Piping files using stdin is great but I will need to block the asynchronous loop because of the output filename being the same for each iteration. That or get clever with --outdir option.

Does the following line dictate this behavior?:

match files.remove(OsStr::new("texput.pdf")) {

@pkgw

This comment has been minimized.

Copy link
Collaborator

@pkgw pkgw commented Aug 16, 2019

Yes, this is a reasonable thing to support.

The relevant line is this one:

https://github.com/tectonic-typesetting/tectonic/blob/master/src/bin/tectonic.rs#L67

This issue gets into a topic that's bothered me ... I would like to support these sorts of customizations, but I'd also really like to avoid proliferating a zillion command line options to the tectonic CLI program, as I've discussed in #175. I like the idea of something like the -Z flag used in rustc ... and when thinking about that I also started thinking that I'd like to use structopt for the command line parsing. And then also I've started thinking maybe we should have a split along the lines of rustc and cargo, where there's a freestanding executable with lots of fiddly options, but then most compilations are driven from a separate tool that encapsulates most of that stuff in a configuration file. Whenever I've thought about these things I've gotten bogged down in high-level architecture thinking and haven't actually made any concrete progress, which isn't great.

@efx

This comment has been minimized.

Copy link
Contributor Author

@efx efx commented Aug 19, 2019

I would like to support these sorts of customizations, but I'd also really like to avoid proliferating a zillion command line options

I heartily agree. We don't want a kitchen sink of every user's needs. The -Z pattern would be nice for extending the options of tectonic without clutter. I'd love to know of standard UX practices for CLI interface design. Is there a standard pattern for solving this kind of problem? I think the cargo / rustc example does partly answer that and mimicking the design seems best in absence of experts and continuous experience to guide the design.

when thinking about that I also started thinking that I'd like to use structopt for the command line parsing

I just implemented a learning project using structopt and found it quite nice.

Whenever I've thought about these things I've gotten bogged down in high-level architecture thinking and haven't actually made any concrete progress, which isn't great.

The joy of where thoughts lead! Do you think moving to structopt would make high level architecture changes easier?

I like the idea of using a configuration file that exposes advanced settings. A discourse survey could help gather more data alongside these linked issues.
I can help implement two of these things:

  1. convert the existing CLI to use structopt
  2. Implement this use case using that structure

Given the output format isn't tied directly to the underlying PDF processes, I would think it should be a top level CLI option. That said, we could define criteria for top level options and then go through the existing CLI options to determine which should remain or end up in the Tectonic.toml file with default values.

@rekka

This comment has been minimized.

Copy link
Contributor

@rekka rekka commented Aug 19, 2019

This issue gets into a topic that's bothered me ... I would like to support these sorts of customizations, but I'd also really like to avoid proliferating a zillion command line options to the tectonic CLI program, as I've discussed in #175.

I think that it makes sense to have reasonable command line options that do not change the content of the produced document like --outdir or --synctex. Having something like --output-name is reasonable since in this case tectonic cannot deduce the name, it does not change the content of the output, and makes scripting easier (a sed '/inputenc/d one liner to fix a document xetex cannot compile is handy at times.)

On the other hand, #175 does change the content of the output so it feels more appropriate to use a configuration file or rather have this configured directly in the source document. But from a practical point of view, if we do not have a better way to customize the internals, a command line option can be a good temporary fix (that can be possibly deprecated, tectonic is still in version 0.*)

@pkgw

This comment has been minimized.

Copy link
Collaborator

@pkgw pkgw commented Aug 21, 2019

@rekka Hmmm, I like that line of thinking about how to reason about where to activate different options. But to be precise, the TeX code can observe the output file name via \jobname, so changing that can influence the output. In "reasonable" cases \jobname should only be used to name the .aux file and so on, but there aren't any limits about where it can be used. One idea I've had is that maybe Tectonic should force \jobname to always be texput, and you'd have something like a configuration file setting to override it if your document really cared about the precise value of \jobname.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.