http://blog.wolframalpha.com/2009/10/09/what-does-that-barcode-say/

FAIL.

Altough... now I can *print* barcodes. (Just not *read* them.)

Post a reply to this message

Invisible wrote:
> Interesting fact: I actually have a barcode scanner here. Specifically, 
> our tape robot has a barcode scanner. We've never used it, but 
> apparently our Director of IT has suddenly decided that we're going to. 
> In a few days' time I should have a stack of preprinted barcode labels.

OK, so I now have several sheets of barcode labels.

What I can't figure out is which symbiology they use. Consider, for 
example, the label for "UKM11001L3". If 1=black and 0=white, we have

[...000]101101101001010101001101101100101011010110101001011010
11011001010101101100101011010100101101101010010110100101011
011011001010101101101010100110101101101001[000...]

This doesn't seem to match anything Wolfram Alpha can come up with:

http://www.wolframalpha.com/input/?i=barcode+UKM11001L3

None of these barcodes start with the distinctive two thin bars framing 
two thick bars ("...01011011010..."). I have no idea what barcode type 
this is...

Post a reply to this message

On 10/23/2009 8:58 AM, Invisible wrote:
> OK, so I now have several sheets of barcode labels.
>
> What I can't figure out is which symbiology they use. Consider, for
> example, the label for "UKM11001L3". If 1=black and 0=white, we have
>
> [...000]101101101001010101001101101100101011010110101001011010
> 11011001010101101100101011010100101101101010010110100101011
> 011011001010101101101010100110101101101001[000...]
>
> This doesn't seem to match anything Wolfram Alpha can come up with:
>
> http://www.wolframalpha.com/input/?i=barcode+UKM11001L3
>
> None of these barcodes start with the distinctive two thin bars framing
> two thick bars ("...01011011010..."). I have no idea what barcode type
> this is...

Why not upload a scan of the barcode?

Mike

Post a reply to this message

SharkD wrote:

> Why not upload a scan of the barcode?

I'd need a scanner to do that.

Post a reply to this message

Invisible wrote:
> SharkD wrote:
> 
>> Why not upload a scan of the barcode?
> 
> I'd need a scanner to do that.

A camera will do too.

Post a reply to this message

Invisible schrieb:

> OK, so I now have several sheets of barcode labels.
> 
> What I can't figure out is which symbiology they use. Consider, for 
> example, the label for "UKM11001L3". If 1=black and 0=white, we have
> 
> [...000]101101101001010101001101101100101011010110101001011010
> 11011001010101101100101011010100101101101010010110100101011
> 011011001010101101101010100110101101101001[000...]
> 
> This doesn't seem to match anything Wolfram Alpha can come up with:
> 
> http://www.wolframalpha.com/input/?i=barcode+UKM11001L3
> 
> None of these barcodes start with the distinctive two thin bars framing 
> two thick bars ("...01011011010..."). I have no idea what barcode type 
> this is...

Now if you think that those three barcodes on the Wolfram page are all 
the world has to offer...

http://www.herdsoft.com/ti/davinci4/examples/barcodecgi.cgi is convinced 
that it is a "Code 39" (aka "Code 3 of 9") barcode, and indeed correctly 
reads it as "UKM11001L3".

Closer analysis of your barcode pattern shows that your barcode indeed 
appears to be Code 39, but flipped horizontally for some reason (which 
of course should not matter to a barcode reader).

BTW, Wolfram is doing a poor job at generating Code 39 barcodes, as it 
uses different bar widths for the "frame" than for the "payload".

(The Code 39 frame is usually interpreted as a leading and trailing 
asterisk (*) character, as it uses the same bar sequence.)

Post a reply to this message

>> This doesn't seem to match anything Wolfram Alpha can come up with:
>>
>> http://www.wolframalpha.com/input/?i=barcode+UKM11001L3
>>
>> None of these barcodes start with the distinctive two thin bars 
>> framing two thick bars ("...01011011010..."). I have no idea what 
>> barcode type this is...
> 
> Now if you think that those three barcodes on the Wolfram page are all 
> the world has to offer...

There don't appear to be many bacode types that handle text. Many handle 
only numbers.

> http://www.herdsoft.com/ti/davinci4/examples/barcodecgi.cgi is convinced 
> that it is a "Code 39" (aka "Code 3 of 9") barcode, and indeed correctly 
> reads it as "UKM11001L3".

