# jgm/pandoc

### Subversion checkout URL

You can clone with
or
.

# windows and texlive error missing article.cls#1151

Closed
opened this Issue · 45 comments

### 5 participants

On two different machines, win 8.1 and win 7 x64 with the latest and greatest pandoc and texlive, I get an error 43 that article.cls is missing when I try to convert a markdown document to pdf.

If I first convert to tex first then manually run pdflatex everything works.

If I switch to miktex everything works. For several reasons I would like to keep using texlive. The program I am using automatically invokes pandoc and I can not separate out convert from markdown to tex then tex to pdf.

Someone thought maybe my username was long. It is under 8 characters.

Owner
Owner

I tried searching for awhile and I could only find one related error about 5 months ago on this issue log. They were getting a different but similar error messge.

I tried re-installing and I just ran mktexlsr and reopened my command window after that. That didn't work.

I can see the texlive path in my path set in the environment settings.

I tried specifying the full path to pdflatex and that did not work. I can compile using pdflatex from that same command line.

This is the actual message I received:

c:\0\source\source\r>pandoc test1.md -o test1.pdf
pandoc: Error producing PDF from TeX source.

Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: cls)

Enter file name:
! Emergency stop.

l.2 \usepackage

c:\0\source\source\r>
Owner

No responses from tex stackexchange. But I did get a colleague of mine try it on his win 7 x64 computer and he too received the same error message about article.cls missing. I don't think I have a choice but to swtich to MikTex.

I have the same error with a Windows 7 x64 computer, pandoc 1.12.3 and TexLive 2013.

Just so I can confirm a hunch, can you guys list both your miktex and texlive versions?

I was using the latest and greatest version of both. I did a fresh install of both. TexLive: 2013 and whatever the latest version of MikTex as of 10 days of ago.

I also tried this on another win 7 x74 laptop and had the same issue with TexLive and Pandoc.

I haven't tried MikTex yet, but my Texlive version was a web-installed 2013.
I have also tried the Export to PDF option from the program Texts, that, as I assume, incorporates Pandoc (https://github.com/jgm/pandoc/wiki/Pandoc-Extras).

If it does, perhaps it uses an older version? I have Pandoc 1.12.3 now, but can't remember having this problem in the past. Perhaps others could try to reproduce this with other versions? The setup is very simple:

1. Have TexLive as the Latex encironment.
2. Create a Markdown file.
3. Use pandoc -s *<input.md>* -o *<output.pdf>*

That is the command I am using too. Same version of pandoc. If I first convert from markdown to tex, then run the pdflatex command myself it works.

Well, this rules out my initial working theory, which is kpsewhich interaction wonkiness between older versions of MiKTeX and TeX Live.

Well, it could have been some problem in this area. I also checked kpsewhich article.cls, which returns:

C:\Users\Yinglai>kpsewhich article.cls
c:/texlive/2013/texmf-dist/tex/latex/base/article.cls

@jgm John, it looks like the runTeXProgram function in Text.Pandoc.PDF sets the TEXINPUTS environment variable but always assumes the : path separator. This is valid on POSIX but not on Windows, which uses a semicolon ; because : is the drive-letter delimiter.

I think this is the most likely candidate for the TeXLive problem. A little Google search shows that kpathsea looks for that trailing TEXINPUTS path separator to insert its own stuff. I'm guessing a little CPP magic would solve this problem.

Owner

@jgm Yes, AFAIK they have entirely different mechanisms for managing texmf paths, and MiKTeX's kpathsea is just a compatibility layer for its own system (that's how it can pull packages on-the-fly, etc).

Hard to know for sure though, haven't used MiKTeX (or Windows for work at all) since undergrad.

Thank you all for these efforts. It would be great if the problem could be resolved like this.

Same here. Thank you. I know others that this will eventually help. RStudio is switching to using pandoc for their markdown translation engine soon. In my circles, anyone who is using RStudio on windows is using texlive and not miktex.

I can setup clean win 7 environments to test any changes. Not sure if that would help this if and when ready.

