Thursday, 31 May 2012

Technically correct (union flag)

One of the small jobs I had yesterday was the new router cards.

We put these in a small clear plastic wallet attached to the routers we ship.

They contain the login details for the line, the router and wifi. We have gone for a single sided design this time.

This should have been a simple job!

First off, I thought why not include a 2D bar code that has the WiFi connection details. It seems many phones will now read these and pick up the SSID and password from them. I already have an IEC16022 (Datamatrix) encoding app I wrote many years ago. Simples!

Except it turns out the code has a bug. Even though published long ago and used by many people, it does not code EDIFACT correctly. In the case of the upper case characters and punctuation used in the WiFi password data, EDIFACT was the best coding, and it just made gibberish. So that wasted an hour or so fixing it.

The rest was easy, but when I had finished some bright spark (Steve, I think) suggested that we could put a union flag on the card as it is the jubilee. Fair enough. How hard can it be?

Uncharacteristically, as it was a gimmick and cosmetic, I just made something that looked like the union flag. Of course, and quite rightly, I was immediately slated for this by the denizens of irc. Sorry everyone... What was I thinking?

So I went off and found the 2:1 ratio union flag design, and put that on. It kept them happy. However, I thought I should dig a bit deeper. Thanks to this site.

Interestingly the union flag design is specified in such a way as to allow any ratio of flag, even square. I never knew this, but it is not just one design that you stretch to fit. It is different when drawn in different ratios. In the case of this card the ratio is not 2:1 (or 3:2 or 5:3 or one of the common variants) but was around 200:127 as that is the space I had. Actually the ratio is dependent on the left margin I set, and can be changed easily in the design now.

All of the sizes are based on the height (or as I believe it is called, the width where what we would call width is the length). The top to bottom distance, OK!

Postscript is really good at this stuff, and makes it very easy.

First, we define w and h as width and height, and make some derived values. d is diagonal distance; a is angle of diagonal; u is a unit which is 1/30th of the height h.

/d w dup mul h dup mul add sqrt def
/a h w atan def
/u h 30 div def

We make the rectangular area as a clip area for the drawing:

0 0 moveto w 0 rlineto 0 h rlineto w neg 0 rlineto clip

Then we may as well fill the whole flag blue:

0 0 102 256 div setrgbcolor % blue

Then the white diagonal cross which is 6 units thick and from corner to corner:

1 setgray % white
0 0 moveto w h lineto 0 h moveto w 0 lineto
u 6 mul setlinewidth stroke

Then the thin red diagonals which are 2 units thick. We need to rotate to do this right:

204 256 div 0 0 setrgbcolor % red
u 2 mul setlinewidth
gsave a rotate 0 u neg moveto d 2 div 0 rlineto 0 u 2 mul rmoveto d 2 div 0 rlineto stroke grestore
gsave 0 h translate a neg rotate 0 u neg moveto d 2 div 0 rlineto 0 u 2 mul rmoveto d 2 div 0 rlineto stroke grestore

Then the England cross white border:
w 2 div 0 moveto 0 h rlineto 0 h 2 div moveto w 0 rlineto
gsave 1 setgray u 10 mul setlinewidth stroke grestore

And finally the red cross (we gsaved it above):
u 6 mul setlinewidth stroke

Job done. Flag poll assumed on left.

Oh, and add some text to explain why on earth we have but a flag on there in the first place :-)

Note: You probably want to wrap this all in a function with gsave/grestore, etc.

And in different ratios, it looks like:


  1. Nice... Although I could never bring myself to scan the Data Matrix knowing that your library generates bad 144x144 symbols ;-)!topic/postscriptbarcode/ylTP8DCCjZ8/discussion

    You could always take the "Pure PostScript" route:

    1. Is it making bad 144x144 symbols - I did not know.

    2. I have done many 1D bar codes in pure postscript.

    3. I emailed you a bug report in 2008 when I was investigating a bug report against the Data Matrix encoder in my Barcode Writer in Pure PostScript, however I did not follow it up.

      I've just re-forwarded the email.

  2. Greylisted, so jumping the gun and including here for anyone else who happens to be interested...

    Hi guys,

    I'm contacting you because you maintain projects that appear to
    misgenerate 144x144 Data Matrix ECC200 symbols due to a discrepancy
    between the formal specification and (seemingly) accepted convention.

    Specifically, in 144x144 symbols the error correction block alignment
    during interlacing needs to be two places so that the EEC blocks
    corresponding to the two "short" data blocks are placed first. I have
    reported this to a contact ISO/IEC and will relay any comments that
    they may have on the matter.

    An example 144x144 ECC for the ASCII-encoded text "70856 1" can be
    found at^200^215^055^033^050&options=rows=144

    To see the complete encoding algorithm download and open the EPS file
    in the text editor.

    My testing is limited to:

    * Reading with two hardware readers (Datalogic and Wasp)
    * Reading with a commercial software reader
    * Visual and logical comparison against
    * Visual comparison against output from

    More information follows in the forwarded message below.

    All the best,


    ---------- Forwarded message ----------
    From: Terry Burton <[REDACTED]>
    Date: Sun, Dec 14, 2008 at 7:27 PM
    Subject: Re: Data Matrix code...
    To: Ray Johnson <[REDACTED]>

    On Mon, Dec 1, 2008 at 6:09 PM, Ray Johnson <[REDACTED]> wrote:
    > Here is the sample I said I would send "2desk.bmp", and I've included 2
    > programs that can decode data matrix barcodes. DM single and DM Multi.
    > They require BMP files for input...

    Hi Ray,

    I spent a very long time pulling apart my code in an attempt to find
    the root of the 144x144 Data Matrix encoding issues. I have reread the
    ISO/IEC 16022:2000 specification in detail and there really isn't a
    great deal of difference between rendering 144x144 symbols versus any
    other size. In fact, I've found another open source project "iec16022"
    [1] that predates BWIPP that also happens to fail in /exactly/ the
    same way.

    However, the resources that you provided have been very useful for
    investigating this...

    > I made samples of 120x120 132x132 and 144x144 from your code and GMC.
    > The 120x120 and 132x132 DM codes can be decoded by the supplied
    > software. The 144x144 fail.
    > I've also included an Indesign document and PDF output of your DM codes
    > placed over the GMC codes, and they are "exactly" the same.

    The break came when I eventually found that the open source libdmtx
    project [2] generates 144x144 symbols identical to those of the ID
    Automation servlet [3] and which also scan correctly using the
    utilities that you provided.

    So after a lot of tracing I was able to determine that for some
    (insane) reason the error correction code blocks require reordering
    for 144x144 symbols, which is entirely contrary to annexe G.2 of
    ISO/IEC 16022:2000!

    + ncws 1558 eq {
    + /ecbs [ ecbs 8 2 getinterval {} forall ecbs 0 8 getinterval
    {} forall ] def
    + } if

    Convention appears to out way formality in the matter since the
    ECC-block-reordered symbols do scan correctly whilst the plain symbols
    do not.



    All the best,