After many hours or development I'm pleased to announce that the
latest release (2008-03-30) of BWIPP features support for QR Code -
phew!

As usual for the 2D symblogies, the input must be specified as a
binary string representing the barcode contents after translation into
a data bitstream and prior to conversion into padding, error
correction, etc. You'll have to perform the ASCII -> data bit stream
conversion within your own application for the timebeing.

The encoder will generate "full" format symbols unless you specify
otherwise with the option "format=micro" but you should ensure that
the reading apparatus can decode Micro QR Code before using this
variant. The error correction level will be set to "L" unless
specified with the option "eclevel={L,M,Q,H}". Also, the version of
the symbol will be automatically set to the minimum size that can
contain the input data at the specified error correction level unless
a specific value is provided, e.g. "version=8".

For example...

Unspecified parameters resulting in a version 1, error correction
level L (aka 1-M) QR Code symbol:

100 100 moveto (000100000010000000001100010101100110000110000) () qrcode barcode

Fixed parameters resulting in a 1-M QR Code symbol:

100 100 moveto (000100000010000000001100010101100110000110000)
(version=1 eclevel=M) qrcode barcode

Partly specified parameters resulting in a M2-L Micro QR Code symbol:

100 100 moveto (0100000000011000101011001100001100000) (format=micro)
qrcode barcode

Fixed parameters resulting in a M3-M Micro QR Code symbol:

100 100 moveto (0100000000011000101011001100001100000) (version=M3
eclevel=M) qrcode barcode

The current code does cut one corner however - it does not perform the
optional evaluation of applied mask patterns in order to determine the
"best" mask pattern for the particular symbol. Instead it always
chooses one particular mask irrespective of its fitness. Nevertheless,
the symbols will still decode properly even if they are not
fully-optimised for automatic location. The reason for this minor
caveat is that the run time of a basic implementation of the
evaluation algorithm for anything other than tiny symbols is quite a
bit more expensive than the entire of the rest of the symbol
generation process, so I have chosen to sacrifice this optional step
for the sake of speed. However, if I find a suitably fast way to
perform the evaluation algorithm in future then I will probably
introduce it.

Have fun,

Tez