search

sumatrapdfreader / sumatrapdf

SumatraPDF reader
http://www.sumatrapdfreader.org
GNU General Public License v3.0
13.41k stars 1.7k forks source link

Autorefresh not working with XeLaTeX in latest SumatraPDF(3.5.2) #4523

Closed inkfin closed 1 week ago

inkfin commented 2 weeks ago

SumatraPDF version Version: 3.5.2 (latest stable, not pre-release)

Describe the bug

I really like SumatraPDF for its speed and simplicity, but I’ve noticed an issue with autorefresh when using XeLaTeX. I use Neovim with vimtex, which updates the PDF correctly, but SumatraPDF doesn’t refresh automatically. I’ve checked my settings, and everything seems fine, but the issue persists.

The log doesn’t show autorefresh events (except when I manually reload), so it seems that SumatraPDF isn’t detecting the updates properly when using XeLaTeX. I’ve attached the log for reference.

Details

``` ReadRegStrTemp(HKEY_LOCAL_MACHINE, Software\Microsoft\Windows\CurrentVersion\Uninstall\SumatraPDF, InstallLocation) => '(null)' ReadRegStrTemp(HKEY_CURRENT_USER, Software\Microsoft\Windows\CurrentVersion\Uninstall\SumatraPDF, InstallLocation) => '(null)' InstallCrashHandler crashDumpPath: '$HOME\scoop\apps\sumatrapdf\current\crashinfo\sumatrapdfcrash.dmp' crashFilePath: '$HOME\scoop\apps\sumatrapdf\current\crashinfo\sumatrapdfcrash.txt' symDir: '$HOME\scoop\apps\sumatrapdf\current\crashinfo' Starting SumatraPDF 3.5.2, GetCommandLineW(): "$HOME\scoop\apps\sumatrapdf\current\SumatraPDF.exe" -reuse-instance -forward-search "path_to_my_pdf\main.tex" 26 "path_to_my_pdf/main.pdf" -inverse-search "wt -w 0 \"\" nvim --headless -c \"VimtexInverseSearch %l '%f'\"" LoadSettings() took 0.70 ms ParseTranslationsTxt: 17632 lines, nStrings: 372 RestoreTabOnStartup: state->filePath: 'path_to_my_pdf\main.pdf' CreateControllerForEngineOrFile: 'path_to_my_pdf\main.pdf', 1 pages LoadDocument: 1.04 ms, 1 pages for 'path_to_my_pdf\main.pdf' DisplayModel::BuildPagesInfo started DisplayModel::BuildPagesInfo took 0.00 ms CanViewWithKnownExternalViewer cmd: 294, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 295, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 296, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 297, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 298, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 299, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 300, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 301, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 302, !pos CanViewWithKnownExternalViewer cmd: 303, !ev || ev->exeFullPath == nullptr StartMonitoringDirForChangesAPC() path_to_my_pdf TabsSelect: tabIndex: 1, nTabs: 2 ReloadDocument: path_to_my_pdf\main.pdf, auto refresh: 0 CreateControllerForEngineOrFile: 'path_to_my_pdf\main.pdf', 1 pages DisplayModel::BuildPagesInfo started DisplayModel::BuildPagesInfo took 0.00 ms CanViewWithKnownExternalViewer cmd: 294, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 295, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 296, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 297, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 298, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 299, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 300, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 301, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 302, !pos CanViewWithKnownExternalViewer cmd: 303, !ev || ev->exeFullPath == nullptr StartMonitoringDirForChangesAPC() $HOME\scoop\apps\sumatrapdf\current ReadDirectoryChangesNotification: FILE_ACTION_ADDED '4913' ReadDirectoryChangesNotification: FILE_ACTION_REMOVED '4913' ReadDirectoryChangesNotification: FILE_ACTION_REMOVED 'main.tex' ReadDirectoryChangesNotification: FILE_ACTION_ADDED 'main.tex' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.tex' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.log' ReadDirectoryChangesNotification: FILE_ACTION_ADDED 'main.synctex(busy)' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.aux' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.out' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.bcf' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.xdv' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.aux' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.bcf' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.run.xml' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.run.xml' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.xdv' ReadDirectoryChangesNotification: FILE_ACTION_REMOVED 'main.synctex.gz' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.synctex(busy)' ReadDirectoryChangesNotification: FILE_ACTION_RENAMED_OLD_NAME 'main.synctex(busy)' ReadDirectoryChangesNotification: FILE_ACTION_RENAMED_NEW_NAME 'main.synctex.gz' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.log' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.fls' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.fls' ReadDirectoryChangesNotification: FILE_ACTION_REMOVED 'main.pdf' ReadDirectoryChangesNotification: FILE_ACTION_ADDED 'main.pdf' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.fdb_latexmk' ReadDirectoryChangesNotification: FILE_ACTION_MODIFIED 'main.fdb_latexmk' ReloadDocument: path_to_my_pdf\main.pdf, auto refresh: 0 CreateControllerForEngineOrFile: 'path_to_my_pdf\main.pdf', 1 pages DisplayModel::BuildPagesInfo started DisplayModel::BuildPagesInfo took 0.00 ms CanViewWithKnownExternalViewer cmd: 294, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 295, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 296, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 297, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 298, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 299, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 300, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 301, !ev || ev->exeFullPath == nullptr CanViewWithKnownExternalViewer cmd: 302, !pos CanViewWithKnownExternalViewer cmd: 303, !ev || ev->exeFullPath == nullptr ```

