A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Is anybody generating barcodes in Java ?
I'd like to find a good library for that, but I'm not really thrilled by what I found right now.
I'd need those barcodes: Code39, Code93 (this one is especially hard to find), Code128 (Type: A, B, C), EAN-13,
Anybody any experiences with a library ?
OSS: Jasper Reports, JBarcode, JBarcode Bean, Barbecue. Third party wrappers: idautomation, SeagullScientific BarTender (v good).
I found that the best way to generate the barcode (but the least reusable way) was to talk directly to a thermal printer in its own language (e.g. ZPL II for Zebra). It does not matter then what driver is installed just talk directly to the printer spooler. Over time you end up with a printer class to plug in for the printer manufacturer you are working with.
The problem with generating and sending graphics is that a thermal printer will print that barcode not as well or as clearly as when the printer generates the barcode itself from a command string. This can cause problems when the barcodes need verification/certification from a standards body, which you often will need if your barcode is to be accepted in a supply chain.
As an aside the SeagullScientific drivers for thermal printers provide better performance than most manufacturer provided drivers and are more programmable. They are free and are the best way to go if printing graphical barcodes. Using these drivers with SeagullScientific libraries will actually often result in printing via printer language (avoiding graphics and bitmaps) but not always.
>> "The problem with generating and sending graphics is that a thermal printer will print that barcode not as well or as clearly as when the printer generates the barcode itself from a command string."
In my experience, that's not entirely true. If you are programming under Windows then the device context has a resolution equivalent to that of the printer and printing custom generated barcodes and graphics presents no quality problems. When sending the job to the Label printer you need to ensure that the printer is calibrated for the label you are using and that the correct darkness setting is being used.
Wednesday, July 04, 2007
>>"If you are programming under Windows then the device context has a resolution equivalent to that of the printer and printing custom generated barcodes and graphics presents no quality problems"
You are correct. There are many nuances/variables here. This is an advantage of writing with libraries dedicated to the one operating system. Although, the original poster was using Java.
You are also correct to say that printer settings are an integral part of quality and readable prints (esp. darkness). This can be an advantage of talking directly to the printer in its own language because often it is simple to include calibration information (and templates). Otherwise, good drivers will help with this as well. Bad drivers can really muck things up.
It can be helpful not to worry about barcode generation (let the printer do it) and just concern yourself with valid barcode information. Some codes are very particular about bar width ratios etc and it would be a bad idea to manipulate an image's dimensions. Some image generators are very poor at dealing with issues like where you may wish to stick to code C for the whole code (label width issue) but need to switch to B for one odd character.
The original poster might however be looking for something very simple but did not specify.
Well, we are making the transition from c++ to java.
In C++ we've been using "directly" the printer language in the past (sending the data directly over the serial port), but this had some shortcomings:
* problem with usb printers (although one of the poster said that the seagull drivers can do this with the bartender api), because you can't directly send something through usb port
* it was an advantage to test the label on normal printers / pdf printers so we had an easier way to test it somehow (100% just with a label printer, that's clear)
Then we used a bar code font, but this was pretty inconvenient (well, we would've made a library with all the start / end signs and check digits) for all the bar codes we are using. Additional the output was ok, but considerable worse than with the printer language
Afterwards we used a barcode library ( http://www.codeproject.com/bitmap/barcode5.asp and the others for the rest of the codes) but there were some barcodes missing, so we used a commercial library ( http://www.tec-it.com/asp/main/startfr.asp?LN=2 ) and both worked exceptionally well.
Well and now I wanted to ask you guys for some opinions in java.
Biggest problem with attempting to allow the printer to create the barcode manually is that you have to create code for each barcode printer yourself. I have previously worked in a company that distributes and uses internally a wide range of barcode printers, and it is far easier to use GDI+ or the Java equiv in this case, for drawing out to the printer. As such, you can easily scale your graphics according to the printer resolution available.
And most printers (thermal transfer or direct thermal included) all have rather good resolutions that are easily set by default on any OS to give you the best output. And of course, anyone can get the right drivers for their printer, so there's no reason you should be using the 'Generic Text Printer' driver.
A lot of the barcodes you ask for are quite easy to create yourself, some have some minor algorithms to them (such as Code 39, EAN/UPC, etc use parity and bit fields) that require a little pre-planning first, but can be done in less than a day. And they definately can be done in Java no problem. You just need to do some careful searching on Google and you can find all the specs for most major open-standard barcodes. (Just remember, a fair number of more complex ones are proprietary, and require either licensing or purchase of specifications)
Monday, July 09, 2007
It is as always dependent on requirements. Using The printer language is very useful for speed - if you have hundreds of labels with incremental numbering destined for different packing and weighing stations you may like to use templates on the printer and not have to be sending images across the network.
Another good approach is of course to use the printer commands with internet printing and forget the driver - bypassing the Operating System specifics can be useful for Java. In manufacturing it is often good to have very tight control of the printer because minimizing external variables helps, especially when people are going to call someone in your company at 4 in the morning and there is a whole shift of workers in another state staring at a printer - why would support need the driver as an extra thing to debug.
For a more generic application where there is little input to, or control of, or interaction with, the potential setup - then generate images or use a third party library.
If speed of design is most important use images or third parties.
If reusability is key then create images or follow google to third parties. It is cost effective too. $500 for a development license is clearly cheaper than spending the time to design, build, test, remain responsible for...
Or design your application/library so that these decisions can be made at run time depending on whether you have the library prepared to the currently selected printer or not. Your requirements will reflect all these decisions. There is no one right way. Is printers/environment something that is changeable? How closely will you support the application? Will your company have input into the roll outs?
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz