Optimize breaking up data for encoding method in Code128 dynamic mode #127
Conversation
|
What do you think of this @binki ? Encoding the first vs the last will require the same amount of switching modes unless Im missing something. |
|
@barnhill, no, encoding the last number will need one more mode switching (between CODE_A and CODE_C). As an example, please check this input: GAA01BB0880001 |
I have not yet looked at the implementation, so I am not sure if my concerns have been addressed. However, here are my thoughts! I will try to check back again (if I remember x.x). It sounds reasonable to try to optimize the number of switches for size. This could actually help a lot with getting the barcode to fit on screen or in a document. The biggest concern I have is that there might be a compatibility concern for an application which accidentally relies on the existing behavior. For example, maybe a scanner which is configured to ignore barcodes which use mode C (not sure if that is a thing). Hopefully all people consuming barcodes work with them as strings and do not know how they are actually encoded ;-). The last versus first seems to be an optimization for when the 3-number sequence is at the very end of the barcode. If the last three characters of a barcode are a run of digits following nondigits encoded using mode A or B, you could encode that as either “mode-C 01 mode-A 2” or you could encode that as “0 mode-C 12”. However, if the 3-digit run is in the middle of a barcode, then I think switching codes would cost you more. You could encode “A123B” as “start-A A 1 2 3 B” (6) or “start-A A 1 mode-C 23 mode-A B” (7). Thus, if you switch for a 3-digit sequence which is followed by a switch back to mode A or B, then switching to mode C increases the total width of the barcode unnecessarily. However, if you have a run of 4 digits followed by a mode switch, then you do not increase the width of the barcode by switching modes—but you do not gain anything until you have a run of at least 6 digits:
@Badkoubehei Please let me know if I am missing something! |
After thinking about it, I think these rules would make sense and result in the most optimal mixed mode barcodes:
Unfortunately, an earlier commit I made disturbed |
Yes, you are right about the length of sequence. But if I have got your meaning about "aligned to either the start or end" right, I think aligning to start or end matters for odd-length sequences. See these examples: 12345A A12345 It shows that if the sequence is at the start of string, aligning to start is more optimal and if sequence is at the end, aligning to end is better.
Yes, you are right. And in this case, aligning to start or end does not matter: A1234567A
I checked your commit. I think re-implementing my commit is easier than resolving the conflicts :). I will try to do it. |
Correct! Aligning to the start or end only matters for odd-length sequences. I just wanted to clearly state that odd-length sequences of 5 or more digits at the beginning of the barcode need to have the barcode start in Mode C rather than switching to it after the first character. It is similar to the optimization at the end of the barcode. I wanted to make sure that this optimization was considered:-).
Correct.
Thanks! |
|
This is awesome 😎. I'm pretty stoked about the collaboration here!! |
|
Hi,
there are Shift A and Shift B that allows switching between Code A and Code
B too. Never used them myself but they are said to only shift for the next
code word.
/rob
…On Thu, May 27, 2021, 16:52 Brad Barnhill ***@***.***> wrote:
This is awesome 😎. I'm pretty stoked about the collaboration here!!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#127 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQNI4LHBD6YWRKWIJ42YSTTPZMDJANCNFSM43BOBAZA>
.
|
Great! I did not know about that. It may change the algorithm! 1234A23 1234A567 1234A5678 12A5678 I will try to consider it in my implementation. |
|
Hi Ahmad,
The Shift code word only exist in the Code A and Code B code sets. The only
time it will save a code word, I think, is when data suitable for Code B
surrounds a single control character, like CR (ASCII 13), it would save a
single code word, example:
[StartB]Testing[SHIFT][CR]some more.[CRC][STOP]
instead of
[StartB]Testing[CODEA][CR][CODEB]some more.[CRC][STOP]
So it will just be a very small optimization. I think Shift is mostly
useless. Control characters in Code 128 is not very common.
24 years ago I wrote an encoder and designed a font for Code 128, and I
tested the encoder today, it did not have support for Shift, not even in
the raw encoding mode. I guess I did not know about it then.
Another topic:
One very common usage of Code 128 is to use it for marking pallets and
cartons according to the GS1-128 content specification. Maybe that would be
a good idea for including support for in barcodelib.
I could contribute with my knowledge about GS1-128 if anyone is interested
in building some code for it. I also have code in C++ and C# for a GS1-128
parser.
/rob
…On Thu, 27 May 2021 at 19:53, Ahmad Badkoubehei ***@***.***> wrote:
@rob313663 <https://github.com/rob313663>
Hi, there are Shift A and Shift B that allows switching between Code A and
Code B too. Never used them myself but they are said to only shift for the
next code word.
Great! I did not know about that. It may change the algorithm!
1234A23
Start-C 12 34 Code-A A 2 3 (7)
Start-C 12 34 Shift-A A 23 (6)
Here the ending sequence of numbers has length 2, but using the Shift-A
makes it optimal to encode using code-C.
1234A567
Start-C 12 34 Shift-A A 56 Shift-A 7 (8)
Start-C 12 34 Code-A A 5 6 7 (8)
1234A5678
Start-C 12 34 Shift-A A 56 78 (7)
Start-C 12 34 Code-A A Code-C 56 78 (8)
12A5678
Start-C 12 Shift-A A 56 78 (6)
Start-A 1 2 A Code-C 56 78 (7)
I will try to consider it in my implementation.
@barnhill <https://github.com/barnhill> what do you think?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#127 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQNI4IKNYIXRB34VRALJJDTP2BI3ANCNFSM43BOBAZA>
.
|
|
Hi @rob313663 |
|
I'm interested in supporting GS1-128. It's a subset of C128 as it's formatted data encoded with C128 as far as I know. |
|
I have what I believe is a much more robust method of correctly decomposing which substrings should be in subset C. The situation is far more complex than 'must be at least 3'. The complexity depends on something which appears not to be addressed at all: the FNC1 code. So, a sequence "0000f66" in the middle of a string (where f means func 1) would be better encoded encoded in set C. Then there are odd numbers of digits which terminate at or start at a FNC1. It isn't obvious how sequence such as X55555f777f99999f44 should be encoded. |
In order to optimize the encoded data length, only numeric sequences with length 3 or more must be encoded in mode C. Shorter sequences must be encoded in mode A or B. In addition, if the sequence length is odd, it is more optimize to encode the first number in mode A or B (not the last number. Because encoding the last number will need another mode switching)