To Reproduce

Steps to reproduce the behavior:

Expected behavior

SumatraPDF should automatically refresh when the PDF is recompiled.

Screenshots

N/A

Additional context

I’ve tested with pdflatex and pandoc, and autorefresh works as expected. Related issues:

SumatraPDF issue #3932

vimtex issue #2830

Thank you for this great software!

GitHubRulesOK commented 2 weeks ago

ouch

SumatraPDF reload depend primarily on two key related points.

One is that a compiling PDF file must usually be under 32 MB so large files will usually be locked against use in TeX of any flavour, and in such case only a command line "PDF non-locked" Foxit may function for that scenario.

The second is more likely your issue as SumatraPDF depends on a signal from the local file system , thus usually a problem on drives that are not simply A: to Z:. Synchronised virtual drives like c:\users\desktop\onedrive will be problematic. even a mapped served drive may not always work due to networking.

You seem to be using WSL ?? thus may not be a conventional Windows File Allocation Table / file system feedback ?

"$HOME\scoop\apps\sumatrapdf\current\SumatraPDF.exe" -reuse-instance -forward-search "path_to_my_pdf\main.tex" 26 "path_to_my_pdf/main.pdf" -inverse-search "wt -w 0 \"\" nvim --headless -c \"VimtexInverseSearch %l '%f'\""

So ensure the PDF during compilation is in a Windows Local NTFS mounted drive that is not subject to comms restrictions.

Side comment is that there should be no need for BOTH -forward-search and -inverse-search (nor any need for -reuse-instance as that should in such cases always be advanced settings true.)

inkfin commented 2 weeks ago

Thanks for your reply! Thank you for your quick response!

I am working in a Windows environment, using a local directory. It’s not WSL, nor is it on OneDrive or any other cloud storage.

The file is quite small, only a few KB, so file size shouldn’t be the issue.

As for forwardsearch and inversesearch, those are part of my vimtex setup, and they are working correctly, so I assume they shouldn’t affect this issue, right?

I would appreciate any further guidance you could provide. Thanks again for your help!

GitHubRulesOK commented 2 weeks ago

I would ensure SumatraPDF (Official Standalone, probably latest current pre-release) is in a Windows conventional area since although you are not using DDE for calling the exe expects to be in a conventional Windows file system calling a conventionally accessible PDF.

There have been several changes to syntex in more recent versions so another possibility just for testing is revert to an earlier version such as 3.1 portable to ensure it is not a recent change having effect. If that works then try a more recent version to find any point of breakage.

HOWEVER the synctex system takes account of the compiled file store system and thus without the synctex file and precisely same time PDF output. It is hard to guess where the inverse call is directed to goto.

The point about removing -inverse-search is it only needs to be stored in the settings file once (a batch file for 1st time portable single command call will do that). So if repeatedly called every time it adds to delay and chatter in forming the response. Should not really be an issue but is recommended by me as a result of testing dozens of different editors! My logic is that the settings related commands force extra settings file access for writing beyond just the PDF filename which is then the only settings file variable from one call to the next and thus reasonably static for that session.

inkfin commented 2 weeks ago

