Closed JacekMarcinJ closed 4 years ago
Interesting, i will try to find some time during the weekend to take a look at it and get back to you.
Thank you for the report.
I am not sure, but maybe can help proper value returned by QZXing::foundedFormat (now it is empty for EAN128/Code128). But much more handy will be embedded (to the "tag" variable) separator signs so using QRegExp will be probably possible (I am not sure about this because probably separator codes are not printable - so I don't know whether QRegExp can handle them).
Is there any hope to investigate this issue?!?
Could you provide me with a sample barcode where it is failing to do my tests?
I did a quick lookup to the code and in some extent the above that you mention is already existant. Maybe I am wrong this is why a sample barcode would be helpful.
I can do it! I have code read by Datalogic laser scanner: ]C1#GS#GS93101#GS2402000190#CR (non printable characters are converted to human readable form) But when I read the same code by mobile phone camera, then I got only: 931012402000190 Which is pretty useless from our point of view. I got this code from one of our document, and I just print it and decode by laser and mobile. I attached this code. I talk only about first of the two codes visible on this image (second is single code which not big problem, but also some not visible characters are missing). I was thought for a while about this problem, and I am not sure whether it is not a case that it converts Ascii code to Unicode - so maybe it lost this characters during this process?
Thank you for your input.
I understand now what you mean. I did a quick check with the updated implementation that is in zxing project and there are differencies so one goal would be to port all the changes from here
On the other hand, since my free time is very limited this period of year, i will try to add the separators that you mention. The soonest that i can get to it is sometime next week but not guarantied. I will keep you updated
Until then, the source code that needs changes is here. In case you are interested in contributing changes, you would be more than welcomed.
Yesterday i have created a branch for testing this feature.
Right now, the decoding results of the two barcodes that you have posted are:
string on barcode: (93)101(240)2000190
string on barcode: (30)76
the characters "\035" is the octal representation of the group separator character 29 in ASCII table.
These results seem to be matching the string that you have decoded using Datalogic.
In this branch i have hardcoded to consider all Code128 as GS1barcodes though it is just for testing. It will be handled properly before merged to the master branch.
If you are interested, you could try it out.
Considering as resolved.
I can confirm that reported issue in this post: http://git.net/ml/zxing/2013-03/msg00152.html is current state. It is serious bug which does not allow to use this code in business applications. I don't know - but it seems to be simple typo. So maybe you can fix this?