#20 EDIFACT mode errors with linefeed

open
encoding (5)
3
2011-04-14
2009-03-13
simon wood
No

--
simon@juicebox:~/libdmtx-svn/trunk/util/dmtxwrite$ echo -n 'EDIFACT' | ./dmtxwrite -e e -p

XX XX XX XX XX XX XX
XX XX XX XX
XX XX XXXX
XXXX XX XX
XX XX XX XX
XX XXXX XX XXXXXXXXXX XX
XX XX XXXX XX XXXX
XXXXXX XXXXXX XXXXXXXX
XXXXXX XX XX XXXX
XX XX XXXX XX XX XX
XXXXXX XXXXXXXXXXXXXX
XX XXXX XX XXXX XX
XXXX XXXX XXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXX

simon@juicebox:~/libdmtx-svn/trunk/util/dmtxwrite$ echo 'EDIFACT' | ./dmtxwrite -e e -p
Character "
" not supported by requested encodation scheme

lt-dmtxwrite: Unable to encode message (possibly too large for requested size)
--

I believe that it is possible to switch back to ASCII and encode the '\n'.

It may also be possible to use the same 'feature' as C40 mode where the last possible codeword (for a given size) is always assumed to be ASCII encoded.

Cheers,
Simon

Discussion

  • Mike Laughton

    Mike Laughton - 2009-03-13
    • labels: --> 1050217
    • assigned_to: nobody --> mblaughton
     
  • Mike Laughton

    Mike Laughton - 2009-03-13

    Hi Simon,

    Actually this behavior is the result of conscious design decision, but you bring up a good point. The original idea was that when dmtxwrite returns successfully the user will assume they now hold a fully EDIFACT barcode. If we introduce a mixture of schemes even though they requested something specific then we might be creating bugs in other peoples applications.

    The C40/Text case is a little different because the specification actually dictates the use of ASCII encoding under certain end-of-symbol conditions, but I don't remember seeing anything like that for EDIFACT. Even so, if a non-EDIFACT character occurs mid-stream then the encoder may need to switch into ASCII mode and switch immediately back to EDIFACT after the extra character(s) are encoded.

    Maybe it makes sense to implement a "--strict" option for dmtxwrite that will throw an error like above when encountering a character like this, but otherwise just switches over silently in the default case. Would this address your situation?

    Thanks,
    Mike

     
  • simon wood

    simon wood - 2009-03-13

    Whoops there goes my Nokia

     
  • simon wood

    simon wood - 2009-03-13

    The '--strict' would suffice, but you could also make the --encoding allow more than one format.

    For example '--encoding ea' would prefer (start) EDIFACT, but also allow ASCII.
    Cheers,
    Simon

    PS. I've already seen that the Nokia N95 'Barcode' application does not like the EDIFACT barcode I made this morning, even though it scans OK with libdmtx and Metrologic Focus. Image attached for ammusement.
    File Added: test.png

     
  • Mike Laughton

    Mike Laughton - 2011-04-14

    Changed to a feature request tracker based on conversation

     
  • Mike Laughton

    Mike Laughton - 2011-04-14
    • labels: 1050217 --> encoding
    • priority: 5 --> 3
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks