I install code 128, code39 and Free 3 of 9 Extended but my barcode reader is not reading that codes
what i tried
size of barcode 24 to 48 but not succeeded
in code 39 used '*' in start and but unfortunately not succeeded
i am using normal paper normal printer. is there any need of special printer or paper?
using Ms Word to print after that i have to print in report 6i
chracters are 8,9 to genrate
is there any specific method to generate the barcode. I am just changing the font
my barcode reader is 1D BLACK COPPER BC-8806
I am generating Alpha numeric
Related
Recently I started writing a png decoder for fun.And for understanding the format and compression I have read the following
PNG (Portable Network Graphics) Specification, Version 1.2)
RFC 1950("ZLIB Compressed Data Format Specification")
RFC 1951 ("DEFLATE Compressed Data Format Specification")
And hence I have an simple understanding of the format and compression.
So at first I decided to implement a simple decoder which will decode a simple png image file,and for that i have choosen a simple png image containing a single IDAT chunk which contains a single zlib block and deflate block.
And image file used is this
Image file used for decoding
And i have extracted the zlib block from the the image file and in the hex editor it looks like this
Hex view of IDAT CHUNK
And the binary representation of the part marked in red is this
Binary representation of zlib block
Now from what i have understood from reading the specs i have decoded it as follows
Decoded binary representation of zlib block
BFINAL=FINAL BLOCK
BTYPE=DYNAMIC HUFFMAN
HLIT=29
HDIST=29
HCLEN=11
The parts marked in green is the (HCLEN + 4) code lengths for the code length alphabet.
The read lengths are as follows 6,6,0,2,3,3,5,4,4,4,3,6,4,6,5
The generated huffman codes for above code bit lengths are as follows
Generated huffman code
And after assigning them to corresponding length alphabet is as follows(Note:The length alphabet 18 is not used as its code length was zero)
Assigned huffman codes
Now when I started to decode the huffman code for the (HLIT+257) of code lengths of the huffman codes for the literal/length alphabets using the assigned huffman codes, I got the first decoded alphabet as 16,but this is not possible as alphabet 16 is copy the previous code length alphabet,but this is not possible as it is the first decoded alphabet.
Hence there is some error in my understanding of the format and i cannot seem to figure it out and this is where I need help with.
The way you're representing the codes doesn't make sense, since you are showing a bunch of zeros that aren't part of the codes, so you can't tell what their lengths are. Also you are showing the codes in reverse, as compared to how they show up in the bytes.
More importantly, somehow you got the assignments wrong. Here are the correct codes, showing only the bits in the codes, in the correct bit order, with the correct assignments:
00 - 0
010 - 7
110 - 8
001 - 11
0101 - 5
1101 - 6
0011 - 10
1011 - 12
00111 - 9
10111 - 13
001111 - 3
101111 - 4
011111 - 16 (followed by two bits, +3 is the repeat count)
111111 - 17 (followed by three bits, +3 is the zeros count)
The first code length code is 001111, which says the literal 0 has code length 3.
Using barcodes with different length (12 chars or 16 chars). Cannot find a tool to centralize the barcode depending on the length. If I set 16 chars by default, and then I will need to print a 12 char barcode, it will not centralize but cut from the right. Any ideas how can i centralize it just like the ^FB command for text fields?
My Java project deals with OCRing pdfs to index them. Each pdf page is converted into a png which is then piped to tesseract 4.
The pdf->png conversion uses renderImageWithDPI from PDFBox PdfRenderer :
buffImage = pdfRenderer.renderImageWithDPI(currentPage,
PNG_DENSITY,
ImageType.GRAY);
with PNG_DENSITY = 300 as advised on tesseract's wiki to get best results.
The OCR command is
The command used for tesseract is
tesseract input.png output -l fra --psm 1 --oem 1
I also tryed --psm 2 or 3 which also involve page segmentation ie
1 Automatic page segmentation with OSD.
2 Automatic page segmentation, but no OSD, or OCR.
3 Fully automatic page segmentation, but no OSD. (Default)
With a scanned PDF (producer/creator is Adobe Acrobat 7.0, which involves copyrighted content so I can't share it) of 146 pages, tesseract makes endless computations (the process never ends) on a given page (85).
As it was too long to test (ie : wait until page 85 gets OCRed), I decided to generate an extract of this pdf with Evince "print to file" feature.
Now the pdf produced by Evince (producer/creator is cairo 1.14.8), Tesseract handles it successfully (ie the image gets OCRed).
The difference is the image resolution. The image that fails is 4991x3508 pixels whereas the one that succeeds is only 3507x2480 pixels.
Please note : tesseract in "Sparse text with OSD" (ie --psm 12) handles the page "successfully" although the text (on 2 columns) is not understandable (ie the 2 columns are mixed)
EDIT after several trials and errors
It looks like the input image has to have a width strictly less than 4000 pixels to work with page segmentation. Looking at Tesseract source code, in a class called "pgedit" the canvas size seems limited to 4000 x 4000 as the constructor of a "ScrollView" (for whatever it serves) is :
ScrollView::ScrollView(const char* name, int x_pos, int y_pos, int x_size,
int y_size, int x_canvas_size, int y_canvas_size, bool y_axis_reversed)
So my question now is, why is there a limit of 4000 pixels wide / high to use page segmentation, and what should I do if a pdf page converted to png at 300dpi exceeds 4000 pixels (either wide or high or both) ?
Any help appreciated,
I'm reading the powerpoint specification and I came across a table like this:
Do tables like these have a name? How do I read this?
I'm pretty sure it means that the first 4 bits identifies the recVer and the next 12 identifies the recInstance, but what about recLen? Do all 32 bits pull double-duty and identify the recLen or does that mean the next 32 bits do that?
It looks like some type of packet header. The numbers at the top are the bit position. It is read left to right, top to bottom, so it is telling you that the header is made up of 4 bits interpreted as the recVer, followed by 12 bits that is interpreted as recInstance, followed by 16 bits that is the recType, followed by 32 bits which is the recLen.
This is a common way to show the header structure, as can be seen on Wikipedia's TCP page.
This is just part of the binary format for the powerpoint file. the 0,1,2 etc are the bit numbers. So you can see bit's 0 - 3 inclusive are the recVer etc.
The specification will tell you want recVer, recInstance and recType mean.
I think recLen should be obvious but it'll be in the spec.
To read it, you'd read in the bytes and then do bit manipulation to decode those fields. You don't say what language you'll be using but you can do bit manipulation in a number of languages.
Not sure about an official/standard name, but this looks like a record layout map.
You read it left to right, every box is a single bit.
The record is composed of
4 bits recVer
12 bits recInstance
16 bits recType
32 bits recLen
Within my iOS App I am using a 3rd party scanning library for scanning Code39 barcodes. This software sometimes gets the scan wrong (e.g. a value of "13415566" comes back as "U *"). Sometimes the same barcode works ok, then scan the same code again and it is wrong.
The 3rd party software vendor reports that Code39 isn't a 'reliable' format, and that 'it has no error protection and it is often possible to get false reads'.
This seems ridiculous to me. The codes in question have no check-digit, but even so, surely this is simply a bug in the scanning software? Is Code39 known for this sort of thing? How can it possibly be an adopted format if it 'gets it wrong' sometimes!
Thanks.
There should be no major issues with Code 39 readability. When used in applications where reliable scanning is important Code 39 is normally deployed with protection against misreads in the form a modulo 43 check digit that the scanner is configured to verify prior to passing the code on to the system. Any half-decent barcode generator or barcode reader will support Code 39 check digits.
As I haven't seen the print quality of the Code 39 barcodes that your are scanning it is impossible to be certain however I would certainly suggest that you are using reader software that has very poor quality Code 39 scanning.
Your barcode library is probably confused for the following reason, but it is impossible to be sure without extensive debugging of the device...
Below I have aligned two Code 39 images that were created using the online barcode generator based on Barcode Writer in Pure PostScript. On top is a horizontally flipped image containing "U" and beneath is an image containing "13415566".
Reading the top image from right-to-left you can see that there is a degree of similarity with some portion of the bottom image.
A scanner might be forgiven for the misread of this unprotected Code 39 except that it has following against it:
It should be expecting a quite zone (whitespace) before the leading start bars sequence.
It should be expecting a quite zone after the trailing stop bars sequence.
The bar pattern for "U" is not entirely correct.
The assumed stop bar sequence is not entirely correct.
Many barcode scanners read black and white sections on a single line. They have no clue as to whether the line is horizontal, vertical, or diagonal, and have no inherent means of knowing if the line "enters" a barcode on one side and leaves at the other, or if it enters via the top, crosses the barcode diagonally, and exits via the bottom.
Some barcode formats like Interleaved 2 of 5 start and end with patterns which can commonly occur within a barcode [I2of5 starts with BwBw and ends with BBwB], and it is possible for a partial scan which slips off the top or bottom to be misread as though it were a valid scan of a shorter code. Some other barcode formats start and end with patterns that are chosen so that there is no way a partial scan can read as valid data. Code 39 is somewhere between.
Every valid code 39 barcode starts with BwBBwBBwwBw and ends with wBwBBwBBwwB. It is possible to have the sequence wBwBB to appear at the end of one character and BBwwBw to appear at the start of the next, with a single "w" between them. If two such pairs of characters appear within a barcode, a limited variety of characters appear between them, and the scan exits the first pair at just the right place and likewise exits the second pair at just the right place, it is possible that the scanner would see a legitimately-formed barcode whose content bore no apparent resemblance to the original. Someone who deliberately chose barcode data that met the necessary criteria and tried to scan it at an angle to generate a false read would have little trouble getting false reads from many scanners, but both the data and scanning angle would have to be "just right" in order to cause problems.
If one is concerned about the possibility of such misreads, it is possible to print barcodes in such a way as to guarantee that a scan which leaves the code will not be seen as valid. A simple way of doing this is to print black above and below the barcode, so that any scan which enters and/or exits via the top or bottom will perceive the code as starting and/or ending with an exceptionally thick black bar. In many places where one sees "stacked" barcodes, they will be separated by a pattern of dots which do not hold information, but are instead designed to ensure that a scan which crosses from one row to another cannot be perceived as valid.