--
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
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
Whoops there goes my Nokia
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
Changed to a feature request tracker based on conversation