windows and texlive error missing article.cls

[stephenll]

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.

[jgm]

I would try, first, running

mktexlsr

then if that doesn't help, uninstall and reinstall texlive.

A google search for similar problems shows that several people fixed
it by reinstalling texlive.

+++ stephenll [Feb 10 14 09:22 ]:

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.

—
Reply to this email directly or [1]view it on GitHub.
[3044__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcwNzU4NTc1MCwi
ZGF0YSI6eyJpZCI6MjUzNDIyNTJ9fQ==--1b6af3a58fdf76318a9ab6d67468536591d61
339.gif]

References

1. windows and texlive error missing article.cls #1151

[jgm]

OK, I see your setup works when you run pdflatex yourself.

Try specifying the full path to pdflatex:

--latex-engine=PATH/TO/pdflatex

If this works, then the problem is with paths. By default pandoc will
assume that pdflatex is in the path. Maybe you have set the texlive
path in such a way that it is visible in your shell but not to
processes pandoc spawns? When you look at your environment variables
in Control Center, can you see where the texlive path is set?

[stephenll]

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.
! LaTeX Error: File `article.cls' not found.

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

Enter file name:
! Emergency stop.
<read *>

l.2 \usepackage

c:\0\source\source\r>

[jgm]

Not sure what to suggest. You could try asking on the texlive mailing
list or the tex stack exchange. They might know what could cause
article.cls not to be found.

[stephenll]

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.

[YinglaiYang]

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

[timtylin]

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

[stephenll]

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.

[YinglaiYang]

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>*

[stephenll]

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.

[timtylin]

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

[YinglaiYang]

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

[timtylin]

@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.

[jgm]

Wow, great! Thanks for tracking that down. Do you have any
explanation of why MikTeX would still work, though? Does it
use a different kpathsea?

+++ Tim Lin [Feb 21 14 16:07 ]:

@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.

---

Reply to this email directly or view it on GitHub:
#1151 (comment)

[timtylin]

@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.

[YinglaiYang]

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

[stephenll]

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.

[jgm]

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.

[YinglaiYang]

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

[GongYiLiao]

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>

[timtylin]

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

[GongYiLiao]

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.

[timtylin]

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

[GongYiLiao]

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.
! LaTeX Error: File `article.cls' not found.

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

Enter file name:
! Emergency stop.
<read *>

l.2 \usepackage

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

[timtylin]

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

[timtylin]

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) ++)

[GongYiLiao]

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>

[timtylin]

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?

[GongYiLiao]

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

[timtylin]

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.

[timtylin]

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.

[timtylin]

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.

[GongYiLiao]

Thanks eVITAERC, that's really a great catch

[jgm]

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

[timtylin]

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.

[timtylin]

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.

[jgm]

Try the latest.

[timtylin]

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.

[timtylin]

Thanks John, for promptly resolving this.

[jgm]

+++ Tim Lin [Mar 10 14 16:32 ]:

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! I've merged your patch. Can you open a new issue for the
readFile laziness problem? And maybe you also have a solution to
suggest? Switching to a strict bytestring would not cause too
many problems -- to keep the API the same, we could simply convert
the result to a lazy bytestring.

[timtylin]

@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.

[GongYiLiao]

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

[YinglaiYang]

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.

[stephenll]

Is there a binary I can test? Thx

Stephen

On Mar 15, 2014, at 6:10 AM, Yinglai Yang [email protected] wrote:

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.).

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.

—
Reply to this email directly or view it on GitHub.

[jgm]

The issue about temp directories is known: see #1192.