So check it out. I made a little chart showing the start and stop codes 
for various types of (1D) barcodes. Now I can tell which type of barcode 
I'm looking at.

(Actually, so far I've yet to find anything with a barcode other than 
the four on the right. However, I'm told that packing cartons often use 
a varient of I25...)

Post a reply to this message

Attachments:
Download 'barcode types 2.pdf' (3 KB)

"Invisible" <voi### [at] devnull> wrote in message 
news:4aeabae6$1@news.povray.org...
> So check it out. I made a little chart showing the start and stop codes
> for various types of (1D) barcodes. Now I can tell which type of barcode
> I'm looking at.
>
> (Actually, so far I've yet to find anything with a barcode other than
> the four on the right. However, I'm told that packing cartons often use
> a varient of I25...)
>

In all of the programming projects I've ever done involving printing of bar 
codes, I've only ever used those... mostly code 39, although I used 128 once 
for making very small bar codes, and 2 of 5 for an PO system where the 
vendor specs required that format.

In most cases, I've used some external tool, like a specialized bar code 
printer, to generate the symbols. I did once (about 15 years ago) have to 
write a program to generate code 39 on a laser printer by iterating the 
rectangles myself. I had to copy the spacing out of a book, which was a 
weekend well spent, let me tell you. :D

Post a reply to this message

Captain Jack wrote:

>> (Actually, so far I've yet to find anything with a barcode other than
>> the four on the right. However, I'm told that packing cartons often use
>> a varient of I25...)
> 
> In all of the programming projects I've ever done involving printing of bar 
> codes, I've only ever used those... mostly code 39, although I used 128 once 
> for making very small bar codes, and 2 of 5 for an PO system where the 
> vendor specs required that format.

Indeed, code 39 and code 128 seem quite popular. I've found very few 
code 93 barcodes. (And, obviously, UPC-A / EAN-13 is everywhere.)

> In most cases, I've used some external tool, like a specialized bar code 
> printer, to generate the symbols. I did once (about 15 years ago) have to 
> write a program to generate code 39 on a laser printer by iterating the 
> rectangles myself. I had to copy the spacing out of a book, which was a 
> weekend well spent, let me tell you. :D

In PostScript, it's not a challenging thing to do. (As you can see, I've 
just done it.)

I'm currently writing a small Haskell library for this. Currently it 
understands 2 of 5 standard and interleaved, code 128, and I'm currently 
implementing code 39. Of course, the library only handles converting 
characters into 1s and 0s and back again. In "real" barcode handling 
things are far more complex; bar thicknesses have to be within certain 
tollerances when printing, and scanning is a fairly sophisticated problem...

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message 
news:4aeaea24@news.povray.org...
> I'm currently writing a small Haskell library for this. Currently it 
> understands 2 of 5 standard and interleaved, code 128, and I'm currently 
> implementing code 39. Of course, the library only handles converting 
> characters into 1s and 0s and back again. In "real" barcode handling 
> things are far more complex; bar thicknesses have to be within certain 
> tollerances when printing, and scanning is a fairly sophisticated 
> problem...

I've never tried to implement a scanning algorithm, but it looks like an 
interesting challenge. Not much novelty in it, I s'pose, although there 
might be some room to develop more sophisticated two dimensional bar code 
scanning processes.

When I had to make my own code 39, I coded for a specific model of laser 
printer at 300 dpi, and I translated the tolerances to integer values before 
I made my translation table, then translated those into the graphics command 
that drew filled rectangles on the printer. That restricted the size 
variations I could do, but it kept me from having slight variations in size 
due to rounding errors; mostly all that was so that I could get the software 
done and out the door quickly.

Post a reply to this message

Captain Jack wrote:

> I've never tried to implement a scanning algorithm, but it looks like an 
> interesting challenge. Not much novelty in it, I s'pose, although there 
> might be some room to develop more sophisticated two dimensional bar code 
> scanning processes.

The fun part of scanning, of course, is this:

1. You have to figure out where the hell the edges of the barcode are.

2. You have to work out how far away the barcode is, and hence how wide 
each of the bars is.

3. If the barcode has been scanned at an angle, the bar thicknesses may 
be different at one end verses the other end, and you need to compensate 
for this.

4. The barcode might be dirty, and you need to account for and reject 
noise in the signal.

5. You have to figure out which kind of barcode this is.

6. The barcode could be upside down. (E.g., my tape labels have all the 
barcodes actually printed the wrong way round. Go figure.) If so, you 
need to detect this and flip the barcode.

7. The barcode scan could be incomplete. (E.g., the scanner beam goes 
across a corner of the barcode, only picking up some of the bars.)

8. If you're using a 2D *camera* instead of a real laser barcode 
scanner, multiply all of the above issues by 7.

It's not as trivial as it sounds. ;-)

> When I had to make my own code 39, I coded for a specific model of laser 
> printer at 300 dpi, and I translated the tolerances to integer values before 
> I made my translation table, then translated those into the graphics command 
> that drew filled rectangles on the printer. That restricted the size 
> variations I could do, but it kept me from having slight variations in size 
> due to rounding errors; mostly all that was so that I could get the software 
> done and out the door quickly. 

Yeah, well, PostScript makes it fairly easy to draw a few rectangles at 
an exact absolute size on any compatible printer. (The print tolerances, 
however, will vary by model. I'd suspect that, e.g., an inkjet printer 
probably won't print small barcodes with sufficient accuracy.)

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message 
news:4aeaee56$1@news.povray.org...
> It's not as trivial as it sounds. ;-)

Sorry, didn't meant to imply it wasn't hard, just that other people have 
done it a few times. :)

I'm currently working (in my spare time) on trying to write a fluid dynamics 
solver, which also isn't novel, but it's new to me. I got into it thinking, 
"How hard can it be?"

Hoo, boy.

Post a reply to this message

Captain Jack wrote:

> I'm currently working (in my spare time) on trying to write a fluid dynamics 
> solver, which also isn't novel, but it's new to me. I got into it thinking, 
> "How hard can it be?"
> 
> Hoo, boy.

Hahahahaha.

0WN3D!



Here, have a cookie:

http://www.youtube.com/watch?v=58_s6r7PaKo

This is what happens when you play with a simple non-linear dynamical 
system. (It represents about a day's worth of computer time, BTW.)

Post a reply to this message

> I'd suspect that, e.g., an inkjet printer probably won't print small 
> barcodes with sufficient accuracy.)

You can buy parcel shipping online here in Germany, and you get a label to 
print out with the barcode on.  This is then scanned by the machine at the 
unmanned drop-off point.  Once my inkjet had a blocked nozzle and I was 
there for 10 minutes trying to get the damn thing to scan.  Then I realised 
what the problem was, got a black pen and filled in the bar that had a bit 
missing by hand - it worked!

Post a reply to this message

scott wrote:

> You can buy parcel shipping online here in Germany, and you get a label 
> to print out with the barcode on.  This is then scanned by the machine 
> at the unmanned drop-off point.  Once my inkjet had a blocked nozzle and 
> I was there for 10 minutes trying to get the damn thing to scan.  Then I 
> realised what the problem was, got a black pen and filled in the bar 
> that had a bit missing by hand - it worked!

That's pretty epic, really... :-D

Actually, I notice the Royal Mail let you buy "stamps" online now, where 
the stamp is actually a PDF file which prints out a 2D barcode...

Oh, and I finally found out what all those zig-zags are for:

