444541191400F7DC009800005080243F0001414243313233345800%
00000000000000000000000000000000C5F04BF66C6E00000000%
00000000000000000000000000000000506F737466616368000000%
000000000000000000000031323334350000000000446575747363%
686520506F73742041470000000000000000000000000000446575%
747363686520506F73742041470000000000000000000000202020%
446575747363686520506F73742041470000000000000000000000%
0000004B42303831352D31000000

is it possible, to get a maxicode with this mode of data?
If yes, I'll will update my pst-barcode.

MaxiCode symbols are a fixed size and the BWIPP MaxiCode encoder is
feature complete (except for ECI and Structured Append support) so it
should have no problem encoding any valid data that you wish to throw
at it.

For general purpose data encoding the required mode is either 4 or 5,
depending upon the level of error correction required. When invoking
BWIPP, if you do not specify the mode in the options field that the
most appropriate mode (providing maximal available error correction
for given input) will be automatically selected. Further details are
given here: http://groups.google.com/group/postscriptbarcode/msg/f6e3d2218bb60fa5

The most obvious problem with encoding your data is that it appears to
be too long. The maximum length of mode 4 symbols is 94 codewords and
of mode 5 symbols is 78 codewords. A literal ASCII representation of
the 404 hex digits that you have provided wouldn't fit any mode of
MaxiCode symbol. An ordinal representation of 202 hex values (i.e.
444541191400... => ^068^069^065^025^014^000...) wouldn't fit either.

Are you in possession of any resources describing the German Post
application of MaxiCode that might be useful in determining what the
actual carried byte data for the symbol should be? If you can
determine the bytes for the carrier data then you can invoke BWIPP
similar to the following:

0 0 moveto (^068^069^065^025^014^000...) (parse) maxicode

One final thing that occurs to me: Could it be that the data that you
have provided requires "Structured Append" to encode - this is a
method of chaining multiple symbols together to read as a single data
stream.

*** Added after a bit of further web research:

Could it be that you actually require the Data Matrix rather than
MaxiCode symbology?

Assuming that the hex bytes are encoded as raw data in the symbol then
you could do the following:

0 0 moveto
<444541191400F7DC009800005080243F0001414243313233345800 \
00000000000000000000000000000000C5F04BF66C6E00000000 \
00000000000000000000000000000000506F737466616368000000 \
000000000000000000000031323334350000000000446575747363 \
686520506F73742041470000000000000000000000000000446575 \
747363686520506F73742041470000000000000000000000202020 \
446575747363686520506F73742041470000000000000000000000 \
0000004B42303831352D31000000> (rows=52 columns=52) datamatrix

If it is Data Matrix that you require then please could you provide me
with a good quality scanned image of such a symbol from such a piece
of genuine mail so that I can confirm the actual content using my 2D
scanning equipment.

All the best,

The first two examples worked well, the last one not. Everything,
which couldn't
be ASCII is coded as ^xyz, The underscores should be spaces.

You'll
an example of the data matrix on page 4 and 7 in
http://www.deutschepost.de//mlm.nf/dpag/images/p/premiumadress/mlfvm_...

thanks
Herbert

300 600 moveto (http://www.terryburton.co.uk/barcodewriter/) (rows=48
columns=48) datamatrix
0 -10 rmoveto (Data Matrix) show

300 500 moveto (DEA%
^025^020^000^247^200^000^152%
xxxxxxxx%
ABCDEFGHIJKLMNOPQRSTUVWX%
xxx%
Heidelbergxxxxxxxxxxxxxx%
Bergheimer Strassexxxx%
110axxxxxx%
DANTE e.V.xxxxxxxxxxxxxxxxxxxx%
______________________________%
) (rows=52 columns=52) datamatrix
0 -10 rmoveto (Data Matrix) show

Good news. I've done a little more digging into this and successfully
used BWIPP to reproduce the sample barcode given in the specification
that you provided.

I've decoded a scan of the sample barcode from the spec [1] which is
shown in attached file [2] using both a hardware and software reader
with identical results. The surprising feature here is that the free
space in the structured data appears to be padded with spaces (hex 20)
rather than NULs (hex 00). The hex bytes are given in file [3]. I've
then fed these directly into BWIPP as a hex-encoded PostScript string
(<...> notation) as in file [4] and the rendered result is given in
file [5]. You can see this is identical to the original sample showing
that the Data Matrix content is nothing more than a byte-oriented
string encoded using "byte mode" (the BWIPP default for Data Matrix).

In order to make it easier for you to encode the data using vanilla
PostScript string notation, i.e. without resorting to hex string
notation, I have just added a "parse" option to the remaining 2D
encoders to make them consistent with the MaxiCode encoder that I
described previously. This option will expand any ordinal
representations of the form ^NNN to their ASCII equivalent, i.e.

0 0 moveto (AB^067D) (parse) datamatrix

will be expanded to

0 0 moveto (ABCD) () datamatrix

or equivalently

0 0 moveto <41424344> () datamatrix

which is of course most useful for non-printable characters.

Hope this helps,