[barcode] Postnet suppport

Dominik Seichter domseichter@web.de
Sat, 22 Feb 2003 19:06:15 +0100


Hello,

> > If you know Postnet barcodes allready you will know that the code can't
> > work yet. According to my source of information [...]
>
> I also got a manual from the us post service (I've printed it and forgot
> where I got it from). Also, I've several sample postnet codes from various
> magazines (they all have a pre-stamped card inside for new subscriptions).
Hmm, good idea. I must have some of those stamped cards here, too.

> And yes, I know it can't fit gnu barcode. There are a lot of encoding
> systems that can't fit the current approach for the intermediate
> language. Like 2D-codes and other stuff.
>
> So here's my plan for extending the current mechanism:
>
> * each encoding is an object, not an entry in a list but a more complex
> data structure, that registers itself in the core registry.
>
> * the "encoding" object can declare its own symbols for the intermediate
> representations and its own implementation for final output. It will also
> declare which output engines it supports (as output generation is now
> split inside the individual encodings, and not all in ps.c/pcl.c).
>
> * The symbols [1-9+-] are already managed by ps.c/pcl.c, so the current
> encodings will not need to have additional code, they just spit the current
> intermediate representation.
>
> * Postnet adds the symbols [pP] (short and long bars), and it's
> intermediate representation will be made up of such symbols alone (and
> no textual representation).  So actual rendering is performed back by
> the postnet encoding itself.
I would favor such an aproach. I will perhaps try to add support for the "p" 
and "P" symbols myself to the existing code in ps.c and pcl.c even if this is 
no clean solution, so that postnet codes can be rendered. 

Another solution would be an to add an intermediate renderer to the code. This 
"intermediate renderer" would get the intermediate representation from the 
different encodings and would transform it into a list of bars (i.e. 
rectangles) and the ps.c or pcl.c code would only draw those bars it gets 
from the "intermediate renderer". The intermediate renderer would do all the 
scaling, margin and textplacement stuff and the ps.c code would only draw 
everything. New stuff would then only have to be added to the "intermediate 
renderer". Your solution is perhaps more clean (especially when it comes to 
supporting 2D barcodes). I just got this idea while having a shower today 
:-).

CU Dom
-- 
************************************************************
Dominik Seichter - domseichter@web.de
Krename - http://www.krename.net
KBarcode - http://www.kbarcode.net
************************************************************