http://en.wikipedia.org/wiki/RM4SCC

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message 
news:4aeaf3f8$1@news.povray.org...
> Captain Jack wrote:
>
>> I'm currently working (in my spare time) on trying to write a fluid 
>> dynamics solver, which also isn't novel, but it's new to me. I got into 
>> it thinking, "How hard can it be?"
>>
>> Hoo, boy.
>
> Hahahahaha.
>
> 0WN3D!
>
>
>
> Here, have a cookie:
>
> http://www.youtube.com/watch?v=58_s6r7PaKo
>
> This is what happens when you play with a simple non-linear dynamical 
> system. (It represents about a day's worth of computer time, BTW.)

I look forward to seeing it with great anticipation. However, it's about 
10:15 AM on a Friday where I'm at now, which puts me at the office, which 
has blocked YouTube and almost everything else that's interesting.

Fortunately, the blocking software service that we use appears to think that 
the Internet and the Web are the same thing, so I can come here to cool off 
my brain cells. Puts me in mind of a friend of mine, who once said to me, 
"Usenet? Is that new? What's their web site look like?"

Post a reply to this message

Invisible schrieb:

> 8. If you're using a 2D *camera* instead of a real laser barcode 
> scanner, multiply all of the above issues by 7.

Not really. Just pick a random straight line through the picture, and 
pretend that's your laser beam.

Post a reply to this message

>> 8. If you're using a 2D *camera* instead of a real laser barcode 
>> scanner, multiply all of the above issues by 7.
> 
> Not really. Just pick a random straight line through the picture, and 
> pretend that's your laser beam.

Except that a human wouldn't aim the laser beam at random, see? Also, as 
I understand it, lasers don't go out of focus...

Post a reply to this message

Invisible schrieb:

> Oh, and I finally found out what all those zig-zags are for:
> 
> http://en.wikipedia.org/wiki/RM4SCC

Yeah. Back to Ogham. Somehow.

Post a reply to this message

> Except that a human wouldn't aim the laser beam at random, see?

Humans don't aim the beam, usually it's wiggled about all over the place 
automatically very quickly, in the hope of picking up a valid barcode scan 
at some point.  You could do the same on a 2D image (just pick points at 
random on the edges and scan between them).

Post a reply to this message

scott wrote:
>> Except that a human wouldn't aim the laser beam at random, see?
> 
> Humans don't aim the beam, usually it's wiggled about all over the place 
> automatically very quickly, in the hope of picking up a valid barcode 
> scan at some point.  You could do the same on a 2D image (just pick 
> points at random on the edges and scan between them).

Actually you could do better. You could search around for a rectangular 
area of white with black stuff inside it, try to figure out the 
orientation of its edges, and then skim a line across the line edge. 
It's kinda tricky though...

Post a reply to this message

> Actually you could do better. You could search around for a rectangular 
> area of white with black stuff inside it, try to figure out the 
> orientation of its edges, and then skim a line across the line edge. 
> It's kinda tricky though...

Why bother?

Post a reply to this message

scott wrote:
>> Actually you could do better. You could search around for a 
>> rectangular area of white with black stuff inside it, try to figure 
>> out the orientation of its edges, and then skim a line across the line 
>> edge. It's kinda tricky though...
> 
> Why bother?

Well, true. I guess we're all going to die anyway, so...

Post a reply to this message

Invisible schrieb:
>>> 8. If you're using a 2D *camera* instead of a real laser barcode 
>>> scanner, multiply all of the above issues by 7.
>>
>> Not really. Just pick a random straight line through the picture, and 
>> pretend that's your laser beam.
> 
> Except that a human wouldn't aim the laser beam at random, see? Also, as 
> I understand it, lasers don't go out of focus...

A human wouldn't aim a camera at random either. And as for the focus 
thing, just use an auto-focusing camera and you're there.

Of course, if you want to make the /most/ out of a camera-based device, 
to actually unleash all the advantages a camera potentially has over a 
laser-based device - now that's a totally different story...

... but in that case you'd use 2D barcodes anyway :-)

There are matrix barcodes out there that I'd expect to be particularly 
easy to use in this sort of application, featuring "bull's eye"-like 
patterns or the like to faciliate finding the center by basically doing 
some simple frequency filtering on the image.

Post a reply to this message

clipka wrote:

> There are matrix barcodes out there that I'd expect to be particularly 
> easy to use in this sort of application, featuring "bull's eye"-like 
> patterns or the like to faciliate finding the center by basically doing 
> some simple frequency filtering on the image.

Depends which symbiology.

Data Matrix uses black bars along two sides of the rectangle, as does 
Semacode. MaxiCode has a "bull's eye" of concentric circles at the 
center, while Aztec Code has concentric squares instead. And then QR 
Codes have squares on three corners...

Post a reply to this message

Invisible wrote:

> I'm currently writing a small Haskell library for this. Currently it 
> understands 2 of 5 standard and interleaved, code 128, and I'm currently 
> implementing code 39. Of course, the library only handles converting 
> characters into 1s and 0s and back again. In "real" barcode handling 
> things are far more complex; bar thicknesses have to be within certain 
> tollerances when printing, and scanning is a fairly sophisticated 
> problem...

I added a function which spits out a PostScript file containing the 
barcode. Printed one out and compared it to a real barcode that encodes 
the same messages. It seems the bar thicknesses don't quite match, but 
otherwise it's quite similar.

In particular, Code 39 uses thin and thick bars and spaces. On my 
barcode, thick is twice the size of thin, but on the real barcode it 
seems to be something like 2.5 or something. (Obviously, you can't 
easily represent this as a sequence of 1s and 0s. But hey, that's the 
Real World for ya...)

I'm almost tempted to see if the reader can actually read my barcode. 
Almost.

Post a reply to this message

Invisible schrieb:

> In particular, Code 39 uses thin and thick bars and spaces. On my 
> barcode, thick is twice the size of thin, but on the real barcode it 
> seems to be something like 2.5 or something. (Obviously, you can't 
> easily represent this as a sequence of 1s and 0s. But hey, that's the 
> Real World for ya...)

As I mentioned earlier, Code 39 doesn't require a particular 
narrow-to-wide ratio. There may be maximum and minimum limits, but 
anything in between those is fair game.

Post a reply to this message

Invisible wrote:
> Oh, and I finally found out what all those zig-zags are for:

Kewl. I like how MSWord gives you an option to print that on envelopes when 
you print envelopes. I wonder if it uses the right barcode for the right 
country? I never tried it.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

>> In particular, Code 39 uses thin and thick bars and spaces. On my 
>> barcode, thick is twice the size of thin, but on the real barcode it 
>> seems to be something like 2.5 or something. (Obviously, you can't 
>> easily represent this as a sequence of 1s and 0s. But hey, that's the 
>> Real World for ya...)
> 
> As I mentioned earlier, Code 39 doesn't require a particular 
> narrow-to-wide ratio. There may be maximum and minimum limits, but 
> anything in between those is fair game.

...which is probably why it's been printed at 2.5. That would mean it 
definitely falls within the limits, regardless of print tolerence.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message 
news:4aeaf3f8$1@news.povray.org...
> Here, have a cookie:
>
> http://www.youtube.com/watch?v=58_s6r7PaKo
>
> This is what happens when you play with a simple non-linear dynamical 
> system. (It represents about a day's worth of computer time, BTW.)

I haven't been able to see it yet, unless of course it's 30 seconds of a 
black screen with a white caption reading, "an error has occurred, try again 
later", or words to that effect. Ah well...

Post a reply to this message

Captain Jack wrote:

> I haven't been able to see it yet, unless of course it's 30 seconds of a 
> black screen with a white caption reading, "an error has occurred, try again 
> later", or words to that effect. Ah well... 

Damn, after this much of a buildup, this is going to be *so* anticlimatic...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message