Home / Visual indicator when refreshing a newly compiled PDF (from tex)?

It would be nice to have the whole PDF viewer flash black/white once or twice when the local PDF is refreshed. This is useful when fine-tuning a .tex document.

While the LaTeX compiler is compilng the PDF file, Sumatra knows about it and changes its window title. The window title will change back to normal when a new PDF file is compiled. Yet, staring at a small window title text is a bit demanding for my eyes.

If there isn’t an option, I’ll look to see if an Autohotkey script can help provide a visual cue once [Changes detected; refreshing] is removed from the title text.

Flicker would be disliked by some thus require further options to control

You should briefly see the refreshing symbol top right of page but the aim of SumatraPDF is to refresh and remove symbol as quick as possible so as to not continually need to show/explain why

Thanks for pointing to the refresh symbol. It is easier to find than the window title text. Can I make such symbol larger? (Or, is this yet another option to build afresh?)

I agree that flickering can be annoying to some.

I had a quick look through the code, but cant find a reference to what / where that symbol is generated, and if you do find it you would need to modify and compile from fresh. (it would not be easy to hex patch a symbol size change, though a good exe resource hacker might allow mods of colour, but then the authenticode will be broken)

Thanks a lot for your quick reply. I’ll look into some Autohotkey piece that monitors title-change, then. Will make the snippet available here once I get it to work.

I tried PixelNotifier – Skrommel's One Hour Software to see if it could be a basis to work from, but it raised more questions than answers.

It certainly can fill the screen in black if you so desire, but you could need to replace the message acknowledge button with a timeout
Biggest problems with one pixel monitoring was:- The target symbol is not fixed UNLESS you are working full-screen and the page is NOT zoomed away from the margins
My other question was:- How long is the refresh symbol active? A quick one page cycle may be missed by the polling time of the watcher…

