2021:Split Pages (Activity)
Split Pages is an activity that will split a multi-page PDF or TIF document into individual pages.
When applied to a Batch Folder with an attached PDF or TIF file, the Split Pages activity will create a Batch Page object for each page in the file, which are created as children of the Batch Folder.
About
|
|
|
|
We can also process this document at this point. We can apply Grooper activities at the folder level, to this Batch Folder (by setting a Batch Process Step's Scope property to Folder). An activity running on the folder level can manipulate the content in the attached file. For example, if we ran the Recognize activity at the folder level, it would obtain text data from the attached PDF file. |
|
|
|
Why Split Pages?
There are two reasons to use the Split Pages activity to split out pages from a multipage document.
- To apply activities that require Batch Page objects to function.
- Namely the Image Processing and Separate activities.
- To increase compute efficiency.
- A Batch Folder is a single object, which can be processed by a single processing thread. If you split out the attached document's pages, each page becomes its own object in the Batch. Each page can also only be processed by a single thread, but with multiple page objects now present, multiple threads can now be used to process the document (one for each page).
Splitting Pages for Specific Activities
Certain Grooper activities require Batch Page objects by design.
- The Separate activity separates loose pages into folders. If there's no Batch Page objects, there's nothing to separate.
- The Image Processing activity applies an IP Profile to mutate a page's image in order to clean it up before OCR processing during the Recognize activity. In all but the narrowest of use cases, the Image Processing activity must process Batch Page objects, not Batch Folders. If there's no Batch Page objects, there's nothing for the IP Profile to clean up.
|
So, first we need to run the Split Pages activity to add page objects we can manipulate. Then, we can run the Separate activity to separate those pages into folders. |
|
|
|
|
|
|
Splitting Pages to Increase Efficiency
Often a Split Pages activity is added as one of the first steps in the Batch Process to increase processing efficiency. Why? To take full advantage of your systems multithreaded processing capabilities.
Many activities can run on the folder or page level and produce the same end result. For example, the Recognize activity will perform OCR and/or native text extraction to obtain text data for a document. This activity can run either on the Batch Folder or Batch Page level.
When running on a Batch Folder level, it will obtain text data from the attached PDF or TIF file. When dealing with large multi-page files, you can encounter a processing bottleneck, leading to increased processing times, if you're only running activities of the folder level.
|
If you apply the activity at the folder level, each thread will process a single Batch Folder.
|
|
|
If you apply the Recognize activity at the page level, each thread will process a single Batch Page.
|
When should I use Split Pages to increase efficiency?
You will get the greatest benefit from the Split Pages activity if you are processing larger multipage PDF or TIF files.
- The more pages there are in the source file, generally the greater the efficiency reward.
- Furthermore, the more processing able to be done at the page level, the more efficiency you'll reap from splitting pages. For example, it will be advantageous for you to use Split Pages to make a Recognize step in your Batch Process more efficient. It will be even more advantageous if you have both a Recognize step and an Image Processing step in your Batch Process, as both those activities can be executed at the page level.
You will receive less benefit if your imported files are small, one to two page PDFs or TIF files.
- In that case the processing effort to split the pages may not be made up by increased parallelism in subsequent steps in your Batch Process.
Are there any drawbacks to the Split Pages activity?
Be aware the Split Pages activity will necessarily eat into your Grooper file store's storage space. By creating a new page object, you're effectively making a copy of the PDF or TIF's page. That page's image must be stored somewhere (your Grooper Repository's file store location).
- If your Grooper file store is severely limited in size, you may not have the digital space necessary to split out several large digital file's pages.
- Also, keep in mind SSD storage is faster than HDD storage. You may experience latency if your Grooper file store's working storage is itself a slower storage medium.
Bursting and Rendering PDFs
There are a few different ways to split pages from PDF documents in Grooper. Being aware of how the page objects are created can greatly increase your processing efficiency in many ways.
First, you must be aware of the differences between "image-based" PDF page and "text-based" (also called "true" or "native-text") PDF pages.
|
An image-based PDF page's visible content is defined by a single image. For example, this could be a scanned paper page saved to a PDF page. This is the realm of raster graphics. A mosaic of pixels constructs the image presented to the reader on a computer screen.
| |
|
A text-based PDF page's visible content is defined by digitally authored content. For example, a PDF form created from scratch in Adobe Acrobat or a Word file printed to a PDF format would both be text-based PDF pages. This is the realm of vector graphics. Text and graphics are rendered visually by mathematical formulas.
|
Depending on how the Split Pages activity is configured, one of three things is going to happen:
- All page objects will be created as PDF pages.
- All page objects will be created as JPEG images.
- Page objects will be conditionally created as PDF pages or JPEG images.
- Text-based pages will be created as PDF pages. Image-based pages will be created as JPEG images.
Why do I care?
Why should you care whether or not the page is split as a PDF or JPEG image? There are several reasons. Some are practical, relating to necessary processing requirements. Others are relating to computing efficiency.
Practical Considerations
- I have text-based PDFs with purely native, digitally encoded text.
- Text-based PDFs already have text data embedded in the page. Whereas images must be OCR'd to get text data.
- If your documents are text-based, you more likely than not just want to extract the raw native text data from the PDF. There's no reason to OCR, if your documents already have good, machine readable text embedded in them.
- Split as PDF pages to perform native text extraction during Recognize.
- I have text-based PDFs with corrupt or semi-corrupted encoded text.
- Sometimes text data can be corrupted. While a page appears readable to a human, the encoded text data may be a bunch of gibberish. Furthermore, some PDF authors will intentionally obfuscate text characters by swapping character glyphs as a kind of watermarking. For example, a printed "A" on the page may be encoded as a "£".
- In both cases, while the printed characters look fine visually, the underlying text data is inaccurate. If the issue is bad enough, you may need to OCR the pages instead of extracting the embedded text data to get the most accurate text data from the document.
- Split as JPEG images to ensure Recognize will OCR the pages (Since they are JPEGs and not PDFs, it won't even attempt to extract native text).
- I have image-based PDFs that require substantial image processing cleanup.
- The Image Processing activity performs permanent image cleanup on a digital image. With few exceptions, it is preferable for Image Processing to process a JPEG image, not a PDF page (See the #Image Processing Considerations section for more details).
- Split as JPEG images to clean up pages with the Image Processing activity.
Efficiency Considerations









