You are here
The Joliet file system specification allows for file names of 128 characters or 64 Unicode characters
The original ISO 9960 system allowed for a maximum of 31 characters
The following is from a website discussing CD file systems to use when using long file names on CD
"Use the ISO 9660:1999 filesystem. Also known as ISO Level 2 Long, 9660:1999 is a variant of the ISO 9660 file system standard that has better support for long file names. It supports pathnames up to 207 characters long and allows for directories to be nested more than eight deep.
The only downside here is that a disk created in this format might not be readable on all computers. Although it's supported by most applications that burn to CD, for instance, Nero 6 and higher, some applications do not support burning ISO 9660:1999 to DVD.
Use the UDF filesystem. UDF is another commonly supported mass storage file system that doesn't have Joliet's length restrictions. UDF 1.5 and higher can support individual file names of 255 bytes and a maximum pathsize of 1023 bytes.
The downside here is that many systems still don't read UDF natively. But if you're only reading the discs in a system that can (Windows XP can read UDF natively), this shouldn't be a concern."
Information on the CD file system formats available and how to apply those settings to use those formats in your CD burning software should be available on the related software manufacturers website. If you would prefer to (or have no alternative than to) use the Joliet file system then you can limit the length of the file names in EzeScan by either
a) Un-checking the "Store Images with Original Filenames" option on the EzeScan Upload Admin form (F8)
b) Using a length limited KFI Index field for the file name (This can be made up of other existing indexes)Direct link to FAQ
EzeScan PC / Server specifications can change depending on your scanning requirements. A suitable machine for scanning large volumes of colour documents will differ from a machine intended mainly for black & white scanning or KFI indexing. Please feel free to contact us if you require more assistance with specifying your EzeScan PC hardware.
EzeScan can be configured to work on 32-bit or 64-bit Windows operating systems.
- On 32-bit Windows operating systems, EzeScan will use 32-bit TWAIN scanner drivers, and will work with USB or FireWire connected scanners.
- On 64-bit Windows operating systems, EzeScan will still use 32-bit TWAIN drivers. Our testing shows that 32-bit TWAIN drivers for USB-connected scanners function well on a 64-bit operating system. Microsoft's 64 to 32 bit USB driver translation layer allows the scanner to work as expected. However during our testing we found that 32-bit TWAIN drivers for FireWire-connected scanners will not always work on 64-bit Windows operating systems (unless the scanner Vendor has certified their driver to do so)
Below is a minimum specification for EzeScan PRO desktop installations.
- Intel™ Core i7 3.06 GHz i7-950 or AMD equivalent processor
- 8GB Ram
- 250GB SSD
- 1000 Mbps Ethernet (for network scanners or to store to EDRMS / network repositories)
- A video controller with at least 512MB RAM
- Monitor supporting at least 1600 x 1280 pixel resolution
- Microsoft Windows client operating systems that support Microsoft .NET Framework Version 4.7.1 and above.
- USB or SCSI connection for scanner (USB 2.0 recommended)
- A TWAIN or ISIS compliant scanner (please refer to our supported scanner list)
For high volume production environments we recommend the fastest quad core Intel CPU (with hyperthreading). The latest i7 5th generation CPU's perform well. Minimum of 16GB of RAM. We recommend using a motherboard that supports the RAM operating at 2133GHZ. The operating system should be run from an SSD, not a HDD or a hybrid HDD/SSD.
Please note: Installing EzeScan on poorly spec'ed equipment may compromise processing speed. We highly recommend using the minimum specifications as listed above. For production environments, in particular when processing large documents we recommend using EzeScan SERVER to carry out document enhancements and OCR as a background task.
Below is a minimum specification for an EzeScan SERVER (Routing).
- Intel Xeon CPU or AMD equivalent (2 cores running at 2.00Ghz minimum)
- 8GB Ram
- 250GB HDD, preferably SSD.
- 1000 Mbps Ethernet (for network scanners or to store to EDRMS / network repositories)
- Microsoft Windows Server operating systems that support Microsoft .NET Framework Version 4.7.1 and above.
Note: This is for a single instance of EzeScan SERVER. Additional instances may be required to provide acceptable processing speeds. The additional instance(s) will require more RAM (a minimum of 16GB of RAM should be installed when running 2-3 instances)
For high volume production environments we recommend deploying a server that supports multiple CPU's. Choose the fastest clock speed Intel E5-2600 version 3 CPU's (with hyperthreading) and the maximum number of cores that you can afford. Minimum 32GB of RAM per CPU installed. Use the highest speed RAM that will operate with the CPU. The operating system should be run from an SSD, not a HDD or a hybrid HDD/SSD.
Below is a minimum specification for an EzeScan WebApps (if EzeScan SERVER is going to be installed on the same server then please note the specifications above)
- Windows Server 2019, Windows Server 2016 or Windows Server 2012 R2 (64-bit edition).
- IIS Application pool running ASP.Net 4.7.1 framework.
- IIS Needs the following role services enabled/installed:
- Application Development
- .NET Extensibility
- ISAPI Extensions
- ISAPI Filters
- Ensure that all windows updates have been installed
Please note: The following PowerShell command can be used to enable/install the IIS features needed
Add-WindowsFeature -Name Web-Server,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Static-Content,Web-Health,Web-Http-Logging,Web-Performance,Web-Stat-Compression,Web-Security,Web-Filtering,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Mgmt-Tools,Web-Mgmt-Console,NET-Framework-45-Features,NET-Framework-45-Core,NET-Framework-45-ASPNET
EzeScan Authority Server
Below is a minimum specification for an EzeScan Authority Server. The EzeScan Authority server is a management tool used to centralise licensing and configurations.
- A minimum of two cores.
- Microsoft Windows operating systems that support Microsoft .NET Framework Version 4.7.1 and above
- Two open ports for the client and server to communicate (default is 32356 and 32380 and the installer will create the firewall rule)
- A Windows share for ease of configuration backup and maintenance
Information Links for Microsoft .Net and Windows 10 versioningDirect link to FAQ
To move the default processing and configuration paths for EzeScan please refer to the following:
The override.ini file in "C:\Program Files (x86)\Outback Imaging\EzeScan\Resources" will need to be copied to "C:\Program Files (x86)\Outback Imaging\EzeScan"
by default typical override.ini file might contain:
[Folder Paths] ;Common Data=C:\programdata\Outback Imaging\EzeScan
Common Data - Defines where EzeScan creates it working files. Defaults to C:\programdata\Outback Imaging\EzeScan
Comment out the ; and update the path to another drive folder.
Save the Override.ini back into C:\Program Files (x86)\Outback Imaging\EzeScan and restart EzeScan.
Please note: The operator will need to re import the jobs in the newly created path. Please refer to FAQ 22 on how to backup and restore EzeScan.Direct link to FAQ
You have installed EzeScan PRO and you are running it with either a PRO Demo license or PRO+BCR license. When you try to run a job that is setup to profile documents based on using barcodes, Ezescan pops up an error message that says you are unlicensed for the the Barcode module even though the BCR license is installed.
This happens if you are running EzeScan as a user account that does not have local admin rights. The barcode dll's used by EzeScan are not fully registered until the barcode module is run. So if you install EzeScan with local admin rights, but do not run a job using barcoding then the barcode dll's are not fully registered.
Then if you switch to a user that does not have local admin rights and try and run a barcode job you'll get the error about not being licensed for the BCR module.
There are 2 ways to fix this problem:
- Close Ezescan. Logout from windows. Login to windows as a user who has local admin rights. Run Ezescan. Run the barcode job. The barcoded thumbnail pages should be highlighted with yellow borders and you should not see any barcode licensing errors.
- Assign the user local admin rights.
If this works okay then you can simply close Ezescan, logout from windows, login as the original user that does not have local admin rights, start EzeScan and rerun the barcode jhob. It should now work okay.
On the SQL Server:
1. Ask the SQL Server DBA to create a database called ezescan_audit for you.
2. The ezescan_audit database will contain 4 tables (Completed_Work, Current_Work, Deleted_Work and Routed_Work).
3. There is a database table creation script for SQL Server that can be used by the DBA to create the 4 tables. Look under Downloads->Application Patch Updates. Download and run the applicable script.
4. Create an ezescan user, and set the password for now to ezescan. You can change the password later once it's all working. Don't forget to do this!
5. Grant the ezescan user all rights to the 4 tables (Completed_Work, Current_Work, Deleted_Work and Routed_Work) in the EzeScan Audit database.
6, Using a SQL test program, make sure that the ezescan login/password can successfully connect to the ezescan_audit database, and perform a select * query on each of the 4 tables (Completed_Work, Current_Work, Deleted_Work and Routed_Work).
On each EzeScan PC that is going to use the remote Audit Database:
7. Make sure the SQL client for SQL Server is installed on the each PC.
8. Configure a SQL client connection called ezescan_audit and connect it to the remote ezescan_audit database running on the SQL Server. Using a SQL test program, make sure that the ezescan login/password can successfully connect to the ezescan_audit database, and perform a select * query on each of the 4 tables (Completed_Work, Current_Work, Deleted_Work and Routed_Work).
9. Configure an ODBC connection called ezescan_audit. This will use the underlying SQL client connection configured in step 7. Using an ODBC test program, make sure that the ezescan login/password can successfully connect to the ezescan_audit database, and perform a select * query on each of the 4 tables (Completed_Work, Current_Work, Deleted_Work and Routed_Work).
10. By default EzeScan uses a local ezescan_audit database located in a MS Access database file called Ezescan_Audit.mdb.
Please note that Auditing is only enabled if the workstation is running with a PRO evaluation license, or a Production license with the AUDIT module enabled.
11. Use the Ezescan Admin->Options form, Audit tab settings to change the Audit datbase from using an MSAccess database file to using an ODBC connection to a remote database server. Tick the 'Use ODBC' option, and enter the following details for the ODBC connection:
ODBC DSN = ezescan_audit , ODBC User = ezescan ,ODBC password = the password you configured
Save and close the Admin-Options form.
Please note that Use ODBC option should only be used with a remote SQL Server. Do not use this option with a MS Access database. We do NOT currently support Oracle Server.
12. For each job/route that you want auditing enabled for, you'll need to enable the 'Update Audit Database' option. This can option can be found on the Job Admin form Profiling tab, or on the Route Admin form Logging tab.
13. Run one of the jobs/routes that has had 'Update Audit Database' enabled.
14. Then use the Admin->Audit Reporting from to run the completed Work report for that job/route. A web browser based activity report should appear on the screen. The report should contain at least 1 row of details for every document processed by that job/route.Direct link to FAQ
Yes, it is possible to do this using the existing Job Admin form, Commit button functionality in Ezescan.
You need to setup 2 specific things in EzeScan to do this.
- Specify where the images are sent once they are profiled.
On the Job Admin form, Output tab you will need to set the following settings:
Specify the job Output Directory e,g, n:\lodge\ret\peter\build\
Other Destination = None
On the Job Admin Form, Output tab press the output Options button. On the output Image Options form, Commit Document frame set the following settings:
Tick Enable Commit Document Processing To.
Specify the folder path where commit documents are to be saved e.g. n:\lodge\ret\peter\commit
Tick Don't Create Images.
Tick Prompt For Filename.
Enter the following in the Command Line And Arguments field.
c:\progra~1\winzip\wzzip.exe -m n:\lodge\ret\peter\commit\<<CFN>> n:\lodge\ret\peter\build\*.tif
When the Commit Button is pressed during production , it would normally simply move the files from the job output directory to the commit directory. When the "Don't Create Images" option is ticked, this file move is skipped, and the wzzip.exe command line instead zips the images and places the resulting zip file into the commit directory. The variable <<CFN>> is replaced by the filename value that the user enters at the Filename Prompt question.
Note 1: You'll need the command line add on for winzip which is normally available from the winzip downloads area. The command line add on will install the wzzip.exe program.
Note 2: wzzip.exe uses only short path/file names. So if your path/file names are longer than 8 characters you'll need to trunacte them down to use the first 6 characters followed by ~1 (or in rare cases ~2 or ~3).Direct link to FAQ
EzeScan would normally expect the operator to configure only one action (e.g. scan, import file, import folder, commit) to a job that runs on a Job button.
However if more than 1 action is enabled then Ezescan uses the following priority list to decide which action will be run, and which ones will be ignored.
a.k.a. How To Implement Dynamic KFI's
In EzeScan versions before 4.1 only one KFI could be associated with any given job. It was not possible to change the KFI definition part way through the job. As a result, users had to pre-sort their images into batches that would all use the same KFI index.
On the Job Admin form you could only select one KFI type and one Upload type per job (as below). It was also not possible to pass field values between fields in other KFI types.
In EzeScan 4.1 a new feature called Dynamic KFI lets users switch to a different KFI during processing, and this FAQ shows you how to set it up.
As with previous versions of EzeScan, create each working Job+KFI+Upload combination using the same steps that are documented in our KFI and UPLOAD user guide addenda. Then, for each KFI that will be used as a Dynamic KFI, complete the following steps.
- In the Job Admin form on the Output tab, set th0e upload type for the job to None/Blank, as below.
- Also on the Output tab, tick the "Allow Change Of KFI" box, then save your changes.
- Go to the KFI Admin form's Output tab, where you can link this KFI to the required UPLOAD type (as below). Apply your changes.
- (Optional) You may also have some index fields that you want to share between each KFI. In this case you can assign a field to load/save its field value from/to a global variable (as below). There are 10 numbered locations that you can save field values into. Once you have chosen a global variable for the field, click OK to save your changes.
Once you have completed the steps 1-4 above for each KFI involved in the job processing, test by running the job and loading a document into the viewer.
- Press F4 to bring up the KFI Indexing Panel. The KFI type that is displayed initially is the one that is assigned to the Job on the Job Admin form's Output tab, in the KFI Type list. A new KFI button and label tell you which KFI is currently in use.
- To change the KFI associated with this document, click the KFI button. Select a new KFI from the list and click OK:
- The KFI indexing panel gets reloaded with the new KFI's first index and the KFI commences processing the field:
- When you click the Submit button, the code checks to see which Upload type has been linked to the currently selected KFI. It then runs that upload type and loads the document and metadata in the backend system. The next document is then displayed to the operator, who can either use the existing KFI or choose another one.
Steps 5-8 will repeat until no more documents are available to display.Direct link to FAQ
Where column 1 is the form TYPE, and column 2 is the form DESCRIPTION.
To do this use the Control->Panel->Administrative Tools->Data Sources(ODBC) option to start the ODBC Data Source Administrator form. Then create a System DSN using the Microsoft Text Driver . The ODBC Text Setup form is displayed. Set the Data Source Name to Formtypes.
Then Untick 'Use Current Directory'. Then press Select Directory and browse to the c:\Documents and Settings\All Users\Application Data\Outback Imaging\Lookups directory and press OK (Please Note that in some cases you might not be able to see this directory until you remove the hidden attribute on the :\Documents and Settings\All Users\Application Data directory).
Press the Options>> button and then press the Define Format button. in the list of tables select Formtypes.txt and then press Guess. Press OK. Ignore the error message that says "Failed to save the attributes of (null) into (null)" - its a Microsoft issue.
Press OK to close the ODBC Text Setup form. Close the ODBC Data Source Administrator form. If you now look in the c:\Documents and Settings\All Users\Application Data\Outback Imaging\Lookups directory there is now a new file called schema.ini that contains:
Col1=TYPE Char Width 255
Col2=DESCRIPTION Char Width 255
Close the editor, saving the changes.
select TYPE from formtypes.text
select DESCRIPTION from formtypes.txt
select DESCRIPTION from formtypes.txt where TYPE='001'
select DESCRIPTION from formtypes.txt where TYPE='<<F1>>'