Veröffentlicht Mon, 14 Oct 2019 12:49:51 GMT von Kim Sims Sr. Solution Integrator
Client bar code recognition is seeing a failure rate around 20%. After manipulating the import configuration multiple times, I can't seem to make much difference in the recognition rate.
I see there is an option available through v6.11 that could have significant impact on it. 

Is this supported in v7.1? Or is there another option?
Veröffentlicht Mon, 14 Oct 2019 13:14:47 GMT von Joe Kaufman Bell Laboratories Inc Application Development Manager

Hi, Kim, long time no see!

Just a bit over two years ago after initial roll-out (a Fortis migration that you assisted with), we were seeing a 5-10% failure rate of barcodes as well, on everything from splitter/ID barcodes to index fields (we use a lot of barcoded scan sheets). One of our scan sheets has something like 20 barcodes on it.

I spent two days testing batch after batch, just trying to increase accuracy. I ran across the same article you found, but it didn't go deep enough. DocuWare support was, in a word, unsupportive. They did tell me more about some of the other VintaSoft settings, but basically said don't mess with them (or gave a standard, "Well, if you do touch them you are on your own, and they won't make any difference anyway.") They were wrong.

It took me a long time to start tweaking the ExpectedNoBarcodes setting because I thought it meant that the import should expect "no" barcodes. Turns out it is just a really stupidly named parameter that means "expected NUMBER of barcodes", and it was set to 0 by default (because, remember, it wasn't supposed to have any effect on anything anyway). I also researched that the higher the number, the more it could affect performance.

The bottom line is that everyone was wrong. I upped ExpectedNoBarcodes to 99, and BAM! The next three test runs I did had 100% barcode accuracy, and the scan job did not run appreciably slower. And we have seen pretty much 100% accuracy for 2 years now. Some printers still print unreadable separator/ID barcodes (which is weird), but by and large we are chugging through thousands of barcodes a day with perfect scanning.

Below are the notes I took about the additional fields in the VintaSoft settings (with my ExpectedNoBarcodes comments asterisked):


10/06/2017 - Additional information from DocuWare tech support:

TradeOff is the option which tries to bring together speed and quality. The possible values are BestSpeed, Balanced, BestQuality. In case barcodes are not recognized (especially smaller barcodes) then switch to BestQuality. This will decrease performance and increase the average number of recognized garbage barcodes. Changing the trade off can make things better, but also worse. So be careful. When changing the trade off the quality threshold should be adapted (the higher the trade off the lower the quality threshold).

All other mentioned setting should not be touched, that's why they are not included in the faq.

Possible values are: any integer number equal or larger than zero
Default value: 0
*** Set this value to 99 to make sure the VintaSoft engine reads all barcodes on a page and doesn't stop prematurely! ***

Possible values are: 0.00 - 1.00
Default value: 0.20

Possible values are: 0.00 - 1.00
Default value: 0.95

Here is the full VintaSoft.settings file we use, where we have everything commented out except Code128 barcodes:

<?xml version="1.0"?>
<BarcodeSettings xmlns:xsi="" xmlns:xsd="" TradeOff="BestSpeed" MinimalBarcodeLength="1" ExpectedNoBarcodes="99" RenderResolution="300" Iso15415Threshold="-1.0" Iso15416Threshold="-1.0" QualityThreshold="0.2" ConfidenceThreshold="0.95" Erode="false" AutomaticMode="true" xmlns="">
    <!--<BarcodeType DwBarcodeType="C25Interleaved" />-->
    <!--<BarcodeType DwBarcodeType="Code39" />-->
    <BarcodeType DwBarcodeType="Code128" />
    <!--<BarcodeType DwBarcodeType="Ean128" />-->
    <!--<BarcodeType DwBarcodeType="EanExt5" />-->
    <!--<BarcodeType DwBarcodeType="EanExt2" />-->
    <!--<BarcodeType DwBarcodeType="Code93" />-->
    <!--<BarcodeType DwBarcodeType="Codabar" />-->
    <!--<BarcodeType DwBarcodeType="Ean13" />-->
    <!--<BarcodeType DwBarcodeType="Ean8" />-->
    <!--<BarcodeType DwBarcodeType="C25Industrial" />-->
    <!--<BarcodeType DwBarcodeType="UpcA" />-->
    <!--<BarcodeType DwBarcodeType="UpcE" />-->
    <!--<BarcodeType DwBarcodeType="Code11" />-->
    <!--<BarcodeType DwBarcodeType="MSI" />-->
    <!--<BarcodeType DwBarcodeType="RSS" />-->
    <!--<BarcodeType DwBarcodeType="Postal" />-->
    <!--<BarcodeType DwBarcodeType="PatchCode" />-->
    <!--<BarcodeType DwBarcodeType="Telepen" />-->
    <!--<BarcodeType DwBarcodeType="Aztec" />-->
    <!--<BarcodeType DwBarcodeType="DataMatrix" />-->
    <!--<BarcodeType DwBarcodeType="QR" />-->
    <!--<BarcodeType DwBarcodeType="PDF417" />-->
    <!--<BarcodeType DwBarcodeType="MaxiCode" />-->     
    <!--<BarcodeType DwBarcodeType="Pharmacode" />-->    
    <!--<BarcodeType DwBarcodeType="Code128" />-->
    <!--<BarcodeType DwBarcodeType="C25Interleaved" />-->
    <!--<BarcodeType DwBarcodeType="UpcE" />-->

I do not know how DW 7.1 does things on the Desktop, but hopefully you can still swap out the settings file, restart desktop services, and try to scan again. Hopefully it increases your accuracy.

Joe Kaufman
Veröffentlicht Mon, 14 Oct 2019 20:41:28 GMT von Kim Sims Sr. Solution Integrator
Thanks Joe. Long time no see.

I tried this solution, but, didn't really see any change.

After further digging, it was determined that the problematic barcode was to have reflected a single digit and it wasn't being written as a valid barcode. Due to length, I'm sure.

In the end, we mitigated the issue by using a separate store dialog and prepopulating that field with the single digit the system was looking for, and when a new document was imported containing a valid barcode that could be translated by DW, it will overwrite that field so it would store correctly.

I appreciate the pointers on the VintaSoft settings file. I've tucked it away for future use.

Thanks again.
Veröffentlicht Mon, 14 Oct 2019 21:22:23 GMT von Joe Kaufman Bell Laboratories Inc Application Development Manager

DocuWare can totally handle barcodes of length 1. That's what the setting:

in the VintaSoft settings file I posted is for. We have been handling single-character barcodes for two years now. Install a barcode reader on your phone and scan a single-character code -- should work, and should also work in DocuWare. Though, it is possible the barcode-writing tool itself does not handle single-character codes, which would be a function of your barcode generator (ours handles them fine).

Sounds like your solution works just as well, though, and lots of devices and scanner have issues with single-character barcodes.

Joe Kaufman
Veröffentlicht Tue, 15 Oct 2019 12:01:19 GMT von Kim Sims Sr. Solution Integrator

Yeah, I tried that as well, but no joy.

It appears that their single character barcode is malformed as it isn't recognized by even the one-click index engine.

Research has shown that others have had issues with single digit barcodes, but, that it is possible.

Oh well, the workaround seems to be working flawlessly.

Thanks Joe

Veröffentlicht Tue, 15 Oct 2019 13:03:50 GMT von Joe Kaufman Bell Laboratories Inc Application Development Manager

Just to make sure folks aren't put off by the idea of single-character barcodes, I'd like to reiterate they work fine across the board as long as devices are configured for it. In DocuWare it is the setting described above, and for some barcode readers you may need to talk to support and get a special setting configured. I bought a Nadamoo USB barcode reader and had to email them about it. Overnight they sent me a system barcode I could print out and scan, and now the gun reads single-character barcodes (numeric or alphabetic) perfectly.

In any other scenario it is the fault of how the barcodes are being generated and/or the printer printing them. We use standard Code128 across the board, and I can read every barcode with my iPhone (no special changes needed), Android tablet (no special changes needed), Motorola industrial handheld computer (no special changes needed), USB scan gun (system barcode required), and DocuWare scanner (VintaSoft settings change).

I guess I would say single-character barcodes aren't just possible, they should be the norm. If it won't scan with RedLaser on an iPhone, the barcode itself is malformed and nothing will read it. Are they best to avoid or work around? Maybe, but that's not always possible. Even barcoding something like a first name means some folks will just have a single character there, e.g. just the initial.

Workarounds that work are wonderful though.  *smile*

Joe Kaufman

Sie müssen angemeldet sein um Beiträge in den Foren zu erstellen.