Regarding the installation location: I installed SumatraPDF using Scoop (for those unfamiliar, Scoop is a package manager for Windows that centralizes installations in the $HOME/scoop directory to manage paths uniformly. It uses shims to redirect executable paths and automatically registers command-line commands and updates the registry). In my testing, SumatraPDF autorefresh works fine when using vimtex with pdflatex or pandoc, so I don’t think the issue is related to the installation path.

I have tested versions 3.5.0 to 3.5.2 locally, but I will try older versions as you suggested.

I also checked, and the synctex file does get updated along with the PDF, so it doesn’t seem like the issue is there either.

Regarding the inverse search configuration: thanks for the advice! I’ll update my setup accordingly.

GitHubRulesOK commented 2 weeks ago

The key to SumatraPDF calling the editor is the contents of the synctex embeded filename line numbers or their related area variables so perhaps ensure the files are set to non compressed =1 or am I forgetful in very old age ? that was wrong it should be -synctex=-1 (do not zip)

Then file compare for return paths in each case, so from PDFTeX and XeTeX for any differences

Hmmm reading my old "out of date" notes Linux editors got a mention as potentially a synctex issue but it was WSL that interfered. https://github.com/GitHubRulesOK/MyNotes/raw/master/AppNotes/SumatraPDF/LATeX%20and%20Reverse-Search.pdf

Mixing a Linux ELF editor (running in Windows 10 WSL) with SumatraPDF running in native windows mode may cause problems with the naming of the volumes where the files are to be found.

And confusingly I then say "if so, use [R]eload key. ", Which is only for the missing PDF autoupdate. BUT that does not itself say there would be any difference between 2 Synctex files from same editor !?

GitHubRulesOK commented 2 weeks ago

So in summary

You can easily get feedback by temporarily set Latex option to cmd.exe /k echo "%f" "%l" but the return path in both cases should be the same ? and not affect the prior step of auto-refresh.

Thus it is ONLY the writing a PDF filename that is different using XeLaTeX compiler ! I thus have to guess there is an issue with the way XeLaTeX builds the PDF compared to PDFLaTeX

Perhaps try a shim between XeLaTeX output calling forward to see if a windows cmd /r start "" sumatrapdf.exe -forward-search options makes a difference ?

inkfin commented 2 weeks ago

I’ve tested two simple LaTeX templates with the only difference being the TS-program directive at the first line: %!TEX TS-program = pdflatex and %!TEX TS-program = xelatex. I kept my editor and config the same, with everything else unchanged. However, the problem persists with XeLaTeX, and the resulting PDFs are quite different.

The autorefresh issue continues to occur specifically when using XeLaTeX, while it works perfectly fine with PDFLaTeX.

GitHubRulesOK commented 2 weeks ago

Sadly dont have time currently to set a working Latex system However have to "ASSume" there is something different in the way XeTeX is file writing compared to others

From your link

If I use latexmk to compile my tex files, then SumatraPDF doesn't refresh automatically

Best suggestion is when caling the XeLaTeX compiler that it be wrapped in a cmd file so calling the cmd with 2 sequential invocations to attempt a separation in file access timing and notification. There were other comments there about how XeLaTeX may build different but dismissed without fuller explanation?

Latexmk or  XeLateX "%1" "%~2" blah blah
SumatraPDF -forward-search blah "%2" (or whatever the needed first line output is)
mathiasleroy commented 2 weeks ago

I have the same issue compiling the pdf with rmarkdown (output: pdf_document) render("report.Rmd", output_file = "out/report.pdf") which uses LaTeX

kjk commented 1 week ago

This should be fixed in latest pre-release

Per your logs:

ReadDirectoryChangesNotification: FILE_ACTION_ADDED 'main.pdf'

3.5.2 doesn't handle FILE_ACTION_ADDED so we don't consider main.pdf as changed hence it doesn't reload.

I added FILE_ACTION_ADDED handling in: https://github.com/sumatrapdfreader/sumatrapdf/commit/0283d24b77beec3ab7d05e59a5b690cd17122df6

That should fix @inkfin issue.

I don't know if it fixes the issue seen by others. Try latest pre-release and if there is an issue, open a bug and provide detailed information like @inkfin, including the log.

inkfin commented 1 week ago

Thank you for the quick fix!

I’ve tested the latest pre-release, and the autorefresh with XeLaTeX is now working perfectly. I really appreciate your prompt response and all the help.

Thanks again for your hard work!