I concluded that it is possible to monitor top LEFT title for change of first character to [ but reducing polling time would eat up CPU resources
SO if the trigger is recompile calling why not just on demand hook that event? very easy to inject a “shim” that gets the call in place of Pdflatex.exe etc and passes the call through to Pdflatex with a Tee (Y branch) to flag up the event in a msgbox.

If you think that too prone to affecting LaTeX or its editor, more simply if the LaTeX editor call is CLI (Not DDE) write an ahk script in place of SumatraPDF.exe that throws up the msg as it passes the same arguments through to the real SumatraPDF

Which could be combined with Making SumatraPDF accept /A page=numbers from Zotero - #8 by llinfeng

Here is a simple AutoHotKey script that “flashes” the newly compiled PDF document when [Changes detected; refreshing] is removed from the Sumatra window’s title text. It “flashes” the Sumatra window with a newly compiled PDF file as long as such Sumatra window exists. (If such a window is not at the forefront, the window will be activated to show on top of other windows.)

What follows is a standalone AHK script. It is meant to be first saved as a text file called something.ahk and executed through Autoohtkey. To install Autohotkey, please use this installer (link pointing to the official website).

; What this script does?
; 
; When compiling tex files locally with latexmk as an "auto-compiler", flash
; the output PDF when compilation completes.
; 
; Warning: this script is a quick draft. It may not cover all edge cases.

#Persistent
SetTitleMatchMode, 2

; The main loop, in AHK, things before the first "return" is called: auto-execution section
WinGetTitle, TitleLast, ahk_exe SumatraPDF.exe 
SetTimer, CheckChanged, 250 ;Check every quarter-second
return


CheckChanged:
WinGetTitle, Title, ahk_exe SumatraPDF.exe
If (Title <> TitleLast) and InStr(TitleLast, "[Changes detected; refreshing]")
; Here, only consider flashing things when "[Changes detected; refreshing]" is found in title
{
    ; Only to flash when a window no longer has "[Changes detected; refreshing]"
    If not WinExist("[Changes detected; refreshing]")
        ; Note, WinExist helps to look for all existing Sumatra windows.
    {
    ; Log for the current window ID, as ActiveSumatraID
    WinGet, ActiveSumatraID, ID, ahk_exe SumatraPDF.exe
    ; Check that ActiveSumatraID should be unique.
    ; msgbox, Stored the active window ID it is: %ActiveSumatraID%

    ; Lastly, this is the "flashing" piece: hide the window for a few
    ; milliseconds and activate it again.
    WinMinimize, ahk_id %ActiveSumatraID%
    sleep 20  ; Tune this number (in milliseconds) for a "slower flash" upon completion of the compiler.
    WinActivate, ahk_id %ActiveSumatraID%
    ; Caveat here: this will interrupt an "active typing session", buy shifting the "focus" to the Sumatra window. See the "ugly gray box" workaround below for a less distracting implementation.
    }
}
TitleLast := Title
return


; Credits: the monitor-title-change structure - https://autohotkey.com/board/topic/57043-command-to-watch-for-window-title-change/

Note, the “flash” action is implemented in a makeshift manner: when a Sumatra window changes its title text by removing the "[Changes detected; refreshing]" bit, the window is minimized first, and “activated” 20 milliseconds after.

Thanks for introducing PixelNotifier. I haven’t used it before.

RE: the refresh symbol - it is a bit shy and I cannot find it every time when the PDF document is refreshed. I guess it may not be a good indicator for recompling LaTeX documents.

Nevertheless, thanks to the persistence of Sumatra in handling its title text, we can “catch” the event where compilation is finished. When the PDF files is refreshed, the title text for Sumatra window will no longer have "[Changes detected; refreshing]". As long as this string stay constant for future version of Sumatra, this condition should be future-proof.

RE: the /A flag - I found a related post on Stata forum, as linked. I suppose some deep engineering is needed to solve such an issue. I wish Stata can listen to what Bert suggested in the post and add a new feature where it can appoint its own PDF reader. After all, Stata is sold at a hefty price for a rather restricting license.
For now, on my main computer, I opt to use Adobe Acrobat as the default PDF viewer and launch Sumatra through my text editor (gvim + vimtex).

Here goes an updated AHK script: it draws an ugly gray box when compilation is finished. The ugly gray box will go away after 1 second.

; What this script does?
; 
; When compiling tex files locally with latexmk as an "auto-compiler", flash
; the output PDF when compilation completes.
; 
; Warning: this script is a quick draft. It may not cover all edge cases.

#Persistent
SetTitleMatchMode, 2

; The main loop, in AHK, things before the first "return" is called: auto-execution section
WinGetTitle, TitleLast, ahk_exe SumatraPDF.exe 
SetTimer, CheckChanged, 250 ;Check every quarter-second
return


CheckChanged:
WinGetTitle, Title, ahk_exe SumatraPDF.exe
If (Title <> TitleLast) and InStr(TitleLast, "[Changes detected; refreshing]")
; Here, only consider flashing things when "[Changes detected; refreshing]" is found in title
{
    {
        SplashTextOn , 1000 , 1000 , Splash, Done compiling
        sleep 1000
        SplashTextOff
    }
}
TitleLast := Title
return

; Credits: the monitor-title-change structure - https://autohotkey.com/board/topic/57043-command-to-watch-for-window-title-change/

I would suggest a simpler variant

1. class avoids issues with exe name (that caused me problems as the .exe i tested is not SumatraPDF)
2. simplify the search to fewer chars and only at run time
3. bump the message into compile down time not once it is completed

SetTitleMatchMode, 2
; The main loop, in AHK, things before the first "return" is called: auto-execution section
SetTimer, CheckChanged, 250 ;Check every quarter-second
return
CheckChanged:
WinGetTitle, Title, ahk_class SUMATRA_PDF_FRAME
If InStr(Title, "[Changes")
; Here, only consider flashing things when "[Changes detected; refreshing]" is found in title
{
        SplashTextOn , 500 , 500 , Splash, Compiling in progress
        sleep 2000
        SplashTextOff
}
return

Thanks for the correction for the ahk_class piece. I was not aware of other variants of the executable. Though, I don’t agree with oversimplifying the repeated search structure.

I may have an old computer? For me, Sumatra may hang with a "[Changes detected; refreshing]" title-text for a couple of seconds, up to 10 seconds or so. This is mostly the compiler refreshing something at the backend. (I have an i7-6700K CPU and the compiler is MikTeX for Windows. The .tex document is not that long, but sizable enough.) This makes it necessary to only show the visual cue when the compilation actually finishes.

Anyways, for older computers that won’t finish compiling in “real-time”, the recurrent “title-search/match” via AHK is somehow needed to reveal the ugly gray box upon compilation is done properly.

@GitHubRulesOK Will there be future changes to when "[Changes detected; refreshing]" is introduced and removed to the title-text?

A sidenote on using ahk_exe SumatraPDF.exe: I use Sumatra mainly when compiling .tex files, where I use gvim.exe as the editor. It took quite a lot of tinkering, but the conclusion is that I am forever tied to the 32-bit version for both gvim.exe and SumatraPDF.exe. This is for achieving full forward and backward search functionalities using vimtex (a plugin for gvim.exe).

The choice of when message appears is entirely up to your preference. My suggestion would not work for all cases.

[Changes detected has been around for a while and may be different in each language so in french its [Modifications or similar,
Only the [ is fairly consistent That text is not shown if tabs are active so depends on use tabs set off or false

Usage is thus very specific to each user and could be removed or changed at any time.

64bit SumatraPDF should be running independent when using CLI calls from any 32 bit editor the EXCEPTION would be when using DDE or Pipes to drive SumatraPDF (one reason I advocate CLI over DDE) but looking at the comments it may be a different issue with gvim
Again using a shim between them could possibly help

1. There is no need for any call to include -reuse-instance (that is so last century and should be permanent in advanced settings, I do use it heavily in scripts where the user setting is unknown, but it should be depreciated as much as is practical)
2. The same with -inverse-search just set it once, unless you are using variable locations/editors.
3. placing SumatraPDF into paths is not needed if an absolute (or well constructed relative) location is used
4. any residual problem is then down to UAC elevated rights and is a bugger in Windows 10