Incorrect Code39 and PDF417 Barcode Results

Aspose.BarCode Product Family
1

Hi, we are doing a POC with the aspose barcode reader , and found that the barcode engine sometimes returns an incorrect string value for Code39 and PDF417 barcodes. If we use zxing or other 3rd party libraries, we get the correct value. I see there is a few posts about the same issue and just wondering if this is a known issue, and if there is ways to prevent this from happening? I am not allowed to share the documents in question.

Thanks.

2

@RynoSchmidt

Could you please provide more details about the specific barcode values you are getting and the expected values? Additionally, any code snippets you are using would be helpful.

3 
using (BarCodeReader code39_reader = new BarCodeReader(bitmap, DecodeType.Code39, DecodeType.Code39FullASCII))
{
    foreach (BarCodeResult result in code39_reader.ReadBarCodes())
    {
        code39_text = result.CodeText;
    }
}

I’m expecting the value 8501225802080, but I get 85VXSLB02080 .

4

@RynoSchmidt,

Could you please provide your barcode image so we can test your issue and log an appropriate ticket (if we find an issue) for it.

5

@amjad.sahi , I will try and find a barcode image and share it soon. I just want to know if this is a known issue that you are aware of ?

6

@RynoSchmidt,

This is not a known issue. Please take your time to get the barcode image and provide us.

7

Hi @amjad.sahi , our process is as follows:
Take the original PDF and create a raster image with default, 100, 200 and 300 DPI.
Foreach of these DPI configs, we scale the Image 1.5 then 2 times (multiply the bitmap width and height by the value). We also convert the image to grayscale. After each step, we send the image to the barcode engine to decode. We have many different scenarios for different documents, each returning different values. At some point in the process, the barcode engine returns the correct value, but it all depends on the quality of the original document, and this makes it hard for us to be confident in the results.

I’ve attached 4 files. The original pdf, and the raster images where the engine returned incorrect values. The expected value for the code39 is “9901295208086”.

  1. 100DPI returned “ABOSSC2V”
  2. 100DPI_Grayscale_1.5x returned “97V-SC27”
  3. 100DPI_Grayscale_2x returned “9901295.V”

Original.pdf (421.2 KB)

1. 100DPI.jpg (67.0 KB)

2. 100DPI_Grayscale_1.5x.jpg (78.2 KB)

3. 100DPI_Grayscale_2x.jpg (122.7 KB)

8

@RynoSchmidt,

Thanks for the barcode images and PDF document.

After initial testing, I am able to reproduce the issue using your barcode images as you mentioned. We require thorough evaluation of the issue. We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): BARCODENET-39159

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

9

At first our engine supports recognition from images and pdf documents from 300 dpi. Image recognition with 200 or 100 dpi is just bonus and it is not guarantied.

The second. PDF417 is a barcode with strong checksum (Reed–Solomon error correction) and correct recognition of the code is confirmed by barcode standard. Code 39 is the 1D code, invented in 1974 without default checksum, and after the possible barcode recognition we cannot check is it correct.

However, we will publish big 1D recognition improvement in 24.11 or 24.12 (December) version where Code39 problem (incorrect recognition) can be partially solved with heuristic methods.