Focus-Pages

[meteorquake]

In reference works one is often working with a particular page range, for example in the 900-page document I have open I'm just interested in viewing and searching in a 100-page stretch (extracting the pages is also blocked).
It would be very useful to be able to designate a page range that the viewer acted as if only existed, particularly for the Find function but also for the viewer if possible too - currently a Find encounters hits in all 900 pages rather than just the area of interest.
It would also be useful if this focus range could be designated on command-line options too.
Ideally the pages could be a set of comma'd page ranges but for simplicity could start off as a simple span.
I suspect much of this could be done with relatively little code.

[GitHubRulesOK]

Was it not you wrote extraction script to export e.g 100 pages from 800-900

The PDF structure is itself whole file as the font could be first item and the first page the last object in a PDF container. It is a very "freeform" format. In PDF syntax page [0] is first then it writes a page tree where branch (/Kid 799) will be 800th page so the PAge number is not a given but based on full traversal of the inter-related objects when exported that first page [799] (800) will be new page [0].

Thus to simply focus a range the whole file would need to be accessible for traversal to and fro. Not impossible but not needed when you have the much faster file with only 100 pages.

EXTRACTION cannot be blocked (if you have the OPEN password) since the filename and page range are all any command line tool needs to separate those pages. Simplest is whilst viewing a pdf you could press one key to call MuDrop then type in 800-900 and auto-reload the 100 page result.

[meteorquake]

For the first general notion, I am thinking even if the "focus" may need to decode the whole file once on opening or every time, it only need treat the pages of interest as relevant; so for example even if a Find has to traverse the whole document, it can just skip finds for pages outside the focus range. The main problem is having to manually engage with innumerable hits outside a range of interest.
I'll try the other exe that was mentioned although I think it's ideal to be able to focus without doing an extract, since a few times a day will be a different focus.

[GitHubRulesOK]

@meteorquake
My suggestion at its simplest is write a temporary file so a batch file with vbs query
Use it to write a %temp%\filename-800-900.pdf and then SumatraPDF that result. I suggested Mudrop as easiest to reconfigure but as you have a specific single need it would be easier to focus just part. Re built parts as ExportPages.cmd (it will download a recent cpdf (2.8.2 is 64bit fix and 2.8.1 is 32.bit but 2.9 is in progress)

I have uploaded that modified script as https://github.com/GitHubRulesOK/SumatraPDF-Plus/blob/master/Plus/ExportPages.cmd note cpdf has a wide set of page descriptions like export some portrait pages in a range or just the landscape ones all in the manual at https://www.coherentpdf.com/cpdfmanual.pdf#page=22 1.3 Input Ranges

[GitHubRulesOK]

@meteorquake
You may not be aware SumatraPDF pre-release now exposes internal MuTool abilities
This includes draw pages (But MuTool needs the range same as any other CLI) I was surprised to see 1.27.2 also includes the brotli compressor which SumatraPDF understands (but other readers like Edge with Acrobat may not)

tool -o out.pdf -O compress=brotli in.pdf 800-900 would be simple enough to add range to the end

here with one page we see the file is much smaller

@echo off
C:\Users\WDAGUtilityAccount\Desktop\Apps\PDF\SumatraPDF\17659\SumatraPDF-prerel-32.exe convert  -O compress=brotli -o "%~dpn1-brotli.pdf" "%1" %p
timeout 1 >nul
C:\Users\WDAGUtilityAccount\Desktop\Apps\PDF\SumatraPDF\17659\SumatraPDF-prerel-32.exe -new-window "%~dpn1-brotli.pdf"

[kjk]

Note: tool is no longer accepted, it's just SumatraPDF draw etc. Basically replace mutool with SumatraPDF and the rest of syntax is the same

[GitHubRulesOK]

@kjk I did have issues with the semantics BUT SumatraPDF MUST be ABSOLOUTE or I had problems

[kjk]

@GitHubRulesOK I don't follow.

[GitHubRulesOK]

@kjk if I tried to run those first version as simply via cmd or via external viewers using relative pathing it usually means supmatrapdf will pick up errors and try to run the incorrect parts as if files to view I understand the use of tool is only the version before current. but here I use absolute then relative

[kjk]

yeah, please wait for next pre-release build, it's compiling

[GitHubRulesOK]

@kjk similar issue only the last is respected because it includes the path (makes no difference inside or outside sandbox but in both cases this is latest Windows 10)

C:\Users\WDAGUtilityAccount\Desktop\Apps\PDF\SumatraPDF\17663>SumatraPDF-prerel-32 poster

C:\Users\WDAGUtilityAccount\Desktop\Apps\PDF\SumatraPDF\17663>SumatraPDF-prerel-32.exe poster

C:\Users\WDAGUtilityAccount\Desktop\Apps\PDF\SumatraPDF\17663>%cd%\SumatraPDF-prerel-32.exe poster

C:\Users\WDAGUtilityAccount\Desktop\Apps\PDF\SumatraPDF\17663>Usage: SumatraPDF poster [options] input.pdf [output.pdf]
-p - password
-m - margin (overlap) between pages (pts, or %)
-x x decimation factor
-y y decimation factor
-r split right-to-left

Same with 64 needs a PATH
%cd%\SumatraPDF-prerel-64.exe poster

C:\Users\WDAGUtilityAccount\Desktop\Apps\PDF\SumatraPDF\17663>Usage: SumatraPDF poster [options] input.pdf [output.pdf]
-p - password
-m - margin (overlap) between pages (pts, or %)
-x x decimation factor
-y y decimation factor
-r split right-to-left