Home › Forums › TWAIN Classic › Invalid Compression Settings
- This topic has 4 replies, 2 voices, and was last updated 16 years, 10 months ago by gabe.
- AuthorPosts
It seems that drivers do not always modify the list of valid compressions you can use at a given time.
For instance, I have a Fujitsu fi-4120C that returns all of its compression modes no matter what transfer method, pixel type or file type is being used. This makes it impossible for a general application to know what option is valid. I also tested a Panasonic KV-S1025C that does the same thing.
I wrote a test that goes all possible combinations just to see what happens. For the most part, both scanners simply ignored the invalid settings and used a default. However, the Fujitsu crashed when the combination was a file transfer, grayscale or color, TIFF image format with JPEG compression. This is a valid file type (although one I tend to stay away from) so even limiting it to valid settings can cause issues.
I guess I’m ranting a little, but issues such as this should never happen. Doesn’t the specification state that the list of compressions should change based on these other capabilities? Anyone agree or disagree?
Yeah it’s on the bottom of page 435 in the twain2d.pdf. But are you really suprised but a vendor straying from the spec? Are the available values corrent from the vendor’s Ui?
but then maybe I’m looking at the wrong spec. what version of the spec is the device targeting?
Haha… I guess I shouldn’t expect the drivers to be correct.
Both scanners report supporting version 1.9. Their UI will only allow correct settings, but many people don’t want the UI displayed which is why I found it to be a problem.
ah. Enter my favorite rant: Don’t set the caps one-by-one. Let the users use the vendor’s Ui to set up the scanner. My users don’t want to see the vendor Ui either, at least not while they are scanning, but they don’t seem to mind seeing it to setup the device (or they talk about me when I leave, I gotta admit there is a strong possibility that is the case). Use EnableDsUiOnly to display the Ui, after the user closes the vendor ui (with and ok or save or whatever) you use CustomDsData.Get to gather all of the settings. Then when the users wants that ‘profile’ of a scan you enableDs and use CustomDsData.Set to config the scanner. In this fashion you skip all the cap getting/setting, the user get a consistant scan from your app and you don’t have figure out all of the custom caps. In most cases if there is some oddness in the vendor’s implementation of the spec their Ui has the best chance of getting it right.
You are still able to scan without a Ui coming up… well it doesn’t detract from that ability in that if the vendor supports it, it is still available.
And the disadvanages to setting caps one-by-one are many. Look thru the
questions and problems people have with twain in the on this site. The vast majority are the type you describe where the spec isn’t quite followed by the vendor and as a result getting the device to acquire is a pain. In the rare case where you get one device just right, what happens when your users get a new device? You go back to the table and figure out all of the particulars again? No. Least not me. I tell the users to get a scanner that supports EnableDsUiOnly and CustomDsData. I occationally get a user with a scanner that doesn’t support the caps I use. What follows is a short talk about the state of the world and the cost of custom development, it takes about 3 minutes and the user goes scanner shopping. If you like reading .net code and are looking for a sample I have my source posted over codeplex/openTwain..
- AuthorPosts