Some people want a way to compare two files side-by-side.
To that effect I’ve added 2 features:
File / New Window menu (with Ctrl-n shortcut) which opens a new window. This is like Chrome browserCtrl-Shift-N opens current file in a new window, showing the same file in 2 windowsThose features are available for testing in latest pre-release:
https://www.sumatrapdfreader.org/prerelease.html
Thank you so much. I always dreamed of this feature in a reader. I downloaded your prereleased version, but couldn’t install because of the message “is not a valid win32 application”. What’s wrong?
Which version of Windows are you using?
Pre-release doesn’t support XP.
Yes, XP.
I see… But I hope your main official version of it will support XP too? Or not?
Is it possible that this new release will also lift the 10MB file-size limit for automatic refresh of SumatraPDF when running PDFTeXify using WinEdt?
I am in the final stages of editing my new mathematics book for Princeton University Press, and even the individual parts of the book are larger than 10MB, due to the very large number of diagrams. Thus, each time I run PDFTeXify, I must manually close the PDF file and then reopen it in order to see the changes I have made.
It would be SO much nicer to have the SumatraPDF window update automatically, as it does perfectly for smaller files.
Thanks for listening!
I’ve increased the limit from 10 MB to 32 MB.
Special-casing for automatic refresh is not easy.
@kjk the refresh is usually applied by the editor (texifier) rewriting the file so no need for “auto refresh” the 10 MB lock was the blocker for a “rewrite” of each sub file (which gets bigger over time)
THANK YOU SO MUCH for increasing the file-size limit from 10 MB to 32 MB!
I just installed the pre-release 3.2 and now it DOES automatically refresh after each run of PDFTeXify on a TeX file that produces a 25 MB PDF output. This is going to save me so much time!
However, I did initially encounter the following issue, which might be useful to share with other users of the WinEdt-SumatraPDF combination.
[FYI: I am running 32-bit Windows 10 Pro (version 1903) under Parallels 15.1.2 on an iMac.]
INITIAL PROBLEM:
The first time I ran PDFTeXify from WinEdt, (with SumatraPDF NOT initially open) SumatraPDF opened automatically and displayed my PDF file. At this point SumatraPDF seemed stable, and I was able to navigate around the PDF, inverse-search took me back to the correct place in WinEdt, etc.
If I then made a change to the TeX files and ran PDFTeXify again, SumatraPDF automatically displayed the UPDATED PDF [which of course it did NOT do in 3.1]. However, after perhaps 3 seconds, SumatraPDF crashed (or at least the window closed). This was completely repeatable.
SOLUTION:
In Advanced Options, I changed the (default?) “false” to “true”:
ReuseInstance = true
Now I can make change after change, and each run of PDFTeXify automatically causes SumatraPDF to refresh and NOT crash.
In latest version, when a crash happens, you can press ‘Cancel’ and see a crash report.
If you report the issue at https://github.com/sumatrapdfreader/sumatrapdf/issues and attach this crash report, I’m likely to fix the underlying issue.
Yes reuse-instance needs to be true (with tabs enabled) for current LaTeX editors
It is a legacy requirement from before tabs were introduced
In effect it means that each subfile will be channelled to re-use its own tab without opening multiple instances (windows)
KJK:
Well, I’m baffled. After making the change “ReuseInstance = true”, SumatraPDF successfully updated my 25 MB file after each PDFTeXify cycle (launched from WinEdt). It worked perfectly for a couple of days, involving many, many LaTeX edits and PDFTeXify cycles.
But, yesterday, still working on the same file, and without changing any settings, SumatraPDF resumed crashing about 2 seconds after the second PDFTeXify cycle, even if no changes were made to the original TeX file. It’s still perfectly stable if I only run PDFTeXify once, thereby opening up the file in SumatraPDF. But the second cycle crashes it.
The only thing that has changed (so far as I know) is that the file has grown very slightly as I have continued to finish the chapter I’m writing, but it’s still “only” 25.3 MB, well below the new 32 MB limit you have set.
Please can you spell out very explicitly [for a non-programming mathematician] how I can generate crash reports for you to study? [I don’t understand what you mean when you say “press Cancel”. Where? How? When?]
I have updated to the latest 3.2 pre-release, and it crashes, too, I’m afraid.
Update: PROBLEM SOLVED (but mystery remains)
I verified that file size had nothing to do with the crashes: it happened on the second PDFTeXify cycle with even a 3 MB file.
SOLUTION: The change I just made was in the
WinEdt settings: Options —> Execution Modes… —> PDFTeXify —> UNCHECK “Start Viewer”.
I now have to manually open SumatraPDF and then the PDF file, but each new PDFTeXify cycle is now updating SumatraPDF without it crashing.
The mystery of what’s actually going on remains, but at least (selfishly) I am back in business!
I would still like to really get to the bottom of this, because of these two downsides to not having WinEdt launch SumatraPDF:
I have to manually switch the focus to SumatraPDF after each PDFTeXify cycle.
The PDF does not open at the place I was editing, because “forward search” is a sub-option of the (now-disabled) “Start Viewer” option.
Update of update:
SOURCE OF CRASHING FOUND?
To overcome the two problems (1) and (2) above, I tried doing a manual “Forward Search” using
WinEdt: Shift + F8
This immediately caused SumatraPDF to crash!
[Of course this does nothing to explain why everything was working perfectly for three days with “Start Viewer” and “forward search” enabled!]
KJK: Thank you for explaining what you meant by “press cancel”. However, no such crash-report window appears after my “crashes”, so perhaps they are not crashes after all. As I have explained, I know nothing about programming, but could it be that WinEdt’s “Start Viewer” and/or “forward search” is being received by SumatraPDF as a (lawful) command for SumatraPDF to Close/Exit?
Recently I made it very easy to report crashes so please do.
Press ‘Cancel’ in a message box that shows when crash happens, this will open a notepad with crash report, post it at https://gist.github.com/ and create a new bug report at https://github.com/sumatrapdfreader/sumatrapdf/issues/new linking to that.
That way I’m likely to fix the problem.
@Tantris winedt 10 will usually automatically set the sumatrapdf configuration
I have not got a copy in front of me to check but it is possible that the call which should now be via WinEdt command line calling rather than the historic DDE method has been disturbed in the editor.
Is it possible you have more than one version on the machine?
I have to presume you have checked with WinEdt support that the call is configured correctly.
Thank you, but it now seems that the issue had to do with SumatraPDF’s interaction with WinEdt, rather than with WinEdt itself.
With each new pre-release version of 3.2 I have tried re-enabling in WinEdt the “Start Viewer” option of PDFTeXify, and each time the problem has instantly returned: SumatraPDF closes on the second run of PDFTeXify.
But today I installed 3.2.11973 and the problem is GONE!
I have re-enabled “Start Viewer” and “Forward Search” and SumatraPDF is auto-updating my 25 MB file—without my having to manually close and reopen it, as I had to do in 3.1—taking me to the correct place in the PDF, and NOT closing. I have been editing the file for about an hour now, and everything is working perfectly.
Whew!
[At least for now.]
Thanks for the feedback it may be worth noting that for the past few weeks there may have been a related problem with -reuse-instance
I have always advocated that should no longer be used in the winedt config as it has was replaced by the reuseinstance = true setting in the advanced options file a long time ago.
@Tantris The reason for that was that DDE commands (which is how WinEdt talks to sumatra) were busted for a while and I just fixed that.
@Tantris since you are using LaTeX if using eps for images you may want to update to 11974 due to a GS problem in 11973
@kjk AFAIK WinEdt specifically avoids DDE at least it advocated NOT using it as described in their early version 10 readme’s, this is in some ways related to other file handling limits possibly including synctex
@kjk and @GitHubRulesOK:
Before 11973 solved my problem, I reached out for help to the author of WinEdt, Alex Simonic, and he very kindly responded and told me the following, which should make a lot more sense to you two than it does to a know-nothing, non-programmer like me!
WinEdt does not use DDE with Sumatra. WinEdt does not instruct SumatraPDF to close any document or itself. Command lines for preview and forward search are:
Run(’%$(!“PDF-View”); -reuse-instance “%P%N.pdf” '+>
'-inverse-search "\"%B\WinEdt.exe\" -C=\"%!W\" \"[Open(|%%f|);SelPar(%%l,8);]\""');Run(’%$(“PDF-View”); -reuse-instance “%P%N.pdf” '+>
'-forward-search "%f" %!l '+> '-inverse-search "\"%B\WinEdt.exe\" -C=\"%!W\" \"[Open(|%%f|);SelPar(%%l,8);]\""');Where %$(“PDF-View”); translates to the name of the SumatraPDF executable as displayed in the Execution Modes. Something like:
“C:\Program Files\SumatraPDF\SumatraPDF.exe”
Make sure that this is actually a proper executable for 3.2 (in case you have two versions of SumatraPDF installed).
The option -reuse-instance could be removed if you have properly configured Sumatra and so could -inverse-search if you specify the command directly in SumatraPDF options. Simplified WinEdt commands could then be:
Run(’%$(!“PDF-View”); “%P%N.pdf”’);
Run(’%$(“PDF-View”); “%P%N.pdf” -forward-search “%f” %!l’);
But there should be no problem with extra parameters (even if they are simply ignored).
@Tantris
That confirms my experience that WinEdt no longer endorses DDE and that all those -inverse-search commands add both overhead time to the call and a risk of failure they are redundant
Only -forward-search is needed
There are several ways to build the ;SelPar section but note the ,8) is a colour so you can customise that bit so you can try 6 or 10 to customise.