Code 128 manual subset selection about postscriptbarcode HOT 11 OPEN

@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

from postscriptbarcode.

Updated comment above.

from postscriptbarcode.

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?

from postscriptbarcode.

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

from postscriptbarcode.

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 😢

from postscriptbarcode.

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

from postscriptbarcode.

@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

from postscriptbarcode.

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

from postscriptbarcode.

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.

from postscriptbarcode.

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

from postscriptbarcode.

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!

from postscriptbarcode.