datamatrix test
Tamas TEVESZ
hi,
so it turns out my phone (nokia e90) with its built-in barcode reader
application is capable of reading (at least some variant of)
datamatrix.
i found these online datamatix generators:
http://datamatrix.kaywa.com/
http://www.i-nigma.com/CreateBarcodes.html
my phone can recognize everything i tried to encode with these toosl
as well as the 3 examples on http://en.wikipedia.org/wiki/DataMatrix.
my zebra output of
DrawBarcode( page, nY, 1, "DATAMATRIX", "Wikipedia, the free encyclopedia" )
DrawBarcode( page, nY += 1.5 * nInc, 1, "DATAMATRIX", "Hello, World of Harbour!!! It's 2D barcode DataMatrix :)" )
looks like this:
http://i56.tinypic.com/sm4mkn.png
the phone barcode application recognizes the outline (ie it draws a
rectangle around the barcode indicating "hmm lets see if there's
something in here"), but apparently doesn't recognize anything.
it also doesn't recognize this:
http://www.itu.dk/stud/e2009/DSDS/tuehellstern/docportal/chunkhtml/ch26s03.html (fig. 26.10)
but does this http://www.idautomation.com/fonts/datamatrix/DataMatrixImage.png
but nothing else on its page: http://www.idautomation.com/fonts/datamatrix/
and does these:
http://www.all-marks.com/Why2dDataMatrix.htm
http://www.datenfreihafen.org/projects/iec16022.html
i also tried the kaywa reader thing (just to have a second opinion on
the nokia shit), with more or less the same results.
i would suppose trendy phones to also know datamatrix, so if you have
one around, you too can do some testing.
--
[-]
mkdir /nonexistent
Viktor Szakáts
frank van nuffel
Tamas TEVESZ
> I've found this, but it doesn't know 2D barcodes:
> http://www.bruji.com/cocoa/barcode.html
>
> If there is similar app able to scan barcodes from
> camera picture, f.e. for Linux or Windows, we could
> use it for testing.
we (a colleague) used this briefly in the past:
http://sourceforge.net/projects/zbar/files/
with qr code, with great results.
now i see it supports EAN-13/UPC-A, UPC-E, EAN-8, Code 128, Code 39,
Interleaved 2 of 5 and QR Code; so no datamatrix, but plenty of the
others.
(we used with a very cheap webcam affixed to an adjustable table lamp
with some plastic tape).
i have no webcam with me here :)
--
[-]
mkdir /nonexistent
Tamas TEVESZ
> oh now qt is merely sh? - how did you put it?
would you now please also include those accidentally forgotten parts
of your mail that would cause the above to make any sense at all?
thank you,
signed,
the management.
--
[-]
mkdir /nonexistent
frank van nuffel
to keep this forum educated
signing with 'the managment' does sound like overtaking the forum, which is
read publicly
thank you
----- Original Message -----
From: "Tamas TEVESZ" <i...@extreme.hu>
To: <harbou...@googlegroups.com>
Viktor Szakáts
frank van nuffel
Viktor Szakáts
it's nothing really - it however sometimes gets annoying to seperate that kind of hitch from value in the amount of posts by Tamasi just didn't want to repeat the phrase used
Viktor Szakáts
Guy Roussin
> zbar is very nice. It spots the barcodes on the webcam image on the fly.
$ zbarimg testhpdf.pdf
CODE-128:Wikipedia
CODE-128:1234567890
CODE-128:Code 128
I2/5:123456789012
CODE-39:ABC123$
CODE-39:ABC123
EAN-13:0012345000065
EAN-13:0012345678912
EAN-8:12345670
EAN-13:4770123456782
scanned 10 barcode symbols from 1 images in 0.15 seconds
Note that there is some mistake ... but it analyse the full pdf !
Guy
frank van nuffel
----- Original Message -----From: Viktor SzakátsSent: Saturday, November 13, 2010 3:08 PMSubject: Re: [harbour] datamatrix test
Tamas TEVESZ
> please keep your afterthoughts for your self; it has been repeated politely
> to keep this forum educated
>
> signing with 'the managment' does sound like overtaking the forum, which is
> read publicly
i am deeply terribly sorry for you not recognizing sarcasm when it
comes your way.
on second and subsequent reads, it appears that you have problems with
me using the expression "nokia shit".
please be so kind to let me know whether it is "nokia", "shit", or the
combination of the two that you find offensive, and i will definitely
make sure not to use them in the future, or use them in such a way
that while the expression itself is never spellt out.
--
[-]
mkdir /nonexistent
Tamas TEVESZ
woohoo, this is nice. i was just thinking about using libzbar to whip
something up that can be used as an automated test, but then even this
is taken care of.
what errors are you referring to? at a quick skim, it seems to me that
the differences come from all the issues mindaugas explained in a
series of mails during the past several days (appending checksum,
leading zero, expanding smaller versions of a specific symbology to
wider version of said symbology, etc) -- but i haven't yet pulled out
a pencil to verify manually.
--
[-]
mkdir /nonexistent
Mindaugas Kavaliauskas
On 2010.11.13 14:52, Tamas TEVESZ wrote:
> my zebra output of
>
> DrawBarcode( page, nY, 1, "DATAMATRIX", "Wikipedia, the free encyclopedia" )
> DrawBarcode( page, nY += 1.5 * nInc, 1, "DATAMATRIX", "Hello, World of Harbour!!! It's 2D barcode DataMatrix :)" )
>
> looks like this:
>
> http://i56.tinypic.com/sm4mkn.png
>
> the phone barcode application recognizes the outline (ie it draws a
> rectangle around the barcode indicating "hmm lets see if there's
> something in here"), but apparently doesn't recognize anything.
You should fix hpdf backend. It draws barcodes upside down. I attach the
correct drawing from cairo.
I've tested hbzebra using
http://www.bcgen.com/datamatrix-barcode-creator.html
It generates EXACTLY the same barcode if you specify ASCII encoding mode
and preferred format. Though, this online generator has buggy 16x36
rectangular barcode support (that's a case of "Wikipedia, the free
encyclopedia" encoding).
So, I've used another webpage to test Wikipedia barcode:
http://www.bcmaker.com/demos/datamatrix.php
This page adds "DEMO" in front of barcodes. So, I had to change data of
encoded barcode to "DEMOWikipedia, the free encyclop". Both hbzebra and
the webpage (do not forget to select ASCII also) produce exactly the
same barcode.
All 2D hbzebra barcodes can be read by:
http://www.datasymbol.com/barcode-recognition-sdk/barcode-reader/online-barcode-decoder.html
Regards,
Mindaugas
Mindaugas Kavaliauskas
No mistake! :) It just returns checksums and expands UPC-A and UPC-E to
EAN-13. You might have heard about this is you read mailing list in last
2 days:
> hb_zebra_upce( "123456" )
> can be read as:
> ...
> - "0012345000065" (expanded to EAN-13, with checksum)
Regards,
Mindaugas
Tamas TEVESZ
hi,
> You should fix hpdf backend. It draws barcodes upside down. I attach the
or, more precisely, mirrored around the horizontal center line
(irrespective of the number of rows, so even a one-row barcode is
bad).
now, how did you spot *that*?! :)
--
[-]
mkdir /nonexistent
Viktor Szakáts
on second and subsequent reads, it appears that you have problems with
me using the expression "nokia shit".
Mindaugas Kavaliauskas
> On Sat, 13 Nov 2010, Mindaugas Kavaliauskas wrote:
>
> hi,
>
> > You should fix hpdf backend. It draws barcodes upside down. I attach the
>
> or, more precisely, mirrored around the horizontal center line
> (irrespective of the number of rows, so even a one-row barcode is
> bad).
No, 1D is OK, since barcodes are only flipped vertically. So, top
becomes bottom, but left remains left. It is because of different y axis
orientation in hpdf and
nY := 841 - nY
So, you hbzebra+hpdf users should decide that is preferred way to write
your code:
nY := 810
nInc := -30
and no
nY := 841 - nY
any more.
Or:
STATIC FUNCTION hb_zebra_draw_hpdf( hZebra, page, nX, nY, ... )
IF hb_zebra_GetError( hZebra ) != 0
RETURN HB_ZEBRA_ERROR_INVALIDZEBRA
ENDIF
hb_zebra_draw( hZebra, {| x, y, w, h | HPDF_Page_Rectangle( page, x,
2 * nY - y, w, h ) }, nX, nY, ... )
(Not tested)
> now, how did you spot *that*?! :)
Sorry, Thomas, my english is not as good as your, and I sometime do not
understand the things you say (especially some slangy things)... But if
"spot" means "notice", than answer is simple :)
http://i56.tinypic.com/sm4mkn.png
Regards,
Mindaugas
Tamas TEVESZ
> No, 1D is OK, since barcodes are only flipped vertically. So, top becomes
> bottom, but left remains left. It is because of different y axis orientation
> in hpdf and
> nY := 841 - nY
oh. i thought this only affects the position.
> So, you hbzebra+hpdf users should decide that is preferred way to write your
> code:
> nY := 810
> nInc := -30
> and no
> nY := 841 - nY
> any more.
yup, i get it now. let me experiment a bit before submitting a patch.
> > now, how did you spot *that*?! :)
>
> Sorry, Thomas, my english is not as good as your, and I sometime do not
> understand the things you say (especially some slangy things)... But if
> "spot" means "notice", than answer is simple :)
> http://i56.tinypic.com/sm4mkn.png
so i guess looking at a small bunch of dancing black and white dots
and immediately knowing they are upside down is as natural to you as
it is natural to me to know that one of the meanings of "to spot" is
"to notice" :))
--
[-]
mkdir /nonexistent
Mindaugas Kavaliauskas
On 2010.11.13 17:53, Tamas TEVESZ wrote:
> so i guess looking at a small bunch of dancing black and white dots
> and immediately knowing they are upside down is as natural to you as
> it is natural to me to know that one of the meanings of "to spot" is
> "to notice" :))
That's why I'm not an english teacher, what about you? :P
Regards,
Mindaugas
Viktor Szakáts
Mindaugas Kavaliauskas
On 2010.11.13 18:11, Viktor Szakáts wrote:
> + nH := 0
> + nYO := -1
> + hb_zebra_draw( hZebra, {| x, y, w, h | iif( y != nYO, ( nH += h, nYO
> := y ), NIL ), HB_SYMBOL_UNUSED( x ), HB_SYMBOL_UNUSED( y ),
> HB_SYMBOL_UNUSED( w ), HB_SYMBOL_UNUSED( h ) }, nX, nY, nLineWidth,
> nLineHeight )
> + hb_zebra_draw( hZebra, {| x, y, w, h | HPDF_Page_Rectangle( page, x,
> y + nH, w, h ) }, nX, nY, nLineWidth, -nLineHeight )
> HPDF_Page_Fill( page )
This will not work if we have a white line across all barcode, since
this code do an independent y calculation (increments y by h) not
related to barcode draw internals (imagine what will happen if draw
internals will use callback to draw rectangles in random order).
If we are going top use y axis from top to bottom in testhpdf sample
code, I would prefer to use a simple proposed:
HPDF_Page_Rectangle( page, x, 2 * nY - y, w, -h )
If this is not clear expression (why do we have to multiply something by
2), I can right it in a different way:
nY - ( y - nY )
i.e.
decrease nY by distance of rectangle relative position from nY, i.e.
by (y - nY).
Bellow is diff that makes testhpdf work exactly (the same text and
barcode positioning) as testcairo (except distance between barcodes).
Regards,
Mindaugas
Index: C:/harbour/contrib/hbzebra/tests/testhpdf.prg
===================================================================
--- C:/harbour/contrib/hbzebra/tests/testhpdf.prg (revision 15821)
+++ C:/harbour/contrib/hbzebra/tests/testhpdf.prg (working copy)
@@ -23,7 +23,7 @@
HPDF_Page_SetSize( page, HPDF_PAGE_SIZE_A4, HPDF_PAGE_PORTRAIT )
HPDF_Page_SetFontAndSize( page, HPDF_GetFont( pdf, "Helvetica", NIL
), 12 )
- nY := 40
+ nY := 20
nInc := 30
DrawBarcode( page, nY, 1, "EAN13", "477012345678" )
@@ -48,8 +48,8 @@
DrawBarcode( page, nY += nInc, 1, "CODE128", "Code 128")
DrawBarcode( page, nY += nInc, 1, "CODE128", "1234567890")
DrawBarcode( page, nY += nInc, 1, "CODE128", "Wikipedia")
- DrawBarcode( page, nY += 2.5 * nInc, 1, "PDF417", "Hello, World
of Harbour!!! It's 2D barcode PDF417 :)" )
- DrawBarcode( page, nY += 1.5 * nInc, 1, "DATAMATRIX", "Hello, World
of Harbour!!! It's 2D barcode DataMatrix :)")
+ DrawBarcode( page, nY += nInc, 1, "PDF417", "Hello, World
of Harbour!!! It's 2D barcode PDF417 :)" )
+ DrawBarcode( page, nY += 2.5 * nInc, 1, "DATAMATRIX", "Hello, World
of Harbour!!! It's 2D barcode DataMatrix :)")
? HPDF_SaveToFile( pdf, "testhpdf.pdf" )
@@ -82,8 +82,8 @@
nLineHeight := 16
ENDIF
HPDF_Page_BeginText( page )
- HPDF_Page_TextOut( page, 40, nY, cType )
- HPDF_Page_TextOut( page, 150, nY, hb_zebra_getcode( hZebra ) )
+ HPDF_Page_TextOut( page, 40, nY - 13, cType )
+ HPDF_Page_TextOut( page, 150, nY - 13, hb_zebra_getcode(
hZebra ) )
HPDF_Page_EndText( page )
hb_zebra_draw_hpdf( hZebra, page, 300, nY, nLineWidth,
nLineHeight )
ELSE
@@ -96,13 +96,13 @@
RETURN
-STATIC FUNCTION hb_zebra_draw_hpdf( hZebra, page, ... )
+STATIC FUNCTION hb_zebra_draw_hpdf( hZebra, page, nX, nY, ... )
IF hb_zebra_GetError( hZebra ) != 0
RETURN HB_ZEBRA_ERROR_INVALIDZEBRA
ENDIF
- hb_zebra_draw( hZebra, {| x, y, w, h | HPDF_Page_Rectangle( page, x,
y, w, h ) }, ... )
+ hb_zebra_draw( hZebra, {| x, y, w, h | HPDF_Page_Rectangle( page, x,
2 * nY - y, w, - h ) }, nX, nY, ... )
HPDF_Page_Fill( page )
Viktor Szakáts
This will not work if we have a white line across all barcode, since this code do an independent y calculation (increments y by h) not related to barcode draw internals (imagine what will happen if draw internals will use callback to draw rectangles in random order).+ hb_zebra_draw( hZebra, {| x, y, w, h | HPDF_Page_Rectangle( page, x,
y + nH, w, h ) }, nX, nY, nLineWidth, -nLineHeight )
HPDF_Page_Fill( page )
If we are going top use y axis from top to bottom in testhpdf sample code, I would prefer to use a simple proposed:
HPDF_Page_Rectangle( page, x, 2 * nY - y, w, -h )
If this is not clear expression (why do we have to multiply something by 2), I can right it in a different way:nY - ( y - nY )
i.e.
decrease nY by distance of rectangle relative position from nY, i.e. by (y - nY).
Bellow is diff that makes testhpdf work exactly (the same text and barcode positioning) as testcairo (except distance between barcodes).
Mindaugas Kavaliauskas
On 2010.11.13 18:54, Viktor Szakáts wrote:
> + hb_zebra_draw( hZebra, {| x, y, w, h | HPDF_Page_Rectangle(
> page, x,
> y + nH, w, h ) }, nX, nY, nLineWidth, -nLineHeight )
> HPDF_Page_Fill( page )
>
> This will not work if we have a white line across all barcode, since
> this code do an independent y calculation (increments y by h) not
> related to barcode draw internals (imagine what will happen if draw
> internals will use callback to draw rectangles in random order).
>
> True, which seems to mean we will have offer
> a way for caller to calculate final dimensions of
> the barcode. [ which could also be used for
> painting background ]
Sorry, I completely do not understand why are you talking about barcode
dimensions and background painting. We are solving the question of
vertical flipping if y axis direction on backend is bottom to top.
> If we are going top use y axis from top to bottom in testhpdf sample
> code, I would prefer to use a simple proposed:
>
> HPDF_Page_Rectangle( page, x, 2 * nY - y, w, -h )
>
>
> This would be good, but the position is lost, so it's
> practically unusable, unless the caller "guesses" its
> size and shifts the base position accordingly (and
> does only that, when using PDF backend)
What position is lost??? What guesses should be made? I do not
understand you. In the previous mail I've added diff of testhpdf.prg. It
is tested and produces a perfect valid pdf file.
> Or, maybe HB_ZEBRA_DRAW() could solve this
> automatically when nLineHeight is negative.
>
> Could this be implemented? This codes knows the
> total height.
There is no need to know barcodes total height for vertical flipping.
Just draw on bar under another, but lower than previous instead of
higher than previous (that was happening to hpdf until now). My previous
diff do it.
But you give me a perfect idea. Instead of changing
HPDF_Page_Rectangle( page, x, y, w, h )
to
HPDF_Page_Rectangle( page, x, 2 * nY - y, w, -h )
we can change
hb_zebra_draw_hpdf( hZebra, page, 300, nY, nLineWidth, nLineHeight )
to
hb_zebra_draw_hpdf( hZebra, page, 300, nY, nLineWidth, - nLineHeight )
to reach exactly the same result. So, I attached one more tested diff.
> If this is not clear expression (why do we have to multiply
> something by 2), I can right it in a different way:
> nY - ( y - nY )
> i.e.
> decrease nY by distance of rectangle relative position from nY,
> i.e. by (y - nY).
>
> Bellow is diff that makes testhpdf work exactly (the same text and
> barcode positioning) as testcairo (except distance between barcodes).
>
> It's not a solution, since you manually tweaked the
> higher level caller code to accommodate to special PDF
> drawing backend needs. IMO backends should behave
> similarly in regards of positioning, otherwise it will be
> very difficult to offer general barcode printing which
> transparently handles all backends.
No, I've done no more than:
841 - nY
do. Just 841 is nY, and nY is y - nY in this case.
I just inverted the drawing direction for backend, which have a negative
relative coordinate for next line. I think this should be done by
backend (manage it's coordinate mapping properties). Maybe you'll find
my next diff as a more clear solution.
Regards,
Mindaugas
@@ -82,10 +82,10 @@
nLineHeight := 16
ENDIF
HPDF_Page_BeginText( page )
- HPDF_Page_TextOut( page, 40, nY, cType )
- HPDF_Page_TextOut( page, 150, nY, hb_zebra_getcode( hZebra ) )
+ HPDF_Page_TextOut( page, 40, nY - 13, cType )
+ HPDF_Page_TextOut( page, 150, nY - 13, hb_zebra_getcode(
hZebra ) )
HPDF_Page_EndText( page )
- hb_zebra_draw_hpdf( hZebra, page, 300, nY, nLineWidth,
nLineHeight )
+ hb_zebra_draw_hpdf( hZebra, page, 300, nY, nLineWidth, -
nLineHeight )
ELSE
? "Type", cType, "Code", cCode, "Error", hb_zebra_geterror(
hZebra )
ENDIF
Viktor Szakáts
Sorry, I completely do not understand why are you talking about barcode dimensions and background painting. We are solving the question of vertical flipping if y axis direction on backend is bottom to top.True, which seems to mean we will have offer
a way for caller to calculate final dimensions of
the barcode. [ which could also be used for
painting background ]
This would be good, but the position is lost, so it's
practically unusable, unless the caller "guesses" its
size and shifts the base position accordingly (and
does only that, when using PDF backend)
transparently handles all backends.
No, I've done no more than:
841 - nY
do. Just 841 is nY, and nY is y - nY in this case.
I just inverted the drawing direction for backend, which have a negative relative coordinate for next line. I think this should be done by backend (manage it's coordinate mapping properties). Maybe you'll find my next diff as a more clear solution.
Mindaugas Kavaliauskas
On 2010.11.13 20:05, Viktor Szakáts wrote:
> Thank you, this patch is indeed more clear and it looks alright.
>
> To move the logic inside HB_ZEBRE_DRAW_HPDF(), this
> worked for me:
> ---
> STATIC FUNCTION hb_zebra_draw_hpdf( hZebra, page, nX, nY, nLineWidth,
> nLineHeight )
>
> IF hb_zebra_GetError( hZebra ) != 0
> RETURN HB_ZEBRA_ERROR_INVALIDZEBRA
> ENDIF
>
> hb_zebra_draw( hZebra, {| x, y, w, h | HPDF_Page_Rectangle( page, x,
> y, w, h ) }, nX, nY, nLineWidth, -nLineHeight )
>
> HPDF_Page_Fill( page )
>
> RETURN 0
Yes. I actually was thinking about the place of this "-" sign: to put
inside of hb_zebra_draw_hpdf() or the caller should put "-" before the
lineheight parameter to make the parameter have negative value.
I'd say this is the philosophical question. The main difference in these
up/down coordinate conversions is that to draw a rectangle having width
and height with (left, top) corner in hpdf, you should call:
HPDF_Page_Rectangle( left, top, width, - height )
If you call
HPDF_Page_Rectangle( left, top, width, height )
you'll get rectangle than has (left, top) coordinates in left bottom
corner instead of left top.
If I assume, that hb_zebra_draw_hpdf() has nLineHeight parameter as a
positive value indicating line height, the function should look like
you've written above.
But, if hpdf user are used to the fact that they have pass negative
values for a height to get a (left,top) to be a left top corner, then
negative value should be passed as nLineHeight and we do not need this
"-" inside hb_zebra_draw_hpdf().
Regards,
Mindaugas
rectangle( left, top, top, left
wanted
> ---
>
> Viktor
>
Viktor Szakáts
Yes. I actually was thinking about the place of this "-" sign: to put inside of hb_zebra_draw_hpdf() or the caller should put "-" before the lineheight parameter to make the parameter have negative value.---
STATIC FUNCTION hb_zebra_draw_hpdf( hZebra, page, nX, nY, nLineWidth,
nLineHeight )
IF hb_zebra_GetError( hZebra ) != 0
RETURN HB_ZEBRA_ERROR_INVALIDZEBRA
ENDIF
hb_zebra_draw( hZebra, {| x, y, w, h | HPDF_Page_Rectangle( page, x,
y, w, h ) }, nX, nY, nLineWidth, -nLineHeight )
HPDF_Page_Fill( page )
RETURN 0
I'd say this is the philosophical question. The main difference in these up/down coordinate conversions is that to draw a rectangle having width and height with (left, top) corner in hpdf, you should call:
If I assume, that hb_zebra_draw_hpdf() has nLineHeight parameter as a positive value indicating line height, the function should look like you've written above.
But, if hpdf user are used to the fact that they have pass negative values for a height to get a (left,top) to be a left top corner, then negative value should be passed as nLineHeight and we do not need this "-" inside hb_zebra_draw_hpdf().
Tamas TEVESZ
> It well is philosophical... I finally felt it better to leave the negative
> sign
> on the caller end (as in your last patch), since the code where I'm making
> the call from is HPDF specific already, so such "trick" doesn't stick out,
it is a possible trap, and i believe it should stick out, carrying a
sign which is written on with friendly letters, "know your backend
well!", quite possibly to the extent of
- hb_zebra_draw_hpdf( hZebra, page, 300, nY, nLineWidth, -nLineHeight )
+ HPDF_Page_GSave( page )
+ HPDF_Page_Concat( page, 1, 0, 0, -1, 300, nY )
+ hb_zebra_draw_hpdf( hZebra, page, 0, 0, nLineWidth, nLineHeight )
+ HPDF_Page_GRestore( page )
> The good thing is that we don't have to decide about it because
> the backends are quite simple callbacks which can be easily copied
> from test code (and tweaked) by all users, so it's not some hard-coded
> "official" API behavior.
agreed, but it also should be emphasized that backends are not
interchangeable without certain adjustments (like the coordinate
system transformation in this specific case).
> [ only if we once plan to add HB_ZEBRA_DRAW_*() to each of their
> backend-specific libs, it will be a decision to make. But so far I
> see it's not worth the complication. ]
--
[-]
mkdir /nonexistent
Viktor Szakáts
it is a possible trap, and i believe it should stick out, carrying a
sign which is written on with friendly letters, "know your backend
well!", quite possibly to the extent of
- hb_zebra_draw_hpdf( hZebra, page, 300, nY, nLineWidth, -nLineHeight )
+ HPDF_Page_GSave( page )
+ HPDF_Page_Concat( page, 1, 0, 0, -1, 300, nY )
+ hb_zebra_draw_hpdf( hZebra, page, 0, 0, nLineWidth, nLineHeight )
+ HPDF_Page_GRestore( page )
> The good thing is that we don't have to decide about it becauseagreed, but it also should be emphasized that backends are not
> the backends are quite simple callbacks which can be easily copied
> from test code (and tweaked) by all users, so it's not some hard-coded
> "official" API behavior.
interchangeable without certain adjustments (like the coordinate
system transformation in this specific case).
Tamas TEVESZ
> > - hb_zebra_draw_hpdf( hZebra, page, 300, nY, nLineWidth,
> > -nLineHeight )
> > + HPDF_Page_GSave( page )
> > + HPDF_Page_Concat( page, 1, 0, 0, -1, 300, nY )
> > + hb_zebra_draw_hpdf( hZebra, page, 0, 0, nLineWidth, nLineHeight )
> > + HPDF_Page_GRestore( page )
> >
>
> In case we'd make HB_ZEBRA_DRAW_HPDF() an official
> API, pbly it'd be good idea to integrate above HPDF calls inside
> the API itself. Though I'm too confused about coordinates
> to do it now :/ BTW, isn't that slower than Mindaugas's
> solution? (on moving the negative sign inside the callee)
it most probably is, but speed and flexibility usually come with
tradeoffs :) on the other hand, this way it won't lose any other
transforms already applied to the page (i hope, but i'm not yet
finished with this line of thought).
suppose for a moment that your application routinely produces a4-sized
documents of some sort, which, for the sake of argument, contain
barcodes.
now comes a client, and says, jolly good software, but i need a5-sized
documents. now, you can either start converting each and every
coordinate (and size!) your application uses, or you can simply stick
HPDF_Page_Concat( page, i don't want to do the math now ) *once* after
your HPDF_Page_SetSize( page, HPDF_PAGE_SIZE_A4, ... ) and be done
with it.
i am pretty sure such facilities exist in other (all?) page/document
description systems, and taking this flexibility away for 0.002
nanoseconds of runtime speedup wouldn't really be such a good idea :)
> Well, IMO they should be interchangeable in case make them
> official backend-specific APIs. Until they are in 'tests' though,
> we're free to do anything, since they are not APIs, just some helper
> functions. What's important now, is that core HB_ZEBRA_DRAW()
> is fully backend agnostic and consistent.
indeed. and while they are in `tests', we have time to figure out the
pitfalls.
--
[-]
mkdir /nonexistent
Mindaugas Kavaliauskas
On 2010.11.13 16:37, Guy Roussin wrote:
> $ zbarimg testhpdf.pdf
> ...
> Note that there is some mistake ... but it analyse the full pdf !
I have a question. I've downloaded zbar for Windows. It also eats pdf
files. How? It has iconv, jpeg, ImageMagic, png, tiff, xml, zlib .dll.
None of it do pdf rendering (AFAIK). Does zbar uses some default systems
.pdf application via OLE to render .pdf? I doubt. How it can read pdf???
Regards,
Mindaugas
Tamas TEVESZ
hi,
> I have a question. I've downloaded zbar for Windows. It also eats pdf files.
> How? It has iconv, jpeg, ImageMagic, png, tiff, xml, zlib .dll. None of it do
> pdf rendering (AFAIK). Does zbar uses some default systems .pdf application
> via OLE to render .pdf? I doubt. How it can read pdf???
imagemagick does pdf.
--
[-]
mkdir /nonexistent
Mindaugas Kavaliauskas
On 2010.11.13 22:07, Viktor Szakáts wrote:
> In case we'd make HB_ZEBRA_DRAW_HPDF() an official
> API, pbly it'd be good idea to integrate above HPDF calls inside
> the API itself. Though I'm too confused about coordinates
> to do it now :/ BTW, isn't that slower than Mindaugas's
> solution? (on moving the negative sign inside the callee)
It should not be slower. If drawing engine supports some global
transform matrix, it only alters matrix's values. All drawing operations
are transformed using this matrix anyway. So, it does not mean that this
way our rectangles will be processed by some extra operations. I do not
know how fast is context save/restore operations, but it is common for
postscript and pdf, so, renderer for sure can cope with it. But I see no
problem to reach any behaviour here. There is a question that we want to
reach. It is difficult to decide until we will not have same real life
application with several backends. F.e., maybe application developer do
drawing of mathematical charts and expects y direction from bottom to
top. In this case he will expect:
DrawBarcode( hCairo, 20, 1, "EAN13", "477012345678" )
DrawBarcode( hCairo, 40, 1, "EAN8", "1234567" )
DrawBarcode( hCairo, 60, 1, "UPCA", "01234567891" )
DrawBarcode( hCairo, 80, 1, "UPCE", "123456" )
DrawBarcode( hCairo, 100, 1, "CODE39", "ABC123" )
to draw Code39 barcode at the top of page instead of bottom. I do not
care about it a lot now. If I have some needs in real life app, I can
include 10 lines function to do correct drawing.
Regards,
Mindaugas
Bacco
the function, and the function should be always device independent.
Maybe something in the lines of
DRAWBARCODE( TYPE, DATA, X, Y, SIZEX, SIZEY, CODEBLOCK)
I provide the starting X and Y, and the SIZEX and SIZEY (that can be
negative) so HB_ZEBRA calls the codeblock provided using the values
scaled to SIZEX/Y.
Viktor Szakáts
It should not be slower. If drawing engine supports some global transform matrix, it only alters matrix's values. All drawing operations are transformed using this matrix anyway. So, it does not mean that this way our rectangles will be processed by some extra operations. I do not know how fast is context save/restore operations, but it is common for postscript and pdf, so, renderer for sure can cope with it. But I see no problem to reach any behaviour here. There is a question that we want to reach. It is difficult to decide until we will not haveIn case we'd make HB_ZEBRA_DRAW_HPDF() an official
API, pbly it'd be good idea to integrate above HPDF calls inside
the API itself. Though I'm too confused about coordinates
to do it now :/ BTW, isn't that slower than Mindaugas's
solution? (on moving the negative sign inside the callee)
same real life application with several backends. F.e., maybe application developer do drawing of mathematical charts and expects y direction from bottom to top. In this case he will expect:
DrawBarcode( hCairo, 20, 1, "EAN13", "477012345678" )
DrawBarcode( hCairo, 40, 1, "EAN8", "1234567" )
DrawBarcode( hCairo, 60, 1, "UPCA", "01234567891" )
DrawBarcode( hCairo, 80, 1, "UPCE", "123456" )
DrawBarcode( hCairo, 100, 1, "CODE39", "ABC123" )
to draw Code39 barcode at the top of page instead of bottom. I do not care about it a lot now. If I have some needs in real life app, I can include 10 lines function to do correct drawing.
Viktor Szakáts
Mindaugas Kavaliauskas
> > I have a question. I've downloaded zbar for Windows. It also eats pdf files.
> > How? It has iconv, jpeg, ImageMagic, png, tiff, xml, zlib .dll. None of it do
> > pdf rendering (AFAIK). Does zbar uses some default systems .pdf application
> > via OLE to render .pdf? I doubt. How it can read pdf???
>
> imagemagick does pdf.
OK, I found it. On another PC I get error message:
============
C:\Program Files\ZBar\bin>zbarimg.exe c:\tmp\testcair.pdf
zbarimg.exe: `%s': %s "gs" -q -dQUIET -dSAFER -dPARANOIDSAFE -dBATCH
-dNOPAUSE -dNOPROMPT -dMaxBitma
p=500000000 -dAlignToPixels=0 -dGridFitTT=0 "-sDEVICE=pnmraw"
-dTextAlphaBits=4 -dGraphicsAlphaBits=
4 "-r72x72"
"-sOutputFile=C:/DOCUME~1/mind/LOCALS~1/Temp/magick-M4QmfzsX"
"-fC:/DOCUME~1/mind/LOCAL
S~1/Temp/magick-fADSZx9s"
"-fC:/DOCUME~1/mind/LOCALS~1/Temp/magick-L_YxPT0W" @ utility.c/SystemComma
nd/1881.
ERROR: PostscriptDelegateFailed `c:\tmp\testcair.pdf': No such file or
directory @ pdf.c/ReadPDFImag
e/611
============
ImageMagic uses ghostscript engine to render pdf. The nice thing is that
GS is not even on the PATH. ImageMagic looks for various registry keys:
HKLM\Software\AFPL Ghostscript
HKLM\Software\Alladin Ghostscript
HKLM\Software\GNU Ghostscript
HKLM\Software\GPL Ghostscript
until it finds installed Ghostscript engine.
I should keep it in my mind if I'll ever need to render pdf in my app.
Regards,
Mindaugas
Guy Roussin
i use zbarimg from zbar-tools on debian. Note that it depends on libmagick ...
see also :
http://sourceforge.net/apps/mediawiki/zbar/index.php?title=FAQ#Can_zbarimg_scan_a_PDF.2FPS_file.3F
Guy
$ apt-cache show zbar-tools
Package: zbar-tools
Priority: optional
Section: graphics
Installed-Size: 108
Maintainer: Bernd Zeimetz <bz...@debian.org>
Architecture: i386
Source: zbar
Version: 0.10+doc-4
Depends: libc6 (>= 2.3.6-6~), libice6 (>= 1:1.0.0), libjpeg62 (>= 6b1), libmagickcore3 (>=
8:6.6.0.4), libmagickwand3 (>= 8:6.6.0.4), libsm6, libx11-6, libzbar0 (= 0.10+doc-4)
Filename: pool/main/z/zbar/zbar-tools_0.10+doc-4_i386.deb
Size: 36792
MD5sum: 0b24ca5e50bc3845a194c624ea9e7ae2
SHA1: 1ef46bcc2bf5668cbcee8d34c471ba21f1aab8d9
SHA256: b9343c29ce2f528850318726fb93031aafc94bcce4fd724a41bda5ac0b32e5e0
Description: bar code scanner and decoder (utilities)
ZBar is a library for scanning and decoding bar codes from various sources
such as video streams, image files or raw intensity sensors. It supports
EAN-13/UPC-A, UPC-E, EAN-8, Code 128, Code 39, Interleaved 2 of 5 and QR Code.
.
This package contains basic applications for decoding captured bar code images
and using a video4linux device (e.g. webcam) as a bar code scanner.
Homepage: http://zbar.sourceforge.net/
Qatan
First of all, thank you for such a nice and very important component to
Harbour.
Its nice to learn from you all.
Try just typing: " zbarimg testhpdf.pdf " and it will give you the
desired results.
Zbar is other nice tool
Regards
Qatan
Mindaugas Kavaliauskas
On 2010.11.14 04:37, Qatan wrote:
> Try just typing: " zbarimg testhpdf.pdf " and it will give you the
> desired results.
I'm a person, who is more interested in how things work than do they
work at all. So, just typing won't give me a desired result (i.e. an
answer). I've already found an answer.
I have not tried it with camera yet, but zbar is really a great tool!
The only wish for it is to increase the number of supported barcodes.
Regards,
Mindaugas
Mindaugas Kavaliauskas
On 2011.11.15 18:04, Qatan wrote:
> I made a small application that creates a PDF with barcode and you
> contribution came on the right time!
> BTW, I realized that Haru and Cairo both can produce PDF files, right?
> Well, what is the advantage / disvantage of using one or other? I am
> right now using Haru because I didn't know about Cairo but I would like
> to know any information / comparation about CAIRO x HARU.
I know not much about hpdf. I've just looked at testhpdf.pdf file using
plain view (F3 in Far manager) once. And I saw a HPDF_Page_Fill() source
(it prints pdf "f" (fill) command to some stream), when I was looking
for a possibility to do fill without stroke for hbzebra test.
1) hbcairo requires external dll (for GPL project you can include it
into .exe, but be prepared for building cairo. It will not be easy if
you're windows guy);
1) hbhpdf can be linked into the same .exe. hpdf is included into
Harbour's development tree.
2) hbcairo compresses pdf objects;
2) hbhpdf does not compress objects. So, any text/hex editor is a good
tool to have an introduction to pdf internals. This is important if you
are more interested in how things work and do not have pdftk utility for
pdf uncompression :)
3) hbcairo has many drawing backends. I.e. you can draw using the same
functions to: pdf, memory image (later save to png), windows DC,
postscript, gtk, svg, QT, OpenGL, xlib (X Windows), quartz (Mac OS),
recording (you can replay draw operation to another surface later), etc.
3) hbhpdf do pdf files only;
4) hbcairo embeds fonts;
4) I'm not sure if hbhpdf uses some font embedding, but testpdf.pdf used
internal predefined pdf fonts only, that is required to be supported by
viewer. You should have to try do some printing of national characters
that are not included into predefined pdf charsets to make this clear.
5) hbcairo is a more large and complex library used by many apps (all
gtk, Firefox, etc.), though it is only 1MB .dll without external
dependencies.
5) hbhpdf is more simple and lightweight.
Regards,
Mindaugas
Qatan
> I know not much about hpdf. I've just looked at testhpdf.pdf file using
> plain view (F3 in Far manager) once. And I saw a HPDF_Page_Fill() source
> (it prints pdf "f" (fill) command to some stream), when I was looking for
> a possibility to do fill without stroke for hbzebra test.
Thank you for sharing what you know
> 1) hbcairo requires external dll (for GPL project you can include it into
> .exe, but be prepared for building cairo. It will not be easy if you're
> windows guy);
> 1) hbhpdf can be linked into the same .exe. hpdf is included into
> Harbour's development tree.
You are right. I use Windows and can tell it was very difficult to build
Cairo, acctually I couldn't and have to use the DLL you provided time ago on
the list. This is imho an disadvantage.
Being GPL means I have to make my program GPL too, right? Disadvantage too
(imho).
BTW is it possible to integrate the libcairo-2.dll to the .EXE?
To build Haru example was easier for me...
> 2) hbcairo compresses pdf objects;
> 2) hbhpdf does not compress objects. So, any text/hex editor is a good
> tool to have an introduction to pdf internals. This is important if you
> are more interested in how things work and do not have pdftk utility for
> pdf uncompression :)
It may save space and specially in my case I need to send emails with
generated PDFs
But are you sure hbhpdf does not compress objects? What about
HPDF_SetCompressionMode()?
I just openned a PDF with a text editor for the first time - pretty
interesting... Thanks for the idea.
> 3) hbcairo has many drawing backends. I.e. you can draw using the same
> functions to: pdf, memory image (later save to png), windows DC,
> postscript, gtk, svg, QT, OpenGL, xlib (X Windows), quartz (Mac OS),
> recording (you can replay draw operation to another surface later), etc.
> 3) hbhpdf do pdf files only;
Cairo is very powerful and multi purpose. Good to know that. May be useful
anytime.
Seems that Haru is easier and very specific for PDFs
> 4) hbcairo embeds fonts;
> 4) I'm not sure if hbhpdf uses some font embedding, but testpdf.pdf used
> internal predefined pdf fonts only, that is required to be supported by
> viewer. You should have to try do some printing of national characters
> that are not included into predefined pdf charsets to make this clear.
Haru does embeds type 1 fonts. I had to do it before you came with hbzebra
barcodes.
HPDF_LoadType1FontFromFile() loads a Type1 font from an external file and
registers it in the document object.
I had to embed type 1 barcode font with a limited char table to not make a
supersized PDF file and it works but the size is still too big compared to
same visual results with hbzebra barcode.
My progress:
1) I first used TTF font (ugly solution and I had to send the font to be
installed on the destination system)
2) Tried to change to Zint (creating an external PNG file to be used in my
PDF - other ugly solution but a bit better)
3) Embed type 1 barcode font but the PDF file was huge in size
4) Embed type 1 barcode font but just a limited char table - made smaller
files, was my final solution until you came with hbzebra that is much, much
better now and does not require any external file!
> 5) hbcairo is a more large and complex library used by many apps (all gtk,
> Firefox, etc.), though it is only 1MB .dll without external dependencies.
> 5) hbhpdf is more simple and lightweight.
Right.
Thanks for sharing your knowledge with me. I really appreciate your
comments.
Regards,
Qatan
Miguel Angel Marchuet
cvs -d:pserver:anon...@bmdbfcdx.cvs.sourceforge.net:/cvsroottoo is REDBFCDX client/server compatible with xharbour server.
we use it because has faster results than other ways.
at next future we want to pass client/server to microsoft rcp subsystem
faster than actual.
Best regards,
Miguel Angel Marchuet
Viktor Szakáts
cvs -d:pserver:anon...@bmdbfcdx.cvs.sourceforge.net:/cvsroot
too is REDBFCDX client/server compatible with xharbour server.
we use it because has faster results than other ways.
marchuet
you are wrong
On 24 nov, 20:48, Viktor Szakáts <harbour...@syenar.hu> wrote:
> > cvs -d:pserver:anonym...@bmdbfcdx.cvs.sourceforge.net:/cvsroot