Explore whether we can change file path structure for LaTeX files

[jmshapir]

In LyX we use paths relative to the LyX file: https://github.com/JMSLab/Template/blob/380e12f4d8cb94165fd9f86262894780b008be1e/source/paper/Template.lyx#L272

In LaTeX we use paths relative to the root: https://github.com/JMSLab/Template/blob/380e12f4d8cb94165fd9f86262894780b008be1e/source/paper/Template.tex#L53

The result is that, in a repository configured according to the Template, it's harder to compile manually in LaTeX than it is in LyX.

Can we investigate whether there is a robust way to modify the builder so that we can use the same path structure in LaTeX that we use in LyX?

Thanks!

[rcalvo12]

Per meeting: Should look into solution offered by this stack exchange thread.

[ew487]

@jmshapir I made some changes to the tex files so that commenting out line 17 on the main file should allow you to compile by clicking the button in the tex editor. Do you think that works?

[rcalvo12]

@ew487 The solution you implemented worked for me! I was able to compile using scons from the root and then, once I commented out line 17, was able to compile from within the document.

[ew487]

@rcalvo12 Great! Thank you for checking!

[jmshapir]

@ew487 thanks!

When trying to compile with line 17 commented out, I hit the error below, though it may be unrelated to the file paths. (Given that @rcalvo12 didn't hit the error I suspect we shouldn't worry about it just now.)

In terms of the implementation, is there a reason you prefer to specify a \dir macro rather than universally specifying the input path as suggested here?

I can see tradeoffs either way so am curious to know how you are thinking about it, thanks.

Sorry, but miktex-epstopdf did not succeed.

The log file hopefully contains the information to get MiKTeX going again:

  C:\Users\Jesse Shapiro\AppData\Local\MiKTeX\miktex\log\miktex-epstopdf.log

! Package pdftex.def Error: File `../../output/analysis/plots/gdp_educ-eps-conv
erted-to.pdf' not found: using draft setting.

See the pdftex.def package documentation for explanation.
Type  H <return>  for immediate help.
 ...                                              

l.8 ...aphics{\dir/output/analysis/plots/gdp_educ}
                                                  \medskip{}

[jmshapir]

(Also, just confirming that I was able to resolve the epstopdf error that I reported in https://github.com/JMSLab/Template/issues/85#issuecomment-1781908760.)

[ew487]

@jmshapir I didn't use the universal input path because I couldn't get it to work. But I didn't try very hard so I will give it another go and get back to you on the pros and cons!

[jmshapir]

@ew487 thanks and sounds good! Of course if you get stuck trying the universal input path, feel free to pause and let me know so we can reconsider whether it's worth investing in that direction.

[ew487]

@jmshapir I implemented the universal input path in 610000b. I think the main advantage is that the the user does not need to comment out anything to run with scons or compiling manually. I think some disadvantages are that 1) we have to remember not to duplicate file names, 2) if we create a new file, we have to remember to specify its location in two places, and 3) we will be searching folders with ../../ that we have no idea what they look like.

[jmshapir]

@ew487 thanks!

That solution looks interesting.

A couple things:

1. In 88aaf0c I split the path statement across two lines. The parallelism might make it easier to remember to specify both (re: your point 2), and to disable the local compile paths if they cause errors (your point 3). Let me know if you see any meaningful downsides to splitting this way.
2. I tried just folding the graphics paths into the input@path argument but it didn't seem to work. Any idea why? Is it because graphicspath is storing the graphics path in a macro that is separate from the input@path macro?

[ew487]

@jmshapir I don't see any meaningful downsides to splitting that way. Regarding the graphicspath, I moved it into the input@path in b3dc300. I think part of the problem was that graphicspath takes on the value of input@path at the time that graphicx is loaded, so I moved the loading of the package later. I'm not sure why but I also had to add an extension to the filename when using includegraphics in the child document.

[ew487]

@jmshapir I also tested a slightly different implementation in bc0c88c that avoids the duplicate filename issue, but the tradeoff is that it searches the entire repository.

[jmshapir]

@ew487 thanks!

@jmshapir I don't see any meaningful downsides to splitting that way. Regarding the graphicspath, I moved it into the input@path in b3dc300. I think part of the problem was that graphicspath takes on the value of input@path at the time that graphicx is loaded, so I moved the loading of the package later.

Nice, thanks.

I'm not sure why but I also had to add an extension to the filename when using includegraphics in the child document.

Specifying the extension doesn't seem so costly to me, but I would like to make sure this works with EPS (in addition to PNG).

@jmshapir I also tested a slightly different implementation in bc0c88c that avoids the duplicate filename issue, but the tradeoff is that it searches the entire repository.

That makes sense. I see some merit in that alternative but as of now I think I favor the more explicit approach (as of b3dc300) as it narrows the search a bit and so might result in fewer side effects.

[ew487]

@jmshapir Regarding eps files, it does not work as is, so I can look into that.

[jmshapir]

@ew487 understood thanks. If we're not able to get an implementation that works with EPS this way we can always revert to making graphicspath explicit.

[ew487]

@jmshapir I think the issue is with pdflatex, since when I manually compile with xelatex the eps files work. Would you or @rcalvo12 be able to confirm this?

[jmshapir]

@rcalvo12 can you check this?

If @rcalvo12 confirms the issue, I think we can just revert to making graphicspath explicit.

[jmshapir]

@ew487 I had a few minutes to test this myself and I can confirm that I get an error compiling locally with pdflatex but not with xelatex.

I'm reluctant to design the template so that pdflatex does not work out of the box, so am inclined to revert to the solution with input@path+graphicspath. Can you implement so I can take another look over that implementation?

Thank you!

[rcalvo12]

@ew487 I had a few minutes to test this myself and I can confirm that I get an error compiling locally with pdflatex but not with xelatex.

@ew487 Just want to confirm that I also tested this and had the same results as both you and @jmshapir.

[jmshapir]

@rcalvo12 thanks!

@ew487 given that, let's revert to the plan below from https://github.com/JMSLab/Template/issues/85#issuecomment-1793817129, thanks!

I'm reluctant to design the template so that pdflatex does not work out of the box, so am inclined to revert to the solution with input@path+graphicspath. Can you implement so I can take another look over that implementation?

[ew487]

@jmshapir It should be reverted now!

[jmshapir]

@ew487 thanks! I fiddled with it a bit locally and it seems to behave as expected.

Can you compile the repo and open a pull with @jmshapir as reviewer?

[ew487]

Thread continues in its pull request #86

[jmshapir]

Interim summary: We found an approach we like better so we are going to abandon the branch 85-explore-whether-we-can-change-file-path-structure-for-latex-files and open a new pull for 85-testing.

[jmshapir]

Summary: In this issue we developed and tested a solution to allow users to compile TeX files both manually and via scons without having to intentionally toggle the document. Changes brought to main in 204def9.