Home / Make Sumatra remember zoom, display pos. etc. for Favorite pages

please,
is it possible to make sumatraPDF remember the zoom, display position of the page, rotation and other view options for every favorite page.
thanks.

I would prefer that it remember the rotation option for every page, not just favorites. Then when you come to a page that has a sideways diagram, you can rotate it once and it stays rotated forever, without rotating the rest of the document.

Currently it remembers rotation for the whole document, but often documents have different rotations for different pages.

Maybe View menu would have different options for “Rotate page left” and “Rotate document left”.

the zoom rotation and many view options are optionaly “remembered” for a whole file thus the favourite page will open with those file settings.

Many users complain that redundant settings are kept for older files, but if the settings were to be kept for every single page you read it would cause bloat to such an extent the settings would eventually be slow to load.

For example with just one “remembered” file that has this entry
TocState = 1 3 5 13 19 30 33 34 41 51 55 56 61 83 86 94 99 103 104 106 113 115 118 130 146 147 150 152 157 162 172 176 177 191 195 196 202 219 230 231 238 240 242 248 253 256 259 263 264 267 272 281 291 296 305 306 315 327 328 332 333 334 337 339 344 346 351 358 361 362 364 368 371 378 382 385 387 402 403 410 413 424
Its slow to load, what if I left all my tocs active or each page needed to have zoom and rotation entries.

My personal view is these types of entry should be kept out of settings and stored in either the PDF using the editors features or in a companion metafile like some other editor/readers do.

I agree. IMO all MRU-related sections such as FileStates, SessionData etc. ought to be kept separate from the main settings file. Perhaps a separate text/XML/JSON file if readability is important, or a compressed binary DB if it isn’t.

I was hoping filename.bmk would combine .smx (highlight) features plus user history then .vbmk could just act as a link/library mechanism, however we shall see which way the development goes.

I don’t think it makes sense to separate and store MRU data into per-file .BMKs. Highlight info. is file-specific and is better suited to being stored alongside each file, but MRU data makes more sense being stored in a single file in a standard location expected by the program (plus this way loading will be faster too).

It would be better if it could remember rotation for every page, though, since many many documents have figures rotated from the main text, so we have to rotate it for that page, look at the figure, then rotate it back again for the next page, and do this every time we read the document. We should be able to rotate a page once and it is remembered for that document forever. Probably a separate menu item from rotating the entire document.

Whilst not imposible to store the rotation per page it can in many cases for books need 3/400 entries though for small magazines it may be only a dozen or two.
Curently those issues are avoided by a whole document approach and as a user adds more and more documents a common database would become slower just like windows registry does.
My view is that a per-file “sidecar” ensures that as file folders get deleted so does their dross. However it also has its downfalls such as portability renaming etc.
If file pages are rotated internally for right reading then there is no issue other than page fitting, but that rotation is an editors function that authors should consider when planing their page layouts.

Might I suggest one of a number of available free PDF tool kits. Everyone has their favorite, I use the one from PDFill. While their editor, which I personally think is great, is $19.99 if you don’t want a watermark, they have a totally free toolkit that will allow you to merge, split, re-order and rotate individual pages as well as many other features. You can load the file in, rotate the pages the way you want and save it back out. While the toolkit requires you to know the page number and the number of degrees to rotate, the editor will allow you to do the job visually.

I tested the toolkit against a PDF I had created with the flag to allow modifications off and it still worked. Your mileage may vary. (Disclaimer - I have no affiliation with PDFill whatsoever - I just like their product.)

I also use PDFill along with others and although freemium sejda with visual editing is slow, due to using its own java runtime. I find its little brother SAMpdf (similarily slow but less visual features) is good enough for basic rotations spliting and merging when called from a page in SumatraPDF. see

Editing PDFs is not a solution, this is a viewing issue

Isn’t that the same as editing?

In your scenario, every time you open a new PDF, rotation settings are stored “somewhere” for every page - even if you are only opening the file once, don’t need to rotate anything and never plan on opening it again. As you move through the file, you manually rotate the pages to your liking (i.e. editing) and the settings are automatically stored “somewhere”. Pretty soon this “somewhere” becomes enormous and has to be read for every PDF opened, thus causing longer and longer loading times for every file you open. Now, let’s say you get a PDF just the way you want it and then copy it to another PC or email it to someone. All that work you did is left behind on the original PC.

