Hi.
Under Settings, I only have one option, and it’s for selecting the UI language.
In the doc, about customization, it says we can open Advanced Settings under Settings.
I currently use pre-release 3.2.11951, 64-bit, installed version.
Thanks!
François
I think I have seen similar in the past on one occasion
I think it was due to a fulty file / location but am not certain
Can you try one of the portable ones from https://www.sumatrapdfreader.org/dailybuilds.html put it in a folder such as c:\simple\
that will firstly avoid any problems such as “ç” in your username installation
secondly it should provide a comparison and build a fresh SumatraPDF-settings.txt file in that folder which if all is well you can delete the installed SumatraPDF-settings.txt file and see if it rebuilds correctly
Thanks, I’ll try that and let you know.
My user name is just « fb » anyway.
Later,
François
There are 2 ways in which this can happen, both of which tell Sumatra to restrict disk access and therefore remove features that require such disk access.
Option 1: running Sumatra with -restrict flag
Option 2: using sumatrapdfrestrict.ini file and restricting disk access (https://www.sumatrapdfreader.org/docs/Configure-Sumatra-for-restricted-use.html)
Oh, thanks, I have created a sumatrapdfrestrict.ini file indeed to test a few things.
Is this file used even if the -restrict flag is not used on the command-line?
I thought it was working that way. (ini file ignored if -restrict is not used)
They are independent of each other.
-restrict restricts everything. It’s simple to use.
sumatrapdfrestrict.ini gives you more control over what to restrict but requires more work to set up.
Ok, thanks.
That was the culprit!
I’ll download the portable version to experiment with advanced settings.
I’d like to be able to use Sumatra in some kind of kiosk mode, but not full screen, with fixed size and position on the screen.
All the best,
François
Hello!,
i want to use SumatraPDF in restricted mode. I already configured the settings in “SumatraPDF-settings.txt”.
All is working great, until i start it from “C:\Program Files\TestApplication” - PDF is opening properly, but the settings are not loaded anymore.
I already tried changing user rights and working directory, but had no luck.
Can anyone confirm this problem?
Unclear of your question but if the settings are restricted you should not be able to make any further changes either by default or by changing this part to 0 (to see settings it needs to be 1) OR as described above if you specify restrict ALL using SumatraPDF.exe -restrict
; Whether SumatraPDF should save user preferences on exit.
; Needed for:
; * Changing settings
; * Favorites menu
; * Remembering recently opened files (includes Frequently Read page)
SavePreferences = 0
if you change it to 1 you need to restart SumatraPDF to see settings
I try to explain it more detailed to reproduce it:
I have two locations with Sumatra PDF portable.
Location 1: D:\Sumatra
Location 2: C:\Program Files\TestApplication\Sumatra
I created a settings file for example with “ShowMenubar=false” - This file exists on both locations. (same settings)
When i start it from Location 1 - Menubar is not visible
When i start it from Location 2 - Menubar is visible
It seems that the settings file is not loaded when the location of sumatra is under C:\Program Files…
Ok
when portable the settings are read from the exe folder but when installed settings are read from users appdata
If you have two copies and want to read same SumatraPDF-settings.txt you need to start with one folder for -appdata but perhaps have 2 copies of sumatrapdfrestrict.ini (but have not tested your combination)
D:\Sumatra\sumatrapdf.exe
“C:\Program Files\TestApplication\Sumatra\sumatrapdf.exe” -appdata “D:\Sumatra”
let us know if that helps
Thank you very much for the fast response!
Both version are portable. I tested it with the -appdata and now it seems to work.
I will do a extended test tomorrow.
As i understand, sumatra detects the program files folder and then automatically load the settings file from the %AppData% directory, right?
It is possible that the “program files” location causes the different behaviour (I am not the programmer, so suggest moving that copy to a different folder to check)
OR
it may also be windows using an older set of installation values from registry. (you could try to install then uninstall to see if it has any effect in removing that behavior)
Portable apps ideally shouldn’t be stored in %ProgramFiles%, because from Vista with UAC onwards only elevated apps (i.e. those running as admin) have write access to that location. Since Sumatra expects the settings file to be writeable, it’s quite possible it exhibits the behavior you’re describing.
Also note that if a non-elevated legacy app insists on writing to protected locations such as %ProgramFiles%, %ProgramData% and %SystemRoot%, UAC Virtualization might kick in and auto-redirect writes to %LocalAppData%\VirtualStore.
