+ harbour/contrib/hbzebra/datamtrx.c
* harbour/contrib/hbzebra/hbzebra.hbp
* harbour/contrib/hbzebra/hbzebra.ch
+ added DataMatrix 2D barcode support
; implemented ASCII encoding only. This is enough for most real
life applications, but it is only a minor part of available
codeword encodings. I just unable to implement without docs.
Reverse engineering of black and white dots take a lot of time
for 2D barcodes, so I've dropped this idea. If someone has
full ISO/IEC 16022:2006 specification, I can implement the rest.
* harbour/contrib/hbzebra/tests/testcair.prg
+ added DataMatrix test
; Please, add it to other backend tests
* harbour/contrib/hbzebra/core.c
* changed bitbuffer logic a little
* harbour/contrib/hbzebra/pdf417.c
* comment added
* small cleanup
* contrib/hbzebra/tests/testwin.prg
* Trying to figure what's best way to round off coordinates
to the stupid integers the winapi requires. Patch it further
if you know better.
* bin/hb3rdpat.hbs
+ Clarification to help text, by Tamas.
* harbour/contrib/hbzebra/hbzebra.ch
* harbour/contrib/hbzebra/hbzebra.h
* harbour/contrib/hbzebra/hbzebra.hbp
+ harbour/contrib/hbzebra/pdf417.c
+ added two-dimensional PDF417 barcode support
HB_ZEBRA_PDF417( cData, [ nFlags ] [, nDataColumns ] ) --> hZebra
; This requires testing on real scanners. F.e., some internet online
PDF417 decoders does not allow encoding mode switching from numeric
to text. Though I see no reason to be this prohibited by
specification.
* harbour/contrib/hbzebra/drawcore.c
+ implemented 2D barcode drawing
* changed argument error logic to generate RTE from Harbour level
* harbour/contrib/hbzebra/testcair.prg
* harbour/contrib/hbzebra/testhpdf.prg
* harbour/contrib/hbzebra/testwin.prg
* included new barcode into test samples
* contrib/hbzebra/hbzebra.hbp
+ contrib/hbzebra/d_hpdf.c
+ contrib/hbzebra/d_win.c
+ contrib/hbzebra/tests/testhpdf.prg
+ contrib/hbzebra/tests/testwin.prg
+ Added Windows DC renderer
+ Added libharu renderer
; TODO: rework current rendering solution. Thinking about
callback based solution, to give it a smoother layout.
Current system has too much interdependencies and
too much redundancy even in renderer "plugins".
* utils/hbmk2/hbmk2.prg
+ Readded PathNormalize() calls missed after prev modif.
+ harbour/contrib/hbzebra
+ harbour/contrib/hbzebra/hbzebra.ch
+ harbour/contrib/hbzebra/hbzebra.h
+ harbour/contrib/hbzebra/core.c
+ harbour/contrib/hbzebra/codabar.c
+ harbour/contrib/hbzebra/code11.c
+ harbour/contrib/hbzebra/code128.c
+ harbour/contrib/hbzebra/code39.c
+ harbour/contrib/hbzebra/code93.c
+ harbour/contrib/hbzebra/eanupc.c
+ harbour/contrib/hbzebra/itf.c
+ harbour/contrib/hbzebra/msi.c
+ harbour/contrib/hbzebra/hbzebra.hbc
+ harbour/contrib/hbzebra/hbzebra.hbp
+ added barcode library. It supports these types of barcodes: EAN-13,
EAN-8, UPC-A, UPC-E, Code 128, Code 93, Code 39, Code 11, Codabar,
Interleave 2 of 5 (ITF), MSI.
Library has both C and Harbour level API functions. GC pointers
are used to store Zebra structures in Harbour items.
Current impementation has Cairo draw backend only. Draw A different
backends can be added
Harbour level API:
hb_zebra_create_<type>( cCode [, nFlags ] ) --> hZebra
hb_zebra_destroy( hZebra )
hb_zebra_geterror( hCairo ) --> nError
hb_zebra_getcode( hCairo ) --> cPrintableCode
hb_zebra_draw_cairo( hZebra, hCairo, nX, nY, nLineWidth, nHeight [, nFlags ] ) --> hZebra
+ harbour/contrib/hbzebra/tests
+ harbour/contrib/hbzebra/tests/test1.prg
+ harbour/contrib/hbzebra/tests/hbmk.hbm
+ added test app to generate barcodes. Creates .pdf and .png output,
uses Cairo backend to draw barcode
; TODO: (my todo list with low priority)
- 2-digit and 5-digit supplemental barcodes for EAN13
- draw EAN, UPC barcode in native format
- 2D barcode support
- PDF417
; If someone has real scanner it would be nice to do tests and get feedback.
; I guess I've implemented Code 128 encoding (code set selection, etc) that
generates the optimal (shortest) barcode. If someone can find a sample of
barcode that encodes the same data and is shorter than hbzebra's barcode,
please inform me.
; Make system is not working and a requires to be fixed by someone!
This library has properties that possibly could not be solved in current
make implementation. It can have multiple draw backends: Cairo, Win32 GDI,
GD, ASCII art, libharu, etc. These depends on system and installed
packages. I do not know howto put all backends into the same hbzebra
library. A separate library for each backend seems to be wasteful way to
solve a problem, because draw backend implements only one function (a few
more functions should be implemented to support EAN/UPC native draw, some
2D barcodes, but backend code size is small).
