! => Fatal error occurred, no output PDF file produced! *** (job aborted, file error in nonstop mode) LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 2. LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 2. LaTeX Font Info: Checking defaults for TS1/cmr/m/n on input line 2. LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 2. LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 2. LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 2. LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 2. ("C:\Program Files\MiKTeX\tex/latex/base\bk10.clo"įile: bk10.clo 0 v1.4l Standard LaTeX file (size Files\MiKTeX\tex/latex/l3backend\f"įile: f 元 backend support: PDF mode ("C:\Program Files\MiKTeX\tex/latex/base\book.cls"ĭocument Class: book 0 v1.4l Standard LaTeX document class In the meantime, the fix is to, well, stick to file and directory names that have no spaces in them.This is pdfTeX, Version 3.14159265-2.6-1.40.21 (MiKTeX 20.6.29) (preloaded format=pdflatex 2020.7.14) 13:14 I hope a future release of MikTeX will resolve the issue, because I do occasionally use spaces in file names. If anyone has experience with this, please let me know in the Comments.īottom line: this is a Windows- and MikTeX-specific, back-end problem that unfortunately I cannot fix. Since MacTeX generates correct sync info with or without spaces in file names, I suspect that TeXlive under Windows does, too. One way to test this would be to run the TeXlive distribution on Windows it, too, includes synctex, and the standard Mac TeX distribution, aptly named MacTeX, is essentially just TeXlive compiled under OSX, with some additional apps. The synctex code is largely cross-platform, so the problem must be in the way MikTeX incorporates or adapts it on Windows. However, on Mac OSX, synchronization works fine with file names that include spaces. Now, in principle, the problem may be with the synctex library itself. Incidentally, the TeXworks test exonerates SumatraPDF, because TeXworks and SumatraPDF use different libraries to render PDF files (although they both use synctex for backward and forward searches). Google says it fails with WinEdt, TeXmaker and other editors as well. I double-checked this two ways: first, if there are no spaces in the path name, ST2+SumatraPDF work just fine second, if there is a space in the file name, then synchronization also fails in TeXworks. Unfortunately, if the LaTeX source file name (more precisely, its full path name) contains a space, the generated sync information is incorrect. Like many other TeX distros, MikTeX relies on a library called “synctex” to generate the synchronization information (the “.synctex.gz” files that get created whenever you pass the “-synctex=1” option to pdflatex). Rather, the failure of synchronization is a well-known issue that affects the (otherwise excellent) MikTeX distribution. Still, one can never rule out new bugs with updates to both ST2 and SumatraPDF this is the reason why I occasionally take a trip to the Win7 side, as I did today.Įnds up the problem is not with ST2 or with the LaTeXTools plugin: the sync infrastructure is still solid on Win7. This was both surprising and worrisome: I have been developing the LaTeXTools plugin for ST2 under Mac OSX lately, but my focus has been on cross-platform features I assumed that the sync infrastructure, which is very platform-specific, was in a stable state by now. jumping from the LaTeX source to the PDF output and conversely) kept failing with the particular file I was working on. After a long hiatus, I fired up a Parallels 7 virtual machine and decided to use SumatraPDF and Sublime Text 2 under Win7 for my day’s work (which is, as usual, LaTeX-heavy). In three words: it doesn’t work (does “doesn’t” count as 1 or 2 words though?).Ī bit more detail.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |