We have a user that would like to be able to scan hundreds of single page forms that have hand-written content, and check them into Trim with appropriate metadata. Large batches of these forms would be procesed on a routine basis, so we're trying to find an efficient means for her to accomplish this task.
Originally, she had preferred to use TrimScan, since she could just scan the document, TrimScan would show her the scanned document and she could launch the record check-in immediately by reading the metadata off of the screen. However, anyless we missed something, we couldn't find that TrimScan would save to a PDF format, which is the format we need it in.
Queue processing would be very close to solving this need, especially since the default record type for a queue can be specified, but there's still the problem of obtaining the right metadata on a per-document basis when the queue is processed. Is there any way to have Trim automatically preview or otherwise open the document being checked in by the queue processor? What would be considered a best practice for processing hundreds of files and entering file-specific metadata for each, besides buying more specialized scanning software?
Document Queues have two properties that you'd want to leverage: Automatically View the Current Document and "After a Document is Checked In: Delete the Local document". Then you just need to determine if the document queue should be automatically processed or if the user is going to manually invoke the process. Either way the same thing happens: the PDF pops up on the screen and then user can check in the document for meta-data capture.
Ideally for this to be useful and not annoying the user would need to two monitors (pretty much standard for any scanning workstation really).
When you create the document queue there aren't as many options available. You have to go back into the properties after you've saved it. Then you'll see an options tab that is similar to the "Dropped Files" tab of the User Options. Use those to tweak the settings for that queue.
Give it a go and let everyone know if it worked for your users!
When setting Trim to use a browser plugin to preview PDF files with and having Trim process a queue of PDF files on a mapped network drive, it renders them in the Trim Viewer window using the IE Adobe Reader plugin. I tagged all files in the queue and told it to begin the check-in. After I canceled several in a row, Trim crashed on a particular PDF (1999 Appendix A Correction to PTC 069-00001, issued 9.22.99): AppName: trim.exe AppVer: 126.96.36.1995 ModName: acropdf.dll ModVer: 188.8.131.52 Offset: 00018ce9
After the crash, the main Trim window appeared to remain open, but presented an alert window with no text, but with a red circle with a white X.
Then when I canceled, Trim asked if I want to save the record, I said no and I got another crash: AppName: trim.exe Appver: 184.108.40.2065 ModName: ntdll.dll ModVer: 5.1.2600.5755 Offset: 000449cf
After that crash, I got another alert window with no text. After closing that, the main Trim instance closed. After I tried to process the queue again, Trim indicate that the queue was still locked, saying that it is being used by another program on this computer (because TrimQueue.exe was still running from the prior attempt above). After closing Trim and terminating the TrimQueue process, attempting to process the queue still gives the warning that the queue folder is being used (presumably because the "TRIMlock.dat" file that the queue processor creates never got removed). Even though the lock file documents which process is associated with the lock, Trim doesn't verify that process number is still running before presenting this message. It might not be feasible for Trim to query if the process is running on another computer, but it shouldn't be an issue for it to check on localhost.
This set of crashes occurred despite me being able to have Trim Preview each document sequentially, using the IE plugin. There must be some checking missing in the queue processing behavior in regards to continuing when one of the check-ins is canceled and the processing is told to continue (potentially multiple times in a row).
After trying to reproduce this a second time and was unable to, I closed the Trim Viewer window and worked outside of Trim. After a couple minutes of leaving Trim idle, it crashed: AppName: trim.exe AppVer: 220.127.116.115 ModName: unknown ModVer: 0.0.0.0 Offset: 1003a1c0
I am not certain of the exact criteria for reproducing this, but it may have to do with latency of accessing network storage, as I was not immediately able to reproduce these crashes when I copied the PDFs to local storage and redirected the queue's target folder.
Is this crashing more likely to be due to a flaw in Trim's handling of browser plugins or the queue processor? The only reason that I'm looking into using the Adobe Reader IE plugin in the first place is due to the absolutely attrocious rendering of some of the image-only PDF files that are created by enterprise Xerox machines (see attachment).
I honestly don't know. The TRIM viewer does ocassionally have issues with using the PDF IE plugin; but more often than not I think it's because of the PDF installation and components. Though with TRIM you never really know. I'd submit it to the helpdesk. But if you can't reproduce it then there's not much they are going to do about it anyways.
Hello. Another option might be to purchase a license of Trapeze Capture for TRIM. I have only briefly looked at TRIMScan, but it appears to be a pared-down version of Trapeze Capture. The full version (which we use) does have PDF and PDF/A output capabilities.
Unfortunately, we don't have a budget for buying any new software for this. I'm going to try Trim 18.104.22.1687 to see if TrimViewer will properly render the PDFs, or at least not crash when using the Adobe Reader plugin.