saintmike has asked for the wisdom of the Perl Monks concerning the following question:

According to this thread, there is no need for using a decoder like Barcode::Cuecat if you're already using a "declawed" Cuecat.

However, when using a "declawed" Cuecat (which works fine on Windows without any decoder), I'm seeing some undecipherable keyboard escape sequences instead of clear text characters.

Here's an example: The scanned barcode is "056 698 580 492" and STDIN shows

0x0000 : 1B 5B 32 7E 1B 5B 44 1B 5B 41 1B 5B 32 7E 1B 5B 0x0010 : 45 1B 5B 36 7E 1B 5B 32 7E 1B 5B 45 1B 5B 44 1B 0x0020 : 5B 32 7E 1B 5B 45 1B 5B 44 1B 5B 32 7E 1B 5B 45 0x0030 : 1B 5B 31 7E 1B 5B 32 7E 1B 5B 45 1B 5B 43 1B 5B 0x0040 : 32 7E 1B 5B 45 1B 5B 36 7E 1B 5B 32 7E 1B 5B 45 0x0050 : 1B 5B 43 1B 5B 32 7E 1B 5B 44 1B 5B 41 1B 5B 32 0x0060 : 7E 1B 5B 45 1B 5B 42 1B 5B 32 7E 1B 5B 45 1B 5B 0x0070 : 31 7E 1B 5B 32 7E 1B 5B 45 1B 5B 32 7E 1B 5B 32 0x0080 : 7E 1B 5B 45 1B 5B 36 7E 1B 5B 32 7E 1B 5B 45 1B 0x0090 : 5B 34 7E 0A
Another one: Scanned barcode is "978 076 270 214 551 095", and keyboard input shows
0x0000 : 1B 5B 32 7E 1B 5B 45 1B 5B 31 7E 1B 5B 32 7E 1B 0x0010 : 5B 45 1B 5B 45 1B 5B 32 7E 1B 5B 45 1B 5B 43 1B 0x0020 : 5B 32 7E 1B 5B 44 1B 5B 41 1B 5B 32 7E 1B 5B 45 0x0030 : 1B 5B 45 1B 5B 32 7E 1B 5B 45 1B 5B 44 1B 5B 32 0x0040 : 7E 1B 5B 45 1B 5B 32 7E 1B 5B 32 7E 1B 5B 45 1B 0x0050 : 5B 45 1B 5B 32 7E 1B 5B 44 1B 5B 41 1B 5B 32 7E 0x0060 : 1B 5B 45 1B 5B 32 7E 1B 5B 32 7E 1B 5B 44 1B 5B 0x0070 : 35 7E 1B 5B 32 7E 1B 5B 45 1B 5B 42 1B 5B 32 7E 0x0080 : 1B 5B 45 1B 5B 36 7E 1B 5B 32 7E 1B 5B 45 1B 5B 0x0090 : 36 7E 1B 5B 32 7E 1B 5B 44 1B 5B 35 7E 1B 5B 32 0x00A0 : 7E 1B 5B 44 1B 5B 41 1B 5B 32 7E 1B 5B 45 1B 5B 0x00B0 : 31 7E 1B 5B 32 7E 1B 5B 45 1B 5B 36 7E 0A
This happens on Linux Fedora (2). As I've mentioned above, any Windows application will just show the scanned barcode. Can any venerable monk explain the difference? I realize this isn't really a Perl question ... but pointers to snippets or modules on CPAN would certainly be appreciated.

Replies are listed 'Best First'.
Re: CueCat decoding with Perl - revisited
by bart (Canon) on Apr 03, 2005 at 20:24 UTC
    Hex 1B (decimal 27) is an escape character, and chr hex '5B' is a "[". This looks a lot like Ansi escape sequences to me. You could check out thing like Win32::Console::ANSI to figure out what it represents. For example.

    And there are (farily simple) rules to how these escape sequences are constructed, so it is easily possible to use regexes to remove them from your strings.

      There's some escape sequences involved, but the most puzzling part is that if you compare the output for the two different barcodes, there's no obvious way on how they map.

      By the way, these sequences are even showing up on Windows: Running

      perl -p -e 1
      and operating the barcode reader will also display them, and not the barcode numbers. It's just that applications like Notepad seem to interpret them in a certain way so that they're showing as regular characters within the application.
Re: CueCat decoding with Perl - revisited
by theorbtwo (Prior) on Apr 04, 2005 at 05:10 UTC

    I think the differences are largely explainable by different keyboard drivers. I also recently got a cuecat (for scanning books, mostly), and found that it didn't work under X when declawed, only when under the console. (On linux; I didn't try it with windows.) Fornatly, for my application, I wanted to know the type of barcode anyway, and didn't purticularly need human readability, so I simply reclawed it.

    The table given in 444574 would tend to be explained by this if and only if we assume that cygwin is doing something mildly odd causing it to use dosish keyboard drivers rather then win32ish ones, which wouldn't much surprise me. (X11 uses it's own keyboard driver, essensially, on linux.)

    Since the product was never intended to be used by end-users in "declawed" mode, I suspect the output runs at a frequency which is a little faster then it should be, because it skips the modified base64 encoding step. Some keyboard drivers will still work, some won't, depending on the fine details of the routines.


    Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Re: CueCat decoding with Perl - revisited
by brian_d_foy (Abbot) on Apr 04, 2005 at 01:32 UTC

    I don't have an answer for you, but I haven't seen this sort of thing on Mac OS X. When I look at STDIN, I get just what I expect.

    brian[688]$ perl -p -e 1 9780937175903 90000

    I smell something between the CueCat and STDIN playing with your data.

    --
    brian d foy <brian@stonehenge.com>
      Interesting. I ran more tests on different terminals and the results are baffling:
      (1a) Windows command window: OK (1b) Windows command window + Activestate 5.8.4: OK (1c) Windows Notepad: OK (1d) Windows cygwin shell: Garbled (1e) Windows cygwin shell + cygwin perl 5.8.5: Garbled (1f) Windows cygwin shell + perl Activestate 5.8.4: OK (2a) Linux Fedora 2/3, X11 terminal: Garbled (2b) Linux Fedora 2/3 without X11: OK
      While the regular Windows command window works fine (with and without perl), the cygwin shell, doesn't, however, calling Activestate perl 5.8.4 from within the cygwin shell seems to fix it.

      On the Linux side, it didn't matter if perl was involved or not, neither did the version of perl (tried 5.6.1 - 5.8.6).

      The terminal settings (stty -all) in 2a and 2b were identical, $TERM was "linux" vs. "xterm" but setting it to "linux" in X11 didn't help.

      Strange, strange ...

        Curious: I just tried it on Apple's X xterm and it comes out wrong, but not garbled: everything shows up twice for one scan. I tried this a couple times with the same result (and I know I'm not scanning it twice!)

        albook:~ brian$ echo $TERM xterm albook:~ brian$ perl -p -e 0 9780937175903 90000 9780937175903 90000

        Changing the TERM type didn't help anything.

        --
        brian d foy <brian@stonehenge.com>