Really? (I can't even tell what language that page is in.)

> Closer analysis of your barcode pattern shows that your barcode indeed 
> appears to be Code 39, but flipped horizontally for some reason (which 
> of course should not matter to a barcode reader).

My word... That *does* in fact appear to match. I hadn't noticed that!

> BTW, Wolfram is doing a poor job at generating Code 39 barcodes, as it 
> uses different bar widths for the "frame" than for the "payload".
> 
> (The Code 39 frame is usually interpreted as a leading and trailing 
> asterisk (*) character, as it uses the same bar sequence.)

I especially love the way the bar widths don't appear to be multiples of 
each other. I almost wonder if the image has been scaled down by 
rounding each bar to a whole number of pixels, so some "thin" bars are 3 
pixels and some are 4... It's very districting!

Indeed, clicking on "PDF" and enlarging the image seems to make the 
problem go away... How annoying!

Post a reply to this message

Invisible schrieb:

>> http://www.herdsoft.com/ti/davinci4/examples/barcodecgi.cgi is 
>> convinced that it is a "Code 39" (aka "Code 3 of 9") barcode, and 
>> indeed correctly reads it as "UKM11001L3".
> 
> Really? (I can't even tell what language that page is in.)

That's German of course :-)

>> BTW, Wolfram is doing a poor job at generating Code 39 barcodes, as it 
>> uses different bar widths for the "frame" than for the "payload".
>>
>> (The Code 39 frame is usually interpreted as a leading and trailing 
>> asterisk (*) character, as it uses the same bar sequence.)
> 
> I especially love the way the bar widths don't appear to be multiples of 
> each other. I almost wonder if the image has been scaled down by 
> rounding each bar to a whole number of pixels, so some "thin" bars are 3 
> pixels and some are 4... It's very districting!

It is less surprising once you know that Code39 doesn't have fixed bar 
width ratios - just "narrow" and "wide" black and white bars (with each 
character having 3 "wide" and 6 "narrow" bars, and characters separated 
by another white bar; don't know if that is mandatorily narrow, though 
it seems common).


> Indeed, clicking on "PDF" and enlarging the image seems to make the 
> problem go away... How annoying!

Why not get one of those many Code39 TrueType fonts out there?

... or write a POV-Ray SDL script to generate barcode images :-)

Post a reply to this message

>> I especially love the way the bar widths don't appear to be multiples 
>> of each other. I almost wonder if the image has been scaled down by 
>> rounding each bar to a whole number of pixels, so some "thin" bars are 
>> 3 pixels and some are 4... It's very districting!
> 
> It is less surprising once you know that Code39 doesn't have fixed bar 
> width ratios - just "narrow" and "wide" black and white bars.

It's still confusing to have several apparently different bar widths 
which are actually supposed to be "the same". The reader might accept 
it, but for a visual example, it's sucky.

> Why not get one of those many Code39 TrueType fonts out there?
> 
> ... or write a POV-Ray SDL script to generate barcode images :-)

Why use SDL when you can use PostScript, the language of the laser 
printers? ;-)

I have in fact just written a working code-128 reader/writer today. It 
only deals with bit-sequences, but I guess the next step is to handle 
actual pictures...

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

Post a reply to this message

Invisible wrote:

> Hahaha, well... it turns out there are actually a miriad of different 
> kinds. And they're ALL COMPLETELY DIFFERENT to each other.

Interestingly, though, they all seem to have quite characteristic 
start/end markers. It appears to be possible to uniquely discriminate 
them by this alone.

(For example, UPC-A and EAN-13 both start and end with ...01010...)

> I just did a cursory scan of my office.

I see what I did there. ;-)

> Here's what I found:
> 
>   SIIG USB-serial box: UPC-A barcode plus one of unknown type.

This appears to be Code-39. (Begins 10010... and ends ...0101101101.) 
I'm guessing it encodes the serial number also printed above the barcode.

>   Maxtor drive: 5 barcodes of unknown type.

These all appear to be Code-128. (Begins 11010... and ends ...11101011.)

>   Integral RAM box: One barcode (from Insight UK) of unknown type.

This seems to be Code-39 again. (I'm guessing it encodes the large part 
number printed above, not the smaller description text.)

>   TNT shipping box: Two barcodes of unknown type.

I no longer have the box.

>   HP laptop adaptor: 3 barcodes of unknown type.

Two of these appear to be Code-39. The final one might be Code-93. Maybe.

> It's great fun. EAN-13 is apparently an "extension" of UPC-A, and yet 
> it's COMPLETELY DIFFERENT. The encoding is entirely unrelated.

 From what I can tell, the two utterly different algorithms are supposed 
to produce the same output in the case of an EAN-13 where the extra 
digit happens to be zero. I haven't varified how this is possible yet.

> The impressive thing is, as far as I can tell, almost all barcode 
> scanners support almost all kinds of barcodes. Even though each coding 
> scheme is utterly unrelated to any of the others. God only knows how 
> this is physically possible...

Again, it appears the start and stop markers are actually pretty unique 
to each barcode type. It seems to be possible to distinguish them by 
that alone, without the aid of a computer...

Post a reply to this message