RFE: optionally overlay content from all pages in preview when cropping

[DIV]

There was a cool tool* I used in the past that overlaid content from all pages in the preview when cropping the pages, which was a nifty way of ensuring that no (scanned) text on any page got accidentally trimmed, but as much as possible of the useless empty space around the text was removed.

Could such a feature be considered for inclusion in Editor, as a tick-box that users could toggle in the cropping preview dialogue box?

Other users, please feel free to comment on the usefulness (or otherwise) of such a feature.

—DIV

* I think I recall the name of the tool, but maybe it's better not to mention it here, so that there's less chance of a perception of reverse-engineering an implementation, as distinct from creating a fresh implementation of the basic idea?

[Paul - PDF-XChange]

Hi DIV,

you mean in this preview, to have all paged overlaid rather than click through the pages to see what is outside the crop box?

I imagine this might get overwhelming when there are a lot of pages. How would this 507 page document work for example?

crop pages preview.gif

That preview would be very busy! Am I misunderstanding the request?

[DIV]

The preview would indeed get very 'busy', because all of the content from all of the pages would be overlaid onto a single 'page'.
The idea is not to be able to read anything! The idea is to be able to see how far in it is safe to crop "all pages" without accidentally trimming some useful content.

Admittedly when I was doing it I was dealing with documents with no more than dozens of pages, rather than hundreds or thousands of pages. Nevertheless, from the user's point of view it probably becomes more useful for longer documents, because they're more tedious to click through to check for (say) an unusually low footnote on page 47. From the implementation point of view it might take more memory/CPU/time, perhaps — but that's your expertise, not mine

If you wanted to make the idea more 'advanced' (or 'complicated'), then you could allow the user to specify a page range to overlay. Aside from the possible(?) memory/CPU/time issue, the other advantage of this would be to avoid selecting pages of incompatible layout (e.g. a document with a mixture of A4 and A3 page sizes, or a mixture of portrait and landscape orientations).

Perhaps it could be done with a low-resolution rasterisation (to suit the preview size), and then combining them using something similar to either the Multiply or Darken blend modes in the Commenting Tools menu.

image.png

—DIV

[Daniel - PDF-XChange]

Hello, DIV

I do not expect that this request will be accepted, simply because rasterizing a few hundred pages still requires loading their content to begin with, rendering it, and then downscaling from there, even if the end result is less intense, it would be a very lengthy process (by comparison). At the moment, our "remove all white space" feature, shown below, will calculate the white space for each page individually:

image.png

This allows you to have pages of various orientations in your document even, and still crop the white space from them all safely without missing a single thing.

image(1).png

I think this will be the best we can offer for the time being.

Kind regards,

[DIV]

OK. It sounds like the implementation would be more challenging than I expected.
—DIV

[Stefan - PDF-XChange]

[Jensen Head]

our "remove all white space" feature, shown below, will calculate the white space for each page individually

Thank you! This is really cool!

But what's not so cool is that the "Crop Pages" window interface doesn't make it clear which functions work in batches across the entire set of pages and which work individually. In PDF-Tools this is obvious and depends on the state of the "Batch Processing Mode" checkbox.

[Daniel - PDF-XChange]

Hello, Jensen Head

Is there a particular reason this is "obvious" in PDF-Tools? it looks to be essentially he same on my end. (also, it should not be reliant on the batch processing mode checkbox..)

I don't know that any changes will be coming to this text, but I am curious what you mean exactly.

Kind regards,

[Jensen Head]

Is there a particular reason this is "obvious" in PDF-Tools? it looks to be essentially he same on my end. (also, it should not be reliant on the batch processing mode checkbox..)

What do you mean?

[Daniel - PDF-XChange]

Hello, Jensen Head

sorry, I mean that I am confused by this specific claim:

In PDF-Tools this is obvious and depends on the state of the "Batch Processing Mode" checkbox

The Crop pages tool looks nearly identical between the two applications, and in PDF tools, its handling does not change with relevance to the batch processing checkbox. So, I am not understanding what you mean when you said that it is "obvious" in Tools, but not in the Editor. What is different about the Tools implementation of the Crop function, that makes this any more or less obvious in comparison to the Editor? If it is a simple item that I am just overlooking, I can certainly pass it on for review - but so far I'm not seeing anything that would change someone's perception of the options.

Kind regards,

[Jensen Head]

In PDF-Tools, the "Batch Processing Mode" checkbox toggles the entire tool between two fundamental states, which produce different results when processing more than one input document. Granted, when I first saw this switch, it wasn't immediately clear what it did either. But you have an excellent tooltip explaining the setting.

PDF-XChange Editor doesn't explicitly indicate what switches "batch processing of document pages" from "batch processing mode on" to "batch processing mode off." This behavior is hidden in the specifics of individual settings from the set, within the general "Crop Pages" tool.

I hope this explanation makes my understanding of the interface's inconsistency clearer.

[Daniel - PDF-XChange]

Hello, Jensen Head

Unfortunately this only adds to my confusion...
"Batch" processing refers to processing multiple documents in a since stage of the process.. As such, the only impact that "batch processing mode" should have on the process is in relation to multi-document actions, such as the "Split/Merge Documents" action.

There is no scenario where it should have any impact on the "crop" action at all. If there is a case of such a difference, can you please explicitly showcase how, and what the difference is for me, as that should never happen and would almost definitely be a bug, if it is happening.

As for any relation to the Editor... Batch processing mode is a non-factor there, since you are manually running each "action" - and would actively know if you are using the "combine files" tool to merge multiple input documents in a single step.
I do not know how or why it should/would need to be distinguished in the first place - or how it could apply to the crop tool?

Kind regards,