Can't save annotations in >32 MB files

[GitHubRulesOK]

retesting to close 1984 (ironically a big brother reference) I hit a potential limitation with large files over 32MB

I had saved work in progress and was checking that I could add more to same file

[kjk]

Must be file locking. If many people report this, will bump the threshold. With 4 GB computers, 32 MB isn't much in the first place.

Alternatively, I could try to re-arrange the code to close the file (destroy the engine) and then save, since the file would be re-loaded afterwards anyway, but this probably isn't easy in current code.

[GitHubRulesOK]

Close and reload sounds like could address the "save as and reopen" in same tab but guess that sounds like a lot of refactoring (I was partly surprised at how many new lines some seemingly small changes required to be stable)

[wdscxsj]

If many people report this, will bump the threshold. With 4 GB computers, 32 MB isn't much in the first place.

I often find the 32 MB limit too small. Personally an important use case is to "share views" with Acrobat or something else. Is it possible to make the threshold configurable?

[GitHubRulesOK]

@wdscxsj I dont think SumatraPDF and Acrobat should "share views" The reason Foxit and Acrobat et all lock PDF against secondary viewers is to avoid corruption when contents are changing, My use of 2 editors at the same time such as Edge and SumatraPDF is based on using other combinations of dual editing, so it is essential you save in one before manipulate the other.

If SumatraPDF triggers a mod in a PDF it is likely Acrobats "Fix-it when closing file" could be triggered badly.

[wdscxsj]

@GitHubRulesOK Thanks for your explanation. I actually meant SumatraPDF in a read-only mode.

[GitHubRulesOK]

@wdscxsj well it is currently read only since acrobat would block all those hard drawn comments, but you can set Foxit to dual editing via command line

[wdscxsj]

@GitHubRulesOK Read-only on one side is good enough for me. But the 32 MB limit is too low indeed.