Dosadi on Brother

{MainCell}

vendor:

Brother (Brother Industries)

Atalasoft is not affiliated with this manufacturer.

website:

comments:

Brother is a puzzle to us. They offer literally hundreds of MFC models that include scanning capability, many have document feeders - relatively slow but functional and reliable. These devices are typically substantially less expensive than dedicated document scanners. They could be the brand of choice for low-volume TWAIN document scanning, which is a potential need in... let's see... nearly every office and household in the US.

But no. So far, we have not encountered a Brother scanner that we can recommend for TWAIN scanning. They either lack native TWAIN drivers completely, relying on the buggy Microsoft WIA-TWAIN bridge, or - they have buggy native TWAIN drivers. The classic Brother TWAIN bug: When asked to scan a stack of pages without showing its own UI the Brother cheerfully does so - and then delivers only the first (or last) page to the application.

We recommend using/supporting Brother scanners:

A. ...if you verify that the specific Brother model works with your application. Please let us know!
(Don't assume that any other model, no matter how similar looking, will work the same way.)

B. ...if

(1) low cost for the scanning function is very important to you,
(2) scanning speed is not very important, and
(3) you don't mind displaying the scanner's user interface (the device-specific scan dialog)

See issues below.

devices:

Although Brother offers dozens of models, very few are explicitly listed by Brother as having TWAIN support.

issues:

Model(s)	Issue
Multiple MFC models	When scanning multiple pages from the ADF with the scan dialog hidden, only the last page is delivered to the application. There is no known work-around: When the unit is asked to scan it feeds all pages, but delivers only the last to the application.
	After each scan from the feeder, the device indicates that there are more pages available. Once the feeder goes empty, when the application requests the (imaginary) next page, the driver returns TWRC_CANCEL/TWCC_SUCCESS i.e. "User cancelled transfer." There is no way to distinguish this from an actual user cancel during normal scanning.
MFC-5840CN	Setting ICAP_PIXELTYPE does not update the value of ICAP_BITDEPTH.
	CAP_XFERCOUNT is initally 0 (!) and cannot be set to -1. MSG_RESET sets it to 0. It can be set to a positive integer, and during scanning it magically changes to 32767. Extremely silly bugs.
	Setting CAP_FEEDERENABLED to TRUE or FALSE returns failure (TWRC_FAILURE/TWCC_BUMMER) - but selects the feeder anyway.
	Querying CAP_FEEDERLOADED always returns TRUE, whether there is paper in the feeder or not.
	With the user interface suppressed, selecting the feeder has no effect: The device always scans from the flatbed.

features:

Twister Reports: MFC 9070

EZTwain