Is it Possible to Export Favorite Pages to a New Pdf?

[MarjaE2]

I would like to be able to mark favorite pages on a topic, and then export the pages to a new pdf document, so I could stash them in an appropriate folder, read them on another device, etc. I can't find anything about this in the documentation, so I think it would be a new feature here.

[GitHubRulesOK]

the function is there in the PRE-release 3.7.18324 but not by "marking" you need to note current pages of interest as a list then use the
Extract pages from PDF with that list as the target.

So for example 12,20-30,50,53,1000-N

It will try to export related entries such as bookmarks which is better than may other tools, but page numbering will naturally be off kilter.

IF you use some OTHER "Custom" page renumbering tool then SumatraPDF can respect that 1=12 2 =20
an easy to use PDFMeta tool MANY years ago and thus only found in Internet libraries would allow for pages as a list like

[PageLabels]
b1 sD o12 
b2 sD o20 
b13 sD o50 
b14 sD o53 
b15 sD o1000 

[GitHubRulesOK]

@kjk the explanation page online is AWOL the current list shows 2 extract as text and not an extract pages as PDF unless using online search
https://www.sumatrapdfreader.org/docs/Tool-x-extract-pages-from-pdf#:~:text=To%20extract%20pages%20from%20a%20PDF%20in%20SumatraPDF%3A

It looks like this line needs moving down and changed from text to pages [Extract pages from PDF](Tool-x-extract-text-pages-from-pdf.md)

sumatrapdf/docs/md/SumatraPDF-documentation.md

Line 89 in c2e20c0

[Extract text from PDF](Tool-x-extract-text-from-pdf.md)

[kjk]

thanks, should be fixed

[Petewg]

I noticed that no matter how many pages are being extracted, the size of the file in which they're saved is always the same and almost equal to that of the original (just a few bytes less).
Is it Ok?
(pre-release build: 3.7.18454 64bits)

[GitHubRulesOK]

@Petewg that is not uncommon with some tools but either need a second pass or improvement in the extraction function. Relative size is impacted thus decided based on many factors, and PDF extractions may even be bigger than their source. The main contributor is the encoding formats in use by each file.
This exSTREAM Sample as plain text is 17 bytes in 2 lines but as a PDF produced by a common Academic application (Application: TeX
PDF Producer: pdfTeX-1.40.22) it is as a Compacted/compressed PDF = 12.46 KB (12,761 Bytes) but that is because it carries styling! so no longer plain and decompressed will become 14,933 Bytes

So as raw PDF it is this 1 line Td [(Hello)-333(W)83(orld!)]TJ 154.421 -567.87 Td [(1)]TJ spilt into 4 areas High = (Hello) - (W) - (orld!) and Low = (1) on a page

BT
/F19 9.9626 Tf 148.712 707.125 Td [(Hello)-333(W)83(orld!)]TJ 154.421 -567.87 Td [(1)]TJ
ET

All the other baggage is how to show that as Times Roman with an encoded Computer Modern font.

That is why there should be no expectation on extracted be smaller However it could be much smaller and the expectation is if there are 2 such pages then 2 files each will be less because the text part is not in both, just all the baggage is needed by both.

So that small part will be the difference between pages contents and for one less page then that small part will not be needed.

[GitHubRulesOK]

@Petewg conside the first file has 2 pages then removing the unwanted page references will still be roughly same size each will just display 1 not 2 if those are then garbage collected and recompressed they will then be smaller so after extract ask for compression.

[Petewg]

Maybe I wasn't clear enough.
I have a PDF with 73 pages. It is exactly 26.735.464 bytes
Then for a reason I thought to extract 2 pages into a separate pdf, (to send it via e-mail).
To my surprise the size of the created pdf was 26.727.336 bytes, which is 8128 bytes less than the original. Doing a second extraction, 8 pages this time, the size was 26.727.377 bytes.
Tried another PDF,
original size: 35.014.204 bytes
size of 2 extracted pages: 37.096.833 (this is almost 2 GB more than the original!)

I think something has to be improved with extraction, which undoubtedly is a very welcome & useful feature.

Edit: Doing a document compress, the size reduced dramatically! This seems like an acceptable solution, so it might be done automatically during extraction (before saving).

[GitHubRulesOK]

@kjk my observation is the file is naturally modified as a copy to do the BEST means of extraction with minimal damage.

E.g. retain 100% structure and simply remove the unwanted page references thus Accessibility Bookmarks Fonts Goto this and that are all still present, even if some impacted! Since the alternative is destroy file structure as standalone single pages.

The @Petewg issue is that the garbage collection is not removing the natural bloat. Which is usually included as part of a compression OR DECOMPRESSION cycle. Normally I use the latter, but file size will then increase to normal faster size.

Perhaps a setting (as offered by MuTools g[ggg],compress=) to either decompress or compress aggressively, would allow for collateral damage to the structures!