Home » Developing U++ » UppHub » [Barcode] Code128 & EAN13/UPC-A/EAN8 supported
| [Barcode] Code128 & EAN13/UPC-A/EAN8 supported [message #39253] |
Tue, 05 March 2013 23:59  |
Lance
Messages: 656
Registered: March 2007
|
Contributor |
|
|
2016-01-31 Support for ITF (interleaved 2 of 5) added.
2016-01-22 Attachment updated to accommodate change in UPP library (explicit selection of pick/clone) after introduction of C++11.
==========================
First of all. Sorry to sergeynikitin. I noticed that you already implemented Code128. You are one of the more active U++ contributors, and I fully respect you. I did this a few years back but never took time to polish it, so I just use it myself.
Anyways:
see screenshot for effect. the usage is pretty intuitive. Supports both Draw class and QTF with pretty natural way.
[Updated on: Sun, 31 January 2016 19:18] Report message to a moderator |
|
|
|
|
|
| Re: [Barcode] Code128 & EAN13 (Superset of UPC-A) supported [message #39256 is a reply to message #39254] |
Wed, 06 March 2013 13:30  |
Lance
Messages: 656
Registered: March 2007
|
Contributor |
|
|
Code128 is very compact, and supports full ASCII code set.
EAN13/UPC-A is widely used in retail. It might be desirable to add support for other EAN/UPC variations.
I have no use for other linear barcode.
PDF417 is very interesting, but there is no openly (freely) available documentation. (Unlike Code128 and EAN13 for which all details are available on Wiki). If anybody knows more details about PDF417 and is willing to share, please kindly let me know.
[Updated on: Wed, 06 March 2013 13:32] Report message to a moderator |
|
|
|
|
|
|
|
| Re: [Barcode] Code128 & EAN13 (Superset of UPC-A) supported [message #39272 is a reply to message #39264] |
Thu, 07 March 2013 15:14 |
Lance
Messages: 656
Registered: March 2007
|
Contributor |
|
|
Thank you, Deepak. They are very good. First one is LGPL, so basically we can use it if we keep it as a dll or so. It also allows MPL, it is more relaxed?
Second one has some easily understandable information. It will be more helpful if I decide to implement it myself.
Will take time to go through other links.
Thanks again.
=========================
The 3rd is fantastic! I am glad I asked. Fully appreciated, Deepak.
[Updated on: Thu, 07 March 2013 15:46] Report message to a moderator |
|
|
|
| Re: [Barcode] Code128 & EAN13/UPC-A/EAN8 supported [message #40611 is a reply to message #39253] |
Fri, 23 August 2013 10:03 |
|
|
|
hello, gays, I am glad to be here. I know this forum is about barcode, I want you to help me solve my problem. I am going to use this EAN-8, I searched it by google, for I have little knowledge about it, I hope some of you can give me some useful suggestions, and help me know the advantages about it. Thanks a lot!!!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: [Barcode] Code128 & EAN13 (Superset of UPC-A) supported [message #41238 is a reply to message #41237] |
Mon, 18 November 2013 01:06 |
Lance
Messages: 656
Registered: March 2007
|
Contributor |
|
|
Got stuck again.
When I said there were know omissions, one of it in my mind is "Code Word 913 will switch to Octet(AKA byte) only for the next CW(code word)" mentioned in the reference webpage. The author didn't elaborate on it, I assume it should mean:
1. If the current compaction mode is Text, 913 will cause the next codeword be interpreted as literal ASCII value, and the compaction mode for the codeword immediately after remains Text. Chance is, even the submode (UpperCase, LowerCase, Mixed, Punctuation) will be reserved;
2. If the current compaction mode is Byte, there will be no use for 913;
3. If the current compaction mode is Numeric, 913 will cause the next codeword be interpreted as literal ASCII value, and the compaction mode for the codeword immediately after remains Numeric.
If shortest encoding is a goal, it will not be achieved without taking the above into consideration. So I took time to implement above according to my assumption. Too bad, no online decoder will recognize barcode generated if 913-shift-to-Octet sequence existed in the codewords sequence. I was wondering if it's because the information was incorrect(author's mistake), or it wasn't interpreted correctly(my mistake), or it's because of a blind spot in the online decoders(somebody else to blame).
If somebody who has a decent barcode scanner that supports PDF417 could tell me the result of scanning the following barcode, it will be fully appreciated.
encoded text: ABCDEFâABCDEFGHIJKL
codeword sequence: 14 1 63 125 913 195 913 162 1 63 125 187 249 311 509 563 with the last 2 being error correction code words.
-
Attachment: screen.png
(Size: 0.71KB, Downloaded 2113 times)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Aug 01 03:41:02 GMT+2 2026
Total time taken to generate the page: 0.01393 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
. I was getting stuck in doing the PDF417. There was some minor errors in the otherwise easy to follow documentation(whose link was provided by you), then I decided the Reed-Solomon algorithm might not be interpreted/implemented correctly. I thought I could get some clue from one of the library (whose link also provided by you) . But I ended up decoding barcodes generated by an online generator for given simple inputs to figure it out. Thank God, the basic data (the coefficients) provided in the website seems to be correct. 
