Code 128 manual subset selection

[Siyfion]

I was wondering whether it is possible to create a Code 128 barcode, but with different subsets used for different parts of it? More specifically, say subset A for the first 8 characters, B for the next 10, etc.

I’ve never come across anything like this before and wondered whether BWIPP would be able to generate such a barcode?

[terryburton]

On 15 April 2016 at 12:38, Simon Mansfield [email protected] wrote:

I was wondering whether it is possible to create a Code 128 barcode, but with different subsets used for different parts of it? More specifically, say subset A for the first 8 characters, B for the next 10, etc.

I’ve never come across anything like this before and wondered whether BWIPP would be able to generate such a barcode?

The specifications discourage such usage.

It sounds like what you might find useful would be the ability to
directly specify the codewords, avoiding the high-level encoding
entirely?

Might I ask what the use case is?

[oehhar]

Am 15.04.2016 um 14:40 schrieb Terry Burton:

On 15 April 2016 at 12:38, Simon Mansfield [email protected] wrote:

I was wondering whether it is possible to create a Code 128 barcode,
but with different subsets used for different parts of it? More
specifically, say subset A for the first 8 characters, B for the next
10, etc.

Simon,

Normally, the character changes are chosen automatically to get minimal
code length. You want that, as shorter codes increase readability.

Example data: 1234567A
Low Level Codewords (automatically chosen): [Start C] [12] [34] [56]
[Change B] [7] [A] [Check] [Stop]
-> 9 Codewords

Perhaps you don't know, that bwipp cares about this automatically and
there is no need to specify anything.

A reason to specify the "charset" is to get contant code length with
constant data length. If you specify "Set B" for the upper code, you get
a constant length, even if you encode digits or alphas:
[Start B] [1] [2] [3]... -> 11 Codewords

Those two use-cases are covered. Is your use case one of those ?

Hope this helps,
Harald

[Siyfion]

I need to generate a barcode to the Interlink specification, which states that certain parts of the barcode must be encoded with specific subsets.

Here's a copy of the spec:
Interlink UK.pdf

EDIT: I know that their spec is stupid from a readability point-of-view, but I need to adhere to it 😢

[oehhar]

Am 15.04.2016 um 14:55 schrieb Simon Mansfield:

I need to generate a barcode to the Interlink specification, which
states that certain parts of the barcode must be encoded with specific
subsets.

Here's a copy of the spec:
Interlink UK.pdf
https://github.com/bwipp/postscriptbarcode/files/221002/Interlink.UK.pdf

Ok, thank you.

Harald

[terryburton]

@Siyfion I've just remembered that I included a "raw" option (or "encoding=raw") that allows you to specify the codewords directly.

See: https://github.com/bwipp/postscriptbarcode/wiki/Code-128
Alongside the encoding table here: https://en.wikipedia.org/wiki/Code_128#Bar_code_widths

To take Harald's (@oehhar) example above:

Example data: 1234567A
Low Level Codewords: [Start C] [12] [34] [56] [Change B] [7] [A]
These final codewords are automatic: [Check] [Stop]

0 0 moveto (^105^012^034^056^100^023^033) (raw) /code128 /uk.co.terryburton.bwipp findresource exec

[Siyfion]

@terryburton I saw the raw option, but to be completely honest, I had no-idea how to use it! Any way I could get you to do a small example of it's usage? Hell, I'm sure it'd be useful in the Wiki too

[terryburton]

Updated comment above.

[Siyfion]

Awesome, thanks! I'll give that a go now. 👍

[terryburton]

Leaving this fragment from offline here:

Terry Burton (@terryburton) wrote:

Grrr. The GeoPost specification should not be dictating what the
internal representation of the barcode should be since a
standards-compliant barcode reader would not reveal such data anyway!

That said, a very brief reading of the spec seems to indicate that
the data format complies with a run of alphanumeric data following by
numeric data. If that is so then BWIPP's optimising encoder will
naturally produce Mode B data for the leading characters (including
the short run of digits in a post code) then switch to Mode C for the
numeric tail.

Royal Mail has similar requirements over Data Matrix for their new
postal symbology. After talking to their developers it turns out that
all they intended to achieve was stability in the output size, which
is probably the case here.

[metafloor]

Terry, just to add a note to this closed issue.

We had a situation at a factory where we had to program a fixed scanner to ignore code128 symbols that started in subset-C. The labels it was scanning contained three code128 symbols, with the top one always starting in subset-C. We wanted only the other two bar codes.

Why I bring this up? Sometimes, because of automatic encoding, one of the other two bar codes would also start in subset-C....

We unfortunately had no control over those labels, but I think it demonstrates a use-case for at least forcing the starting subset.

Cheers, Mark

[terryburton]

On 15 Apr 2016 19:38, "metafloor" [email protected] wrote:

Terry, just to add a note to this closed issue.

We had a situation at a factory where we had to program a fixed scanner
to ignore code128 symbols that started in subset-C. The labels it was
scanning contained three code128 symbols, with the top one always starting
in subset-C. We wanted only the other two bar codes.

Why I bring this up? Sometimes, because of automatic encoding, one of the
other two bar codes would also start in subset-C....

We unfortunately had no control over those labels, but I think it
demonstrates a use-case for at least forcing the starting subset.

That's useful, thanks!

[aprking]

When using the bwip-js.js library to generate a Code 128 barcode, if the symtext content is "^105^012^034^056^100^023^033" and symopts are set to include text with "includetext raw" option, the text content will not be displayed. How can this be resolved?

[terryburton]

When using the bwip-js.js library to generate a Code 128 barcode, if the symtext content is "^105^012^034^056^100^023^033" and symopts are set to include text with "includetext raw" option, the text content will not be displayed. How can this be resolved?

The BWIPP library is an encoder not a decoder, so it does not attempt to convert from codewords back to text. You can however supply the alttext option alongside the raw option. Refer to the documentation.

Please can you describe the use case (application specification, etc.) that requires you to drive the encoding using the raw option, and what is the codeword format that is required?

Only the other day I encountered a proprietary application that required the gratuitous use of switch-A/B/C codewords in Code-128 that no longer works with modern scanning equipment. (These implement GS1 Composite, for which there is a standard use of the same codewords for "linkage" purposes.)

So I am more inclined to create helper symbologies for applications that require discouraged encoding tweaks than to shoehorn features into the generic encoders without reference to why they are required. It's difficult to anticipate the extent of implementer's stupidity!