[pstricks] Question about code128

Terry Burton tez at terryburton.co.uk
Wed May 27 18:53:14 CEST 2020


On Wed, 27 May 2020 at 14:51, Walter Both <walter at uniware.nl> wrote:
> I hope it's a small question for you. We have been using pst-barcode for
> a long time. The first version we used was a version of 2008. In that
> version one could get a CODE128A/B bij putting "^103/^104" in front of
> the barcode. The codepoints for Start code A or Start code B.

In early versions of BWIPP (the PS library used by pst-barcode) you
would indeed specify these "non-data" codewords directly using the
syntax that you describe. At that time each input character (and ^NNN"
sequence) mapped directly to a "codeword" (the unit of information
internal to a barcode) and the PostScript code did little more than
append the bar-space sequences corresponding to the given codeword
sequence.

> Later we started using an update of pst-barcode. Since than we have had
> problems using that method. For now we get the ascii symbols, "g/h"
> when you use "^103/^104" in conjunction with the option "parse".  This
> is indeed as mentioned in the documentation.

At a certain point, all of the encoders had gained an automatic
optimisation routine that would determine the shortest possible
sequence of internal codewords that represent the user-provided
message. From the barcode symbologists' perspective the mode switches
and latches are opaque since they are invisible to the host sitting on
the end of the scanner. The scanner provides just a sequence of bytes
(or keyboard scancodes when in wedge mode) unless an "enhanced
channel" is present. Additionally, 2D barcodes were introduced and
these allowed non-printable ASCII characters to be represented. We
moved to a system where "^NNN" alongside parse was an escape syntax
for ASCII character, rather than codeword values.

So today we have a harmonious system: You just specify the message
that you what to encode and the library takes care of encoding this
for you in an optimal way. When we rounded up all of the capabilities
of each barcode type over many years there was simply too much baggage
to carry around if we wanted to avoid breaking user-facing changes.

Where the user knows better and wants to force an exact representation
there is the "raw" option available, but its use is discouraged
because you have to have domain-specific knowledge to use it. (Every
barcode has a different internal encoding scheme that is optimised for
its intended application, and whilst Code 128 is relatively
straightforward they get increasingly complex the more recent the
barcode. To fully describe the raw option is to teach the high-level
encoding systems of every barcode that we support which isn't
feasible.)

> We have found that you can use "^FNC4"  with the option "parsefnc" or
> "^FNC4^FNC4" also as mentioned in the documentation.
>
> But should this deliver CODE128A/B? Or is this not as to go about?
> Should we use a different method?

As you appear to have discovered the FNC4 non-data character is
normally used to extend the reach of Code 128 (normally ASCII only)
into high order bytes (ordinals 128-255): Singularly it will flip the
most-significant-bit of the next character; In double form it will
apply the bit flip to all subsequent characters until cancelled. This
link [1] gives the typical definitions of all of the FNC characters
and [2] gives information specific to FNC4. (I include this only
because people tend to find scraps of information on forums concerning
FNC characters which are easy to misinterpret without wider context.)

In BWIPP release 2015-05-21 we switched to automatically inserting
FNC4 or double-FNC4 characters as necessary to reach any
extended-ASCII characters (high-order bytes) included in the given
message. So now you should simply forget all you know about the
internal encoding of Code 128 and just give pst-barcode what you want
to represent, using the ^NNN syntax together with the "parse" option
to specify the *(extended-)ASCII* values of any non-printable
characters that TeX or PS might choke on.

If you do however have a good reason to drive the encoding directly
then if you give me an exact example of what you want to encode then I
can demonstrate how to use the raw option to achieve it.


[1] https://stackoverflow.com/a/31322815/2568535
[2] https://stackoverflow.com/a/30308255/2568535


Kind regards,

Terry


More information about the PSTricks mailing list.