Showing results for 
Search instead for 
Do you mean 

Checking in a large folder of documents

Valued Contributor

Checking in a large folder of documents

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?

13 REPLIES
Honored Contributor

Re: Checking in a large folder of documents

Raynebc,

 

You can do this, but it's a bit weird really.

 

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).

 

Let me know if you have any additional questions.

 

Cheers,

Erik

Valued Contributor

Re: Checking in a large folder of documents

That sounds exactly like it would solve the users need!  I hadn't dug into the queue properties to find that option, but I greatly appreciate you pointing me to this information.  Thank you!

Honored Contributor

Re: Checking in a large folder of documents

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!  :smileywink:

Valued Contributor

Re: Checking in a large folder of documents

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: 6.2.4.1225    ModName: acropdf.dll
ModVer: 9.3.2.163    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: 6.2.4.1225    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: 6.2.4.1225    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.

Honored Contributor

Re: Checking in a large folder of documents

Yeah, like I originally said this methodology can be a bit weird. 

Valued Contributor

Re: Checking in a large folder of documents

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).

Honored Contributor

Re: Checking in a large folder of documents

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.

Honored Contributor

Re: Checking in a large folder of documents

I'd suggest getting off build 1225.

There were some freezing issues in that build which is why it was replaced quite promptly with 1226.

Get the latest 6.2.4 client and see if the crash still occurs?

 



::::::::::::::::::::::
NOT A HP EMPLOYEE
::::::::::::::::::::::

Kapish.com.au
Valued Contributor

Re: Checking in a large folder of documents

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.

 

Honored Contributor

Re: Checking in a large folder of documents

Yeah, and along that line EzeScan is a very good alternative as well.  

Valued Contributor

Re: Checking in a large folder of documents

Unfortunately, we don't have a budget for buying any new software for this.  I'm going to try Trim 6.2.5.1297 to see if TrimViewer will properly render the PDFs, or at least not crash when using the Adobe Reader plugin.

Valued Contributor

Re: Checking in a large folder of documents

Trim 6.2.5's built-in viewer still misrenders the Xerox scanned PDFs.  See my attachment from a few posts back to see how it's showing them.  Is this a known issue?

Valued Contributor

Re: Checking in a large folder of documents

As nobody here seems to be sure of why Trim's viewer was mis-rendering the files, I opened a ticket.