Christopher Cassidy
Jun 13, 2016, 5:07:06 PM6/13/16
to zxing
We have some barcodes that contain the 0D character (CR - Decimal 13), and we're trying to figure out how to deal with it. We've tried looking for specific oneByte values in DecodedBitStreamParser (decodeAsciiSegment() - Line 124) and adding logging statements to identify the value. We're not able to get anything to log out, and or attempts at blindly guessing the value of oneByte for the CR are not getting us nowhere. Anyone have any ideas for how to catch this tricky character? Also open to suggestions for getting the logging to work (trying to log the value of the oneByte variable). I've tried using System.out.println and Log.i(), but nothing ever prints out. This is driving me insane, and there's probably a simple solution to it.
Sean Owen
Jun 14, 2016, 9:30:52 AM6/14/16
to zxing
You get back a string containing the contents of the barcode. You can just examine the string for this character, right? I'm missing why it's more than that one line of code.
Christopher Cassidy
Jun 14, 2016, 1:41:34 PM6/14/16
to zxing
On Tuesday, June 14, 2016 at 9:30:52 AM UTC-4, Sean Owen wrote:
> You get back a string containing the contents of the barcode. You can just examine the string for this character, right? I'm missing why it's more than that one line of code.
> You get back a string containing the contents of the barcode. You can just examine the string for this character, right? I'm missing why it's more than that one line of code.
Forgive my ignorance, but you are referring to the string returned once the plugin has processed the barcode completely? The string that is returned does not contain the character.
Sean Owen
Jun 14, 2016, 4:24:23 PM6/14/16
to zxing
Once the library has processed it? yes. If the string doesn't contain the newline char, the barcode doesn't encode a string containing a newline. Or, post your barcode.
Christopher Cassidy
Jun 15, 2016, 10:11:45 AM6/15/16
to zxing
On Tuesday, June 14, 2016 at 4:24:23 PM UTC-4, Sean Owen wrote:
> Once the library has processed it? yes. If the string doesn't contain the newline char, the barcode doesn't encode a string containing a newline. Or, post your barcode.
> Once the library has processed it? yes. If the string doesn't contain the newline char, the barcode doesn't encode a string containing a newline. Or, post your barcode.
Hmmm. We use other scanners with our applications (camera scanning is new functionality for us) and the output for those scanners is:
PAT-021-4110-010101
567890-J567890
Whereas the output from the library is:
PAT-021-4110-010101567890-J567890
Somehow the other scanners know to put the CR after the 010101. I only have a physical copy of the barcode, so I've scanned and attached it.
Sean Owen
Jun 20, 2016, 4:47:51 AM6/20/16
to zxing
When I decode this barcode with the library, I see that it correctly returns a \r between 010101 and 56789. It is definitely working correctly. Remember it's a non-printing character, and it is not a line feed character. You would not expect the display to break over two lines in general. But, the raw barcode value contains the character you expect.
Christopher Cassidy
Jun 20, 2016, 9:36:16 AM6/20/16
to zxing
On Monday, June 20, 2016 at 4:47:51 AM UTC-4, Sean Owen wrote:
> When I decode this barcode with the library, I see that it correctly returns a \r between 010101 and 56789. It is definitely working correctly. Remember it's a non-printing character, and it is not a line feed character. You would not expect the display to break over two lines in general. But, the raw barcode value contains the character you expect.
We were expecting to find that character, and our initial idea was to find that character inside the library code and replace it with a line feed character before the library returned the scanned string. Is that something we could do? Or do you have any ideas on how we can force a break where the \r character appears (modifying the barcode isn't an option)? Side question: How were you able to see the /r character?> When I decode this barcode with the library, I see that it correctly returns a \r between 010101 and 56789. It is definitely working correctly. Remember it's a non-printing character, and it is not a line feed character. You would not expect the display to break over two lines in general. But, the raw barcode value contains the character you expect.
Sean Owen
Jun 21, 2016, 3:48:26 AM6/21/16
to zxing
I'm not sure what you mean. It exists in the value the library returns in a string, and you can do whatever you like with it. Did you actually inspect the string? I was looking via a debugger.
You are asking about how your application renders the string, which is up to you.
Christopher Cassidy
Jun 22, 2016, 11:51:04 AM6/22/16
to zxing
On Tuesday, June 21, 2016 at 3:48:26 AM UTC-4, Sean Owen wrote:
> I'm not sure what you mean. It exists in the value the library returns in a string, and you can do whatever you like with it. Did you actually inspect the string? I was looking via a debugger.
>
>
> You are asking about how your application renders the string, which is up to you.
> I'm not sure what you mean. It exists in the value the library returns in a string, and you can do whatever you like with it. Did you actually inspect the string? I was looking via a debugger.
>
>
> You are asking about how your application renders the string, which is up to you.
Thanks for your help. When I looked the first time, I didn't realize the string wouldn't show the \r character. For some reason my brain was just not connecting the dots in what you were saying. Looking at the string in chrome inspector I'm not seeing the \r, but I can do a replace and it replaces the character no problem. Again, thanks for your help and apologies for dragging you into our tail chasing.
Reply all
Reply to author
Forward
0 new messages