Forum moved here!

Home / Postscript filesize limitations



i am having issues opening postscript files with SumatraPDF.

I have installed Sumatra with
and postscript with

Whenever i open a .ps file that is bigger than 20MB i get an error saying “error loading \filepath\”

I have tried to open several different files from different sources that are up to 200MB and i always get that error.

Maybe it helps to mention that when opening those files throught Powershell with "sumatrapdf.exe -console -stress-test ‘’ " the console output is just the file path and SumatraPDF says “Stress test complete, rendered 0 files in 10 seconds”

Files that are about 10-15 MB are opening without a problem.

Does SumatraPDF have any filesize limitations?

Thanks for your help in advance.


There is only limit to generally worry about that is related to locking the file during edits such as those done by LaTeX editors
Up to current 3.1.2 release smaller work files up to about 10 Mb are not “locked and loaded”, in current pre-release it should now be 32 Mb.

Thus neither are around 20 Mb
I have no idea how chocolatey construct or run their builds but it could be the way your workflow is running that such a limit could be interfering

Without sample PS file that is causing you issue I can’t test against official builds
What are the methods of running , simply viewing an AI Eps or PS file should not usually be a problem.



I can confirm larger files are not rendering in 3.1.2 and current pre-release

@ kjk
As described above a PS file of about 33Mb will display at least the first page in IrfanView using GS 9.5 x64bit (Irfanview does not generally work with 32bit on x64)
Such a file will not display in 3.1.2 (or current pre-release) even when smaller ones can

I have raised this as an issue at


@GitHubRulesOK thanks alot for your reply!


The way .ps files work in sumatra is: we use GhostScript to convert the file to .pdf using a command like: gswin32c -q -dSAFER -dNOPAUSE -dBATCH -dEPSCrop -sOutputFile="foo.pdf" -sDEVICE=pdfwrite -f ""

(or gswin64c).

My wild guess is that the version of GhostScript you have installed limits the conversion capability to this threshold so Sumatra can’t open the file because GhostScript refuses to convert it to PDF.

One way to verify that theory would be to try to run the command above on a large .ps file and see what happens.


@kjk the GS command appears to work at CLI so I consider this is more likely a user rights issue so will continue further discussion in github


It’s possible that different ghostscript installation have different limits. Maybe the one from is different than the one that you have.


@kjk my personal view its the bigger the file the longer the delay to build and sumatraPDF is prematurely erroring. see github observation.


are you able to measure time taken by SumatraPDF to show error and time taken by your GS to process your file with a command similar to the one above
alternatively provide a link to a similar file


@GitHubRulesOK It takes about 10 seconds to display the error after opening a big .ps file.

@kjk i tried gswin64c -q -dSAFER -dNOPAUSE -dBATCH -dEPSCrop -sOutputFile="foo.pdf" -sDEVICE=pdfwrite -f "" and the was converted into foo.pdf


yes the error time is a max 10000 milli-seconds so Sumatra will time out then with error

more important is if you run the GS command from prompt how long before prompt returns
In my case with a larger 30mb file it was a little more than the 10 seconds so conversion was never completed in time for SumatraPDF to accept it


I increased the timeout from 10 sec to 20 sec.
Let me know if you have documents that take even more than that. I can increase it even more.

Also, as a last resort, you can set SUMATRAPDF_NO_GHOSTSCRIPT_TIMEOUT env variable to disable timeout completely.


@GitHubRulesOK i ran the GS command from cmd with a 90MB file. The command prompt returned after 13-14 seconds.

@kjk Setting the environment variable SUMATRAPDF_NO_GHOSTSCRIPT_TIMEOUT to 1 and Enabled didnt work since the error message kept showing up. Is it possible that this functionality is not available with the current build?

Then i tried to compile it with Visual Studio 2019 on Windows 10 by opening vs2019/SumatraPDF.sln using the x64 option but i kept getting the error (code E1696): —The File “Source” cant be opened: “zconf.h” —

Thanks for your help in advance


the latest build dailybuilds with new 20second timeout worked for me at 33 Mb around the 10 seconds and nearer 40MB around 14 seconds so on my kit 60 Mb may be my limit
However if your 90Mb is under 20 secs then for you only 100+ Mb may need the no timeout set.

The Env var I have not tested but am waiting for a 300Mb file to download for test
If Env var is supposed to be set system wide I will firstly try to set it permanently in windows system then reboot to ensure it is available at run time


It was a very recent change so make sure you’re using daily build

Also, setting env variables in windows is tricky and there are different ways to do it. Not knowing what you did exactly leaves the possibility of user error.


Ok I got success with 300 Mb ps file after about 8 minutes (much too long a time frame) but this is a 1/2 tread coal powered laptop so in SumatraPDF I save as a 30Mb PDF and now it loads in 5 seconds wow! no waiting next time.

As mentioned above I set the no_timeout in system settings and checked it is always there after boot


I downloaded SumatraPDF-prerelease-11986-64-install.exe and i was able to open a 210MB .ps file within 30-35 seconds without setting an environment variable.

Convertion from ps into pdf took about 17 seconds and then it started loading.

Thanks again @GitHubRulesOK @kjk


Thanks for the feedback, note that if you save as within sumatraPDF you can change the save format from ps to pdf then the GS file is saved
so the may become a 20mb.pdf which is much much faster to re-load in the future, the reduction in size is totally down to the GS defaults so there is no way sumatraPDF influences the quality, however my experience is the PDF files appear just as good for reading but quicker


@kjk I’m still using the pre-release version where you increased the timeout from 10 to 20 seconds. Sometimes files take longer to load and i still get an error. Could you maybe increase the timeout to 40 seconds?

I also noticed that the pre-release version does not install with silent arguments like " /S ". Would it be easy to add this functionality?


the /s should be working HOWEVER if you are trying to overwrite the previous version then you will not see the error message that there are blockers such as the previewer needs to be shut down etc.

@kjk rather than the simple SUMATRAPDF_NO_GHOSTSCRIPT_TIMEOUT=true
perhaps have it a number of seconds(=x1000milisecs) up to a reasonable limit in my case it was about 10 mins = 600 seconds and / OR perhaps have the value more accessible in settings.txt