In the solution I worked on, the customer would actually chose the file using the Troi file plugin, and the scripting would attach that file path to the FM record. The PDF itself was displayed through a web portal (since containers just display the PDF icon). Simply load the file path (file://c:/....) as the URL in the web portal. If Adobe is showing the PDFs in the browser, do a quick search for PDF Open Parameters and you'll find lots of things you can customize (removing toolbars, default zoom level, etc) - the parameters are added after the file name. So the full path loaded into the web portal would be something like "file:/F:/Scans/MyFile.pdf#navpanes=0&view=FitH" - this loads the file at F:/Scans/MyFile.pdf, fit to width (Horizontally), with no navigation panes on the left.
Hope this helps give you some ideas.
1 of 1 people found this helpful
Are you using Macs or PCs? The approach may vary depending on the platform, and it may involve a plugin like ScriptMaster from 360works to pickup the scanned file from the scansnap folder.
But basically, it *could* work like this:
You create an intermediary .fp7 file which gets called whenever you make a scan. This can be defined in the ScanSnap manager app. When your intermediary.fp7 opens it executes a script which looks to the scansnap folder for new scans. Scriptmaster can do this. import the new scan into a container, and you're off to the races. You can then do with it as you please. I would then move the from your scansnap 'hot' folder to a 'dump' folder.
Hope this makes sense, and helps.
I have thought about the "let the user choose" approach, but I think that it would get very sloppy very quickly. Evenutally there would be 1000's of files scanned into a directory and they would have to sift thru all of them to find the one they want unless the script woud atomatically move the file to another folder and then attach it...
Is that what you did?
Also, how did you get the portal to show the document before the linking has taken place?
FInally, would the Troi File plugin allow me to schedule a Server side job to import files at regular intervals (moving them to another location in the process) and allow attachment later thru the user interface?
I can see promise, but I also see a lot of potential problems as well...
As David suggested, our solution also moves the selected files out of the "hot" (new scans) folder, so the new scans are easier to sift through (plus, the people scanning can easily pick out the most recent file, as the scanner would sequentially number the scans). They could even right click and preview file (opens in adobe) within the file chooser to confirm they have the right file, then click on the OK button to attach to the user record.
The portal in this case isn't displayed until after the file is linked, but you could easily create a temp layout with the file name and a temp portal, with a "Confirm" button that runs a script to move the file (in our case, again, with the Troi file plugin) and then attach to the record.
As for the scheduled movement, I'm not sure - I didn't get into any of that aspect. I'm not sure of it's capabilities to read directory structures etc - it was a plugin in place from a frmer developer that, in this case, is used for pikcking and moving a file.
I am using both in my current workflow, though I prefer the Mac for the scanning / import job as the SnapScan just works on it (the PC is a little more work).
I like the simplicity of this idea. I have not tried tying SnapScan manager to a Filemaker file app. If you have done this, can you tell me how well it handles a situation like:
1) duplex scan to JPEG (front and back) set to recognize one front-back page as one document
2) drop 10 in the scanner and punch scan
Does the FM intermediary handle the rapid 10 in a row input of files (i.e. does the on-open script run all 10 times)?
If I remember correctly, the snapscan manager doesn't create the pdf file until the scanner's hopper is empty. All of the full duplex/half duplex stuff is under control of the scansnap app as well.
So, the FM file would only be executed once scansnap.app is done, and the file is written to the *hot* folder.
My current SnapScan configuration creates 2 files with each page (front and back one jpg each) and that occurs right away. I will have to set up a trial to see if the startup script is called once or each time.
I will also have to look at how ScriptMaster might be able to grab the file. Do you have any suggestions on this aspect?
I am using the SnapScan configuration for a client like this:
The client has several SnapScan options to choose from: Single page singel sided, Single page double sided, All in one document single sided and all in one document double sided.
The client scans away all documents, where SnapScan converts the documents to a PDF + included text.
Then a script is started to import all the documents into FileMaker (in this case the documents are moved to SuperContainer and the text is scraped from the pdf using the Scribe plugin.
Later the imported scan records are linked to the client records.
Hope this helps,
Ruben van den Boogaard
1 of 1 people found this helpful
I needed to do something similar and reversed the workflow. User finds the record in FMP they want to associate with a PDF or JPG. User clicks a "Scan" button next to a container field and using the InsideScan plug-in (amazingly simple to set up and configure) the scan dialog box comes up, user clicks Scan again, and the resulting scan drops into the container field on the record the user chose. I actually use a portal for the container field so the user can add an infinite number of PDFs/JPGs. There's only one gotcha: InsideScan only works with TWAIN-compliant scanners and ScanSnap is not one.
Ann Arbor, MI
I gave David's "let SnapScan call a db.fp7 file" method a try, and the SnapScan manager will not launch a document, just an application. I then cobbled together an apple script saved as an application to open the file, but this doesn't appear to work for what I need done (only launches at the end of each "batch" of files. Too bad, as this would have been elegant if I could have figured a way to pass the name of the file to FM thru the applescript or automator workflow...
This leaves me the choice of either Gordon's suggestion of flipping the workflow (and buying a Twain compliant scanner) or working with the Troi plugin to try to grab the required file.
I guess I will have to digest the possibilities some more...
Bummer. Sorry to lead you on a snipe hunt.
When you tried the applescript, did you save it as an application? BTW, this *should* work with an Automator app as well.
Good luck, I'm ineterested to hear how you resolve this.
I am not familiar with SnapScan...
I do think, however, that you are trying to tie this into SnapScan too heavily rather than perhpas the OS.
It is possible with many different methodologies (Troi, Scriptmaster, PHP, Applescript) to keep an eye on a folder... so that when a new file is found a script to move/rename and link the file to a record is triggered.
Can SnapScan be linked to a URL as well as an App? If so, it might be possible to do this automated by SnapScan in that way...
Is the FM database on Server or a local machine?
I am not necessarily trying to tie this into a snap scan. The preson paying the bills already has one of these and it does work well. It would be nice to be able to integrate it into the workflow.
That being said, I do not have any qualms buying a TWAIN compliant scanner and integtrating that into the workflow as described by Gordon. This, at least so far, appears to be the solution that would require the least scripting, minimul plug-in integration and probably the most natural user interactions...
My biggest concern is getting too dependent on multiple file oriented scripting using a plugin. In my experience, a simple elegant solution usually holds up a little better with time.
I did manage to get this method to work with an Automator generated app called from the SnapScan. It leveraged, however, a Automator plugin. The files generated by the "bulk" scan of documents are then passed to the workflow and the the workflow then runs once for each document.
This would probably work well (though the order of the documents appears to get rearranged withn the workflow, probably because of their names in the filesystem) and now I have to decide if this method is better than importing directly into a container with a TWAIN compliant scanner as described by Gordon. Both solutions have their advantages and disadvantages. Both solutions are fairly elegant and have minimal script-logic to worry about (which appeals to me).