However, If you find a document that needs some pages rotated, just close it in Sumatra and open it in PDFill or some other editor instead. You can still read the document just as in Sumatra. When you come upon a page that needs rotating, a couple of mouse clicks or a keyboard sequence and the page is rotated. When you’re finished, Ctrl-S to save the document with all your changes intact. Now, when you re-open the document in Sumatra (whether on your PC or another), all your changes are there without the need for a separate “settings” file that will grow with every document you open.

Either way you slice it, you are still “editing”. The question is, do you want to do it at the expense of a couple of mouse clicks, or a gradual and permanent slowdown of your reader?

@Russ
I agree with the principle that that storing individual page rotation is an editor function and rotating ALL pages is the difference between Adobe Reader and Adobe Acrobat.
Also as you point out it is possible to rotate single./ range of pages via an editor tool to keep or re-distribute. without any bloat or slowdown.

What I wish to add to your comment is that PDF rotation per page or range could be done via an external command line whilst still viewing within SumatraPDF. There is a limitation that the PDF must be under 32MB otherwise it is locked against changes.
Since you prefer pdfill then for the paid up version the ExternalViewers command for the current page clockwise would be something like
CommandLine = "C:\Program Files\PlotSoft\PDFill\PDFill.exe" ROTATE "%1" "%1" 90 -page "%p"
However I do not think that would work on its own as both in and out are the same and pdfill should “scream” FOUL, thus a necessary step would be to include a part to copy current file to backup then action rotate on backup to output as currently viewed.

@endolith
If you find a suitable command line tool to concurrently edit the pdf one page at a time I can outline how that may be done, but as 1 page rotations are external to SumatraPDF/Adobe Reader inherent functions its at your own risk how that affects your source files.

No? Editing the file is editing the file. It changes it permanently, no matter who opens it, no matter which software opens it. The file content is changed, it can no longer be de-duplicated, the checksums are no longer the same, git will see it as an altered file, etc. etc. That’s a very drastic action when all we want is to view a page rotated 90 degrees.

Technically, the rotation settings would only be saved when the page is rotated, not just from opening it, but yes, they would be stored in Sumatra’s settings, just like it saves rotation, zooming, and reading position now. The only difference is that it would be per-page rotation instead of whole-document rotation.

I don’t see why this would be necessary. If the page is not rotated, then nothing is saved for that page. 99% of pages don’t need it to save anything at all.

Yes!

I don’t see why. Page rotation is 2 bits, page number is 2 bytes max, and almost all pages in almost all documents require 0 bytes storage because they can be left at their default rotation.

SumatraPDF already does this, and it doesn’t cause any noticeable lag, and even if it did, it would be worth it for the time saved from rotating pages.

Yes, that’s good. My view settings for the file should not affect the experience of someone else who loads the same file.

I want to click a button once to rotate the page, never have to do it again, and without changing the structure of the file, creating new files, dealing with external software, etc. I don’t think it will cause any noticeable slowdown of the reader, but even if it did, it would be worth the convenience and time savings of not having to do all that other stuff. One click, done.

I don’t think a PDF reader should be permanently modifying a PDF file. This is a viewing issue, not a file issue. It should save the rotation per-page, just like it saves the rotation per-document.

I understand the desire however I cant recolect another app where documents are rotated per page without that being a precursor to saving as a new layout.

Keeping separate renders per page is not native to MuPDF, I’m not saying its impossible since SumatraPDF can scale pages independently, but to add complexity of checking each entry for rotation out of possibly a 400 page book then do that for each tab both now and throughout settings history is certain to lead to increasing overheads. My prefered solution is that such info is best suited to the .bkm files https://github.com/sumatrapdfreader/sumatrapdf/issues/1407

Official Line in 2017 was SumatraPDF Reader using MuPDF is functionally similar to Acrobat Reader for PDF and as a side note currently has a bug in DjVU page rotation which should be fixed prior to any other rotation enhancements.

So a file that is stored alongside the PDF that includes meta-information like bookmarks and page rotation? That would be fine. I just don’t want it to affect the original PDF, since I need to be able to de-duplicate those, etc.