referenced this issue from a commit in YinglaiYang/pandoc-seed-project
 Yinglai Yang Beta-Commit: Added task that compiles to formats like PDF, etc. works ===================================================================== The task `md2pdf` now works on Linux. Only a small problem remains: Pandoc not writing to *stdout* when compiling to formats like PDF, odt, etc. is displayed as an `Error`, which can be confusing. **Note**: As this commit message is being written, the task `md2pdf` will not work on Windows when TexLive is used a the LaTeX-environment. According to reports, using MikTex instead does work. The problem probably is due to an incompatibility between Pandoc and TexLive which will be resolved ([on Github Issue Tracker](jgm/pandoc#1151). b37f936
closed this issue from a commit
 jgm PDF: Use ; for TEXINPUTS separator on Windows. Closes #1151, I hope. Testing needed. 19b127b
closed this in 19b127b
Owner

I don't have the right setup to test this change, so please test it on your Windows/texlive systems, if you are able to compile pandoc from source.

Ok, I will try to do it and post the results.

I have tested it and I find it doesn't work (commit 19b127b):

PS C:\Users\gong-yi\Documents\Prorgramming\Pandoc> pandoc -o test.pdf test.md
pandoc.exe: Error producing PDF from TeX source.
! Undefined control sequence.
<*> .\tex
2pdf.3612\input.tex
!  ==> Fatal error occurred, no output PDF file produced!
PS C:\Users\gong-yi\Documents\Prorgramming\Pandoc> cat test.md
# this is the first heading

## and this is the second heading

### hello world

tuoeu

PS C:\Users\gong-yi\Documents\Prorgramming\Pandoc>

Woah that's a crazy error message. Are you able to reproduce this message if you compile yourself the latest stable version of Pandoc?

Yes, this was done by manually modifying src/Text/Pandoc/PDF.hs and pandoc.cabal files in the last stable release's (1.12.3.3) tar ball.

Just to be clear: does it work if you remove the modification and compile again?

this is what I get with the stable release (1.12.3.3) without any modification (install via cabal):

Installed pandoc-1.12.3.3
PS C:\Users\gong-yi\Documents\Prorgramming\Pandoc> pandoc -o test.pdf test.md
pandoc.exe: Error producing PDF from TeX source.

Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: cls)

Enter file name:
! Emergency stop.

l.2 \usepackage

PS C:\Users\gong-yi\Documents\Prorgramming\Pandoc> i

Hmm.. maybe Miktex doesn't like trailing separators after all. Do you currently have anything set for your TEXINPUTS environment variable?

If you don't have anything set, try changing line 157 of src/Text/Pandoc/PDF.hs from

let texinputs = maybe (tmpDir ++ sep) ((tmpDir ++ sep) ++)

to the following line

let texinputs = maybe (tmpDir) ((tmpDir ++ sep) ++)

With the suggested change, this is what I got:

PS C:\Users\gong-yi\Documents\Prorgramming\Pandoc> pandoc -o test.pdf test.md
pandoc.exe: Error producing PDF from TeX source.
! Undefined control sequence.
<*> .\tex
2pdf.3156\input.tex
!  ==> Fatal error occurred, no output PDF file produced!

PS C:\Users\gong-yi\Documents\Prorgramming\Pandoc>

Hmm that is indeed very strange. I've just setup my only Windows computer with Miktex and Pandoc 19b127b and it builds the pdf file perfectly, even when I set my command prompt to non-UTF8/ASCII encodings. Did pandoc successfully produce the tex2pdf.3156 directory under your test directory?

I was using TexLive, and there was no tex2pdf.3156 directory

My apologies, it was getting late here and I simply forgot which distro has the problem in the first place.

Now that I've switched over to TexLive, I'm able to reproduce this. I'll look into it when I'm more awake.

Oh... my... what ...

So with TexLive on Windows, this give the above error message:

pdflatex -halt-on-error -interaction nonstopmode -output-directory .\tex2pdf.3156 .\tex2pdf.3156\input.tex

whereas this works perfectly

pdflatex -halt-on-error -interaction nonstopmode -output-directory ./tex2pdf.3156 ./tex2pdf.3156/input.tex

I should have guessed. Running kpsewhich actually shows:

C:\Users\Tim\Documents\GitHub\testing\texlive>kpsewhich article.sty
c:/texlive/2013/texmf-dist/tex/latex/base/article.sty

Seems like TeXLive wants the forward-slash separator everywhere, whereas MikTex uses the back-slash like everyone else.

After more testing, I can conclude that MikTeX understand both the / and \ path separators (in both TEXINPUTS and CLI arguments to LaTeX renderer), while TeXLive only understands /, even on Windows. I think as long as we're targeting just MikTeX and TeXLive on windows, we can exclusively use the / path separator.

Thanks eVITAERC, that's really a great catch

reopened this
closed this issue from a commit
 jgm PDF: Use / as path separators even on Windows. This seems to be necessary for texlive. Closes #1151 (again!). c026c16
closed this in c026c16
Owner

Thanks for tracking this down! If you could test this latest version with both miktex and texlive, that would be great.

works still for MikTeX which is hard to confuse, but not enough for TeXLive because the tempDir separators need to be scrubbed as well. Pandoc ends up feeding to the latex builder something like

.\tex2pdf.3134/input.tex

Idea: bring back </> and instead in a #ifdef _WINDOWS directive do a intercalate "/" \$ System.FilePath.splitDirectories on both tempDir and file. Thankfully, at least we don't have to probe for MikTeX.

By the way, I've noticed the System.FilePath.searchPathSeparator that can be used instead of the current macro for it.

I've also noticed that this approach means that Pandoc won't properly clean up the tempDir after a successful build. Might want to remedy that somehow as well.

reopened this
referenced this issue from a commit
 John MacFarlane PDF: Use / as path separators in tempdir on Windows. This is needed for texlive. Note that the / is used only in the body of withTempDir, so when the directory is deleted, the original separators will be used. See #1151. 5040f3e
Owner

Try the latest.

referenced this issue from a commit in timtylin/scholdoc
 timtylin PDF: Use / as path separators in latex input only Fixes compile error on Windows for 5040f3e Reverted back to canonical file separators in all places except for arguments to the LaTeX builder and in TEXINPUTS See #1151. Note: Temporary directories still fail to be removed in Windows due to call of ByteString.Lazy.readFile creating process ownership of the compiled pdf file. 1aed920
referenced this issue
Merged

### PDF: Use / as path separators in latex input only #1190

There's a small typo in function declaration that prevents compiling, but otherwise it works great! Compiled correctly for both MikTeX and TeXLive.

Please consider the pull request, which is also tested, and which I hope improves the localization of the problem in the code.

There's a new separate issue where the use of ByteString.Lazy.readFile on the compiled pdf prevents withTempDirectory from deleting tmpDir when makePDF returns. Best to open a new issue for that, I think. Yes, this means that temporary directories likely haven't been removed cleanly at all on any Windows machine.

Thanks John, for promptly resolving this.

Owner

@jgm The new issue is opened. Thanks very much for the responsiveness.

For everyone originally involved in this issue, please report on whether it resolves your TeXLive rendering problem. I don't personally have a stake in rendering latex on Windows, so it's still possible that I missed something.

I confirm that the last updated pandoc with the patch merged from Tim Lin now works perfectly with TexLive on Windows.

Hi, I also managed to test the latest version of pandoc in the repository now. I used pandoc 1.12.3.3 on Windows 7 Professional x64, and Texlive 2013.

There seemed to be no problem anymore, apart of the problem that folders which are temporarily created during conversion to PDF are not removed right now (these folders have names like: tex2pdf.<number>).

I did following tests:

• With a file wikilatex.tex:

pandoc wikilatex.tex -o wikilatex.pdf

• WIth a file test.md:

pandoc -s test.md -o test.pdf

Both commands gave me a correct PDF.

Owner
closed this