Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. .NET (Core and Framework)
  4. Barcode type recognision

Barcode type recognision

Scheduled Pinned Locked Moved .NET (Core and Framework)
comquestion
8 Posts 5 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • P Offline
    P Offline
    paper67
    wrote on last edited by
    #1

    Hi, I am working on an application that is able to read data from a keyboard wedged barcode scanner. I want the barcode that is scanned to be displayed in a picture box in my form. I use the code discribed in http://www.codeproject.com/KB/macros/BarcodeLibrary.aspx to draw the barcode. Therefore I need 2 things : 1) the data to be encoded. 2) the type of the encoding (Code39, Code128, UPC A, UPC E, EAN13 etc..) Since most barcode scanners are able to read several barcode types, is it possible to determine the type of the encoding the barcode reader uses to generate the data from a barcode image? TIA

    L M S 3 Replies Last reply
    0
    • P paper67

      Hi, I am working on an application that is able to read data from a keyboard wedged barcode scanner. I want the barcode that is scanned to be displayed in a picture box in my form. I use the code discribed in http://www.codeproject.com/KB/macros/BarcodeLibrary.aspx to draw the barcode. Therefore I need 2 things : 1) the data to be encoded. 2) the type of the encoding (Code39, Code128, UPC A, UPC E, EAN13 etc..) Since most barcode scanners are able to read several barcode types, is it possible to determine the type of the encoding the barcode reader uses to generate the data from a barcode image? TIA

      L Offline
      L Offline
      leckey 0
      wrote on last edited by
      #2

      ...

      Shhhhh..... http://craptasticnation.blogspot.com/[^]

      1 Reply Last reply
      0
      • P paper67

        Hi, I am working on an application that is able to read data from a keyboard wedged barcode scanner. I want the barcode that is scanned to be displayed in a picture box in my form. I use the code discribed in http://www.codeproject.com/KB/macros/BarcodeLibrary.aspx to draw the barcode. Therefore I need 2 things : 1) the data to be encoded. 2) the type of the encoding (Code39, Code128, UPC A, UPC E, EAN13 etc..) Since most barcode scanners are able to read several barcode types, is it possible to determine the type of the encoding the barcode reader uses to generate the data from a barcode image? TIA

        M Offline
        M Offline
        Mike Dimmick
        wrote on last edited by
        #3

        Barcode scanner hardware is generally able to read any barcode of a particular layout. 'One-dimensional' readers such as wands (which look like a pen you 'draw' along the length of the symbol) and lasers can generally read any one-dimensional code, that is, where the symbol consists of a sequence of parallel lines of varying thicknesses and spacing, and some can read two-dimensional codes which consist of a stack of one-dimensional codes, such as PDF or DataMatrix. The new Reduced Space Symbology, recently renamed DataBar, may be too new for some scanners - they may need a firmware upgrade. Imagers, which simply take an image in the same way as a digital camera, can generally handle both 1D and 2D barcodes. They struggle if the barcode is very long, though, as the scanner needs to be placed a long way from the code to fit it all in to the image, and then the resolution of each line is not very good, making measurement of the bars and spaces difficult. Most methods of encoding - referred to as symbologies - are self-checking, meaning that the scanner just won't return anything, rather than returning incorrect data. The different symbologies are designed for different purposes. For example, UPC and EAN are for encoding Global Trade Item Numbers, basically Stock Keeping Unit codes which identify a product in retail. That's their sole purpose and they shouldn't be used for anything else. If you're marking a product for sale by high-street retailers, you need a GTIN for your product, which means you need to register with your local GS1 Member Organization[^] to get a Company Prefix, a range of item numbers assigned to you. If you're in the US, this will be a UPC; if abroad, an EAN. In fact the two symbologies are the same thing, except that EAN changes the parity of some of the bars in the left-hand half of the code to encode the first digit. The original UPC parity scheme represents a '0' in EAN, the country code for the US in the GS1 system. If your item is a book, it should have an ISBN (International Standard Book Number) and the barcode should be derived from that. A book barcode is an EAN, and traditionally started 978, then the first 9 digits of the ISBN (the tenth was a check character), then the EAN check digit. Because the 10-digit ISBN is close to being exhausted, new books are getting an 'ISBN-13' which is simply a GTIN; in future a new prefix will b

        P S 2 Replies Last reply
        0
        • M Mike Dimmick

          Barcode scanner hardware is generally able to read any barcode of a particular layout. 'One-dimensional' readers such as wands (which look like a pen you 'draw' along the length of the symbol) and lasers can generally read any one-dimensional code, that is, where the symbol consists of a sequence of parallel lines of varying thicknesses and spacing, and some can read two-dimensional codes which consist of a stack of one-dimensional codes, such as PDF or DataMatrix. The new Reduced Space Symbology, recently renamed DataBar, may be too new for some scanners - they may need a firmware upgrade. Imagers, which simply take an image in the same way as a digital camera, can generally handle both 1D and 2D barcodes. They struggle if the barcode is very long, though, as the scanner needs to be placed a long way from the code to fit it all in to the image, and then the resolution of each line is not very good, making measurement of the bars and spaces difficult. Most methods of encoding - referred to as symbologies - are self-checking, meaning that the scanner just won't return anything, rather than returning incorrect data. The different symbologies are designed for different purposes. For example, UPC and EAN are for encoding Global Trade Item Numbers, basically Stock Keeping Unit codes which identify a product in retail. That's their sole purpose and they shouldn't be used for anything else. If you're marking a product for sale by high-street retailers, you need a GTIN for your product, which means you need to register with your local GS1 Member Organization[^] to get a Company Prefix, a range of item numbers assigned to you. If you're in the US, this will be a UPC; if abroad, an EAN. In fact the two symbologies are the same thing, except that EAN changes the parity of some of the bars in the left-hand half of the code to encode the first digit. The original UPC parity scheme represents a '0' in EAN, the country code for the US in the GS1 system. If your item is a book, it should have an ISBN (International Standard Book Number) and the barcode should be derived from that. A book barcode is an EAN, and traditionally started 978, then the first 9 digits of the ISBN (the tenth was a check character), then the EAN check digit. Because the 10-digit ISBN is close to being exhausted, new books are getting an 'ISBN-13' which is simply a GTIN; in future a new prefix will b

          P Offline
          P Offline
          Pete OHanlon
          wrote on last edited by
          #4

          :wtf: OK - this has to be your most comprehensive answer to date.

          Deja View - the feeling that you've seen this post before.

          My blog | My articles

          M 1 Reply Last reply
          0
          • P Pete OHanlon

            :wtf: OK - this has to be your most comprehensive answer to date.

            Deja View - the feeling that you've seen this post before.

            My blog | My articles

            M Offline
            M Offline
            Mike Dimmick
            wrote on last edited by
            #5

            Well, when you've worked with barcodes for seven years, you pick a few things up!

            DoEvents: Generating unexpected recursion since 1991

            P 1 Reply Last reply
            0
            • M Mike Dimmick

              Well, when you've worked with barcodes for seven years, you pick a few things up!

              DoEvents: Generating unexpected recursion since 1991

              P Offline
              P Offline
              Pete OHanlon
              wrote on last edited by
              #6

              That's fair enough, but for somebody who's renowned for giving comprehensive answers you've outdone yourself this time.

              Deja View - the feeling that you've seen this post before.

              My blog | My articles

              1 Reply Last reply
              0
              • P paper67

                Hi, I am working on an application that is able to read data from a keyboard wedged barcode scanner. I want the barcode that is scanned to be displayed in a picture box in my form. I use the code discribed in http://www.codeproject.com/KB/macros/BarcodeLibrary.aspx to draw the barcode. Therefore I need 2 things : 1) the data to be encoded. 2) the type of the encoding (Code39, Code128, UPC A, UPC E, EAN13 etc..) Since most barcode scanners are able to read several barcode types, is it possible to determine the type of the encoding the barcode reader uses to generate the data from a barcode image? TIA

                S Offline
                S Offline
                supercat9
                wrote on last edited by
                #7

                Some scanners that connect via serial port or PS/2 keyboard port can be configured so as to prefix each data record with a character indicating the encoding. This will likely cause problems with any application that doesn't expect such a thing. I would expect/hope that USB-based readers could be configured so that an application that was interested in the encoding on a barcode could ask, while those that weren't interested wouldn't be bothered with the information. Actually, what would be ideal would be if a USB-based reader had a driver that could be configured to behave differently based upon what application was open, but I haven't looked into whether such things were possible.

                1 Reply Last reply
                0
                • M Mike Dimmick

                  Barcode scanner hardware is generally able to read any barcode of a particular layout. 'One-dimensional' readers such as wands (which look like a pen you 'draw' along the length of the symbol) and lasers can generally read any one-dimensional code, that is, where the symbol consists of a sequence of parallel lines of varying thicknesses and spacing, and some can read two-dimensional codes which consist of a stack of one-dimensional codes, such as PDF or DataMatrix. The new Reduced Space Symbology, recently renamed DataBar, may be too new for some scanners - they may need a firmware upgrade. Imagers, which simply take an image in the same way as a digital camera, can generally handle both 1D and 2D barcodes. They struggle if the barcode is very long, though, as the scanner needs to be placed a long way from the code to fit it all in to the image, and then the resolution of each line is not very good, making measurement of the bars and spaces difficult. Most methods of encoding - referred to as symbologies - are self-checking, meaning that the scanner just won't return anything, rather than returning incorrect data. The different symbologies are designed for different purposes. For example, UPC and EAN are for encoding Global Trade Item Numbers, basically Stock Keeping Unit codes which identify a product in retail. That's their sole purpose and they shouldn't be used for anything else. If you're marking a product for sale by high-street retailers, you need a GTIN for your product, which means you need to register with your local GS1 Member Organization[^] to get a Company Prefix, a range of item numbers assigned to you. If you're in the US, this will be a UPC; if abroad, an EAN. In fact the two symbologies are the same thing, except that EAN changes the parity of some of the bars in the left-hand half of the code to encode the first digit. The original UPC parity scheme represents a '0' in EAN, the country code for the US in the GS1 system. If your item is a book, it should have an ISBN (International Standard Book Number) and the barcode should be derived from that. A book barcode is an EAN, and traditionally started 978, then the first 9 digits of the ISBN (the tenth was a check character), then the EAN check digit. Because the 10-digit ISBN is close to being exhausted, new books are getting an 'ISBN-13' which is simply a GTIN; in future a new prefix will b

                  S Offline
                  S Offline
                  supercat9
                  wrote on last edited by
                  #8

                  Mike Dimmick wrote:

                  Imagers, which simply take an image in the same way as a digital camera, can generally handle both 1D and 2D barcodes.

                  FYI, there's a third category of reader (probably not used so much anymore, now that imagers have become cheaper): raster-scanning lasers can scan 1D barcodes and PDF-417 but not other 2D symbologies. PDF-417 is designed so that it can be read by combining many independent one-dimensional reads. If a particular read crosses from one 'row' to the next, the character on which the crossing occurred will not be read, but the system will detect the crossing and can thus properly assign the following characters to the appropriate row. I mention this for a few reasons: -1- I think PDF-417 is a really cool technology which, although it's obsolete, still deserves to be appreciated and marveled at. -2- While I don't know the market situation, I would not be surprised if used raster-scanning lasers are or will be available cheaper than other imaging technologies. If information capacity is more important than small symbol size, using PDF-417 may allow one to equip one's shop with compatible readers more cheaply than other symbologies. -3- With a firmware upgrade, a line scanner that has enough memory should be able to handle PDF-417 barcodes if the user waves the scanner slowly over the barcode a few times, though I'm not aware of any that do. This might make an interesting hobby project, though. -4- PDF-417 barcodes are physically larger than other 2D barcodes with similar information content; it may be nice to understand why.

                  1 Reply Last reply
                  0
                  Reply
                  • Reply as topic
                  Log in to reply
                  • Oldest to Newest
                  • Newest to Oldest
                  • Most Votes


                  • Login

                  • Don't have an account? Register

                  • Login or register to search.
                  • First post
                    Last post
                  0
                  • Categories
                  • Recent
                  • Tags
                  • Popular
                  • World
                  • Users
                  • Groups