What is the smallest 1D barcode size I can print that will be readable by a scanner? Is 6mm x 6mm even possible?
I am planning to encode 21 characters. Will this fit into the barcode? If not will 2D do?
Unfortunately, this depends on the printer and the scanner. The printer's resolution determines how legible the symbols are, so theoretically a 1200 dpi printer is going to print a more readable code than a 600 dpi. Of course that depends on software.
The scanner is limited by its field of "vision", so the closer the scanner can get to the substrate, the smaller your barcode can be. While a 6mm x 6mm target area is possible, you aren't going to get there with off-the-shelf products. Maybe using lenses (like a microscope) and a high fidelity printer (like a typesetter) you could get to 6mmx6mm, but it's going to be expensive.
The smallest I could get my software to do 21 characters is about 45mm using a HP Inkjet and Symbol handheld. However I was using Code128B. If you are using only numbers, Code128C would cut about 30% off the width.
http://brian-p-anderson.github.io/JS-Barcodes/
Related
I have to display barcodes on a mobile screen which can only be within 72x28 pixels (in an area of around 1.5cmx0.5cm). I then have to scan those barcodes using a smartphone. I don't have to encode a lot of information - only enough that can be efficiently decoded in this scenario. What is the best poosible barcode encoding to use? I think given that the vertical is very small, 1D barcodes would be better, but I am not bale to figure out the encoding out of all the available options.
The smallest QR code, Version 1, takes 21x21 pixels. Really, the QR codes are supposed to have a 4-module border on all sides, which would technically make it 29x29 at least. However in practice, leaving one pixel off will probably be just fine, letting you fit into 29x28.
Version 1 can encode up to 41 digits in numeric mode, with the lowest EC level, L.
For 5 digits, a simple Code 128 1D barcode is perhaps an even better choice.
I have a barcode image. I have to make it smaller.
Can that damage the barcode?
Proportional scaling
Not proportional scaling (only height changes)
Barcodes are: Type UPC-A / EAN-13 "vertical lines". Sorry not an expert in barcodes, thought the type of barcode would not be important. Scaling is moderate, the image does not lose relevant data.
Regular barcode (=vertical stripes) is recognized by the relative width of the lines. Thus, the horizontal height only matters for robustness against diagonal scanning. If the codes are scanned with a hand scanner, I'd just scale the height (or crop the image). In any case, the different widths of the lines should still be clearly visible. There may be compliance rules suggesting minimum proportions for a given barcode standard.
For regular linear product barcodes, the simple answer is yes, you can scale it (both case are safe).
However, if you scale too far and the bars end up too close together, you will start to get a high level of read errors.
You'll need to test it with an appropriate barcode reader to make sure you haven't scaled too much.
When scaling a barcode, there are several things you must keep in mind.
1) You get the absolute sharpest edges in a barcode if each module (the narrowest bar) is a whole number of pixels wide.
2) If the module width is not a whole number of pixels, produce a barcode where the width of each module is the truncated whole number and use bilinear interpolation to scale up. This will give you at most one pixel of gradient at the edges.
3) Be careful when buying a barcode library, choose one that includes built-in scaling that preserves the barcode, such as this one or this one. Barcodes have special demands that image processing normally does not have, such as pixel-perfection. Using e.g. Gimp might damage the barcode.
I wanted to implement barcode for one of my mobile project requirements. The amount of data that is to be stored is very little (<25 alpha-numeric). I want to know if its wiser to implement a 1d barcode or a 2d barcode (Qr code particularly) for this project. I would be really glad if someone could educate me on the following aspects from a 1d vs 2d perspective:
scanning speed
size (minimum display size that is needed, for the mobile camera to recognize -- this is more crucual)
accuracy
Considered from a typical processing and SDK perspective (zxing preferably).
I'd go with a qr code, particularly if you're planning on using a phone camera. qr codes have features (finders) that make things like perspective correction easier/more reliable. They also have ECC that enables eliminating false positives and correcting various amounts of bit detection errors. If you look at the zxing test suite, you'll find a number of false positive 1D cases since many 1D codes don't have even a checksum.
Speed's probably not an issue for either case if you know what you're trying to scan. The biggest computational cost in zxing is going through all possible codes when you don't know what you're looking for. If you know the code type, it's not likely to be significantly different.
The only thing about size is the number of pixels that have to be captured. In other words, a small code can be read if you hold the camera close to the code. A large code can be read from further away. All this is subject to light conditions, camera focus (or lack there of), and camera brightness adjustment. I can't see how any of these would impact 1D vs 2D though.
Im creating pdfs server side with lots of graphics so maximizing real estate is a must but at the same time ensuring users printers can handle the tight margins is a must.
Does anyone have an idea what safe values I can use for the margins when authoring the pdfs. In the past Ive used work and home printers with margins of about one cm with no problems but of course I can't take this as the defacto minimum.
Oh and I don't really want to allow the user to specify the margin (50% lazyness 50% will get complicated.)
Ive googled but couldn't find anything concrete. (average minimum margin printing)
Every printer is different but 0.25" (6.35 mm) is a safe bet.
For every PostScript printer, one part of its driver is an ASCII file called PostScript Printer Description (PPD). PPDs are used in the CUPS printing system on Linux and Mac OS X as well even for non-PostScript printers.
Every PPD MUST, according to the PPD specification written by Adobe, contain definitions of a *ImageableArea (that's a PPD keyword) for each and every media sizes it can handle. That value is given for example as *ImageableArea Folio/8,25x13: "12 12 583 923" for one printer in this office here, and *ImageableArea Folio/8,25x13: "0 0 595 935" for the one sitting in the next room.
These figures mean "Lower left corner is at (12|12), upper right corner is at (583|923)" (where these figures are measured in points; 72pt == 1inch). Can you see that the first printer does print with a margin of 1/6 inch? -- Can you also see that the next one can even print borderless?
What you need to know is this: Even if the printer can do very small margins physically, if the PPD *ImageableArea is set to a wider margin, the print data generated by the driver and sent to the printer will be clipped according to the PPD setting -- not by the printer itself.
These days more and more models appear on the market which can indeed print edge-to-edge. This is especially true for office laser printers. (Don't know about devices for the home use market.) Sometimes you have to enable that borderless mode with a separate switch in the driver settings, sometimes also on the device itself (front panel, or web interface).
Older models, for example HP's, define in their PPDs their margines quite generously, just to be on the supposedly "safe side". Very often HP used 1/3, 1/2 inch or more (like "24 24 588 768" for Letter format). I remember having hacked HP PPDs and tuned them down to "6 6 606 786" (1/12 inch) before the physical boundaries of the device kicked in and enforced a real clipping of the page image.
Now, PCL and other language printers are not that much different in their margin capabilities from PostScript models.
But of course, when it comes to printing of PDF docs, here you can nearly always choose "print to fit" or similarly named options. Even for a file that itself does not use any margins. That "fit" is what the PDF viewer reads from the driver, and the viewer then scales down the page to the *ImageableArea.
As a general rule of thumb, I use 1 cm margins when producing pdfs. I work in the geospatial industry and produce pdf maps that reference a specific geographic scale. Therefore, I do not have the option to 'fit document to printable area,' because this would make the reference scale inaccurate. You must also realize that when you fit to printable area, you are fitting your already existing margins inside the printer margins, so you end up with double margins. Make your margins the right size and your documents will print perfectly. Many modern printers can print with margins less than 3 mm, so 1 cm as a general rule should be sufficient. However, if it is a high profile job, get the specs of the printer you will be printing with and ensure that your margins are adequate. All you need is the brand and model number and you can find spec sheets through a google search.
The margins vary depending on the printer. In Windows GDI, you call the following functions to get the built-in margins, the "no-print zone":
GetDeviceCaps(hdc, PHYSICALWIDTH);
GetDeviceCaps(hdc, PHYSICALHEIGHT);
GetDeviceCaps(hdc, PHYSICALOFFSETX);
GetDeviceCaps(hdc, PHYSICALOFFSETY);
Printing right to the edge is called a "bleed" in the printing industry. The only laser printer I ever knew to print right to the edge was the Xerox 9700: 120 ppm, $500K in 1980.
You shouldn't need to let the users specify the margin on your website - Let them do it on their computer. Print dialogs usually (Adobe and Preview, at least) give you an option to scale and center the output on the printable area of the page:
Adobe
Preview
Of course, this assumes that you have computer literate users, which may or may not be the case.
Given words and their frequencies and an area of screen real estate, what are good approaches to fitting a tag cloud to the space? The two variables I can think of to manipulate are:
Font sizes (both absolute and the gradient)
Number of words
Everything approach I can think of requires iteration, like setting an upper bound on the number of words then using binary search on font sizes until the words just fit the area. I'd rather have an analytical solution.
One complication of my situation is that the clouds are resizable, so the algorithm needs to be able to handle 100x100 pixels or 1000x1000 pixels reasonably well.
Edit: I should have said this is for a rich client application, not the web (hence the possibility of resizing). Also, I was hoping to hear some experience like "nobody ever looks at more than 100 words in tag cloud so don't bother displaying them".
What we do in Software Cartographer is
have a maximum font size,
map Math.sqrt(term.frequency) to this range (since words are 2D areas),
only show the top 30 (or so) terms,
exclude any fine print, ie font size smaller than 6 pt,
sort the terms in the cloud alphabetically.
Alternatives
Instead of showing the top 30, choose the top k such that there are no scroll bars.
Instead of mapping the most frequent word to the max font size, use a global mapping such that word size are comparable between clouds (this depends on your use case).
To my best knowledge, no empirical studies on term clouds are available (maybe Jonathan Feinberg, of Worlde fame, knows more in that regard).
This sounds like the knapsack problem, but inverted and with more variables. There is no trivial complete solution, but it is likely you will be able to find a heuristic algorithm that comes close to the optimal solution in most cases.
PS: You can only make this work reliably with font sizes measured in pixels. Font sizes measured in pixels are a Bad Thing (TM) in good web design.
You could create a predetermined set of incidence ranges, which could then relate to a font size in your cloud. For example:
0 - 100: 1 em
101 - 500: 1.2 em
501 - 1000: 1.4 em bold
1001 - 1500: 1.8 em bold
1501 - 2000: 2.0 em bold italic/underlined/flashing/whatever etc...
You could scale the cloud by adding a fixed offset to all the ranges based on the size of the container.