Thursday, 26 September 2013

Zebra ZXP 8 Card Printer

We just got a new card printer for the office - prints on credit card size plastic cards. We have had one for a long time (Evolis Pebble). Unfortunately the SIM cards we do now have a different type of plastic or surface texture or something and they would not print. In the past it only managed black on a SIM card anyway. So time to get a new one, the Zebra ZXP8, for around £2k. The guys at were great.

I have to say that this is a serious card printer. It is over twice the price of the Evolis, and a bit faster. It is about the same running costs, maybe slightly less. It is way better!

What makes the ZXP8 model special is that it is a re-transfer printer. It prints the images on to a transfer film, and then separately heat transfers that on to the card. This is important as the heat for printing is very different to the heat needed to transfer on to some types of card. Direct printers are fine on perfectly smooth PVC blank white plastic cards. They do not work well at all on a SIM card, often not a smooth surface and with gaps and contacts and a dent for the chip on the back and so on.

I have to say it is impressive. It can do full colour, edge-to-edge, double-sided, and can print on SIM cards perfectly.

There are some points worth noting. The ribbons come in various sorts:-
  • YMCK, allows full colour (YMC) and a solid black (K) layer as well.
  • YMCKK, designed for double sided, YMCK one side, just K the other
  • YMCUvK, does full colour, black, and Ultra Violet!
  • YMCKI, does full colour, black, and Inhibit.
You can also get single colour (e.g. black). The YMC being Yellow, Magenta, Cyan (more commonly stated as CMY) are the three secondary colours used for printing, and K is black. This is normal print process stuff, but the last two ribbons deserve some explanation.

The Uv is quite cool. It is a separate print layer that is invisible. To work properly it needs a second transfer ribbon process of just Uv (all done seamlessly), but the end effect is something you can't see, so what's the point? Well, shine a UV light at your driving licence or some money or bank cards, they all use UV for security. The result is pretty cool. We did this at the LONAP/ISPA event this week for fun and found a fake tenner in someone's wallet, ooops.

The Inhibit is also rather fun, and for the SIM cards. It stops the re-transfer for an area of the card. This allows me to avoid printing on the SIM contacts, and for a mag card would avoid the mag stripe too. In practice, the SIM contacts do not stick, so no need, but would be needed for mag stripe I expect.

Also, it is able to cope with CMY on one side and K on the other, which is not an uncommon arrangement, and allows double sided for the same price as single sided in such cases. The transfer ribbon always uses two panels on this model (shame). But this is a nice feature to save on colour panels on some card designs.

There are several options, and I have gone for the SIM contact reader and the Mag stripe encoder/reader, just for fun. Not using either just yet. You can even get a separate laminater for added protection of the surface or using custom laminates with holograms and the like.

For the technically minded, the colour layer is 8 bits per colour and usually sent as RGB and converted to YMC by the printer. The Uv is 8 bits per pixel. The black and inhibit are 1 bit per pixel. It is 300dpi. Print area is 1024x648 which overlaps the edges of a normal card (1012x637 ish) so proper edge-to-edge even with minor feed/alignment variation.

Of course, having got this Monday morning, I had some work to do - it comes with Windows drivers. I had to find a Windows laptop (sales had one in a corner for use with BT eCo on IE). I spent the morning packet dumping (it is a network connected printer). I spent the afternoon coding linux drivers for it, and was surprised it took me until 6pm to print a card (my excuse is lack of blood sugar, too engrossed to eat).

Packet dumping was done using FireBrick pcap dump and tcpdump to decode, though mostly that meant reading hex.

So I have published the drivers now:

Basically it talks on TCP 9100, has a 16 byte command and 32 byte reply system with optional data payload. Several commands worked out (see comments in the driver code). The application I wrote takes separate postscript or BMP files for each layer, being colour, black, inhibit or Uv for each side, and sends to print. It can also make a preview BMP to see what would print.

I have yet to try and decode talking to the SIM card contacts (useful for smart card coding too) or the Mag stripe encoder, but that should be simple and will be added to the driver code as I need.

Why don't people either produce linux drivers or at least publish the interface specs? How hard can it be?

Update: Mag card read and encode was a doddle, but cannot get it to talk to the SIM cards yet!

It is quite neat that I can tell it to take a card from the hopper, manual feed, or left in printer, and tell it to send a card to the output, a reject tray, or left in printer. This means I can suck in a card, read it, print, mag encode, etc, all as separate jobs. When I get the SIM reader working I can get the SIM ID and then make a print job to print the details on the card. It is pretty slick.

P.S. It talks IPv6


  1. We have the Zebra ZXP 3 Card Printer.

    We have had no end of problems with their 64bit windows driver, it prints the first card fine, however it refuses to print anymore!
    So we have one 32bit windows machine left in the office, they get to do ALL the card printing!

    Their support is terrible too! We've tried working with them to resolve it, ended up giving up!

    1. I expect the drivers will work just the same on the ZXP3 to be honest.

  2. The card has a barcode on it which decodes to a URL ( which downloads a .vcf file which contains a JPG of the image displayed on the card.

    From a security point of view, is this wise? OK, I don't know what's on the back of the card, but given your picture of the card under UV light and the .vcf file, assuming I had a card printer, I could make a pretty good stab at a copy...

    1. Yes, you could copy it - but making your face match the card may be harder.

    2. Indeed, but having a better quality image would make the plastic surgery easier ;-)

  3. Errrm Rev! I am looking for a simple card printer, for ABS cards and the Yale Superior cards - Credit card size and Tesco club card keyfob size. So many customers lose their key cards - would be nice to offer a slick replacement card. Something affordable without a large footprint? (Just bought another Silca Triax Quattro so I can't go bonkers!)

  4. You might find that the SIM reader does not work over the network port. We use card printers with Mifare encoders, and only the printing can be done via network - encoding has to be done via the USB port.

    1. That means there is no point in having the network port on such printers as I would have to have a network / USB device like a Pi attached to it, and could print via USB in the first place. What the hell?!?!?!?

    2. I know - annoying isn't it? We have this with Evolis and Zebra printers. We hoped when they moved away from serial card encoders that they would enable them for network use.

  5. Nice Job getting the ZXP printer to work. I am (just) a Java programmer, and need to integrate a ZXP3 printer in some member-administration software. AS you mentioned, support of Zebra is almost zero.... and they only support Windows (license cost), and their own software (again license...) and refuse to open up the API...
    If they only had some little support of ZPL on that type of printer, it would be solvable... but sadly, ZXP does not support ZPL...

    Your experiences are an inspiration that it might be able to call your driver via JNI ? or just re-write it in Java *sigh* ?
    Anyway, any help, hints, etc... would be appriciated. (as in ... i do not fluently read c-code .... sorry)

    1. Have a look at what I released as I expect it would work on a ZXP3 as well. It looks pretty generic stuff. I wrote it as a stand alone command rather than a CUPS driver on this occasions as the print needs multiple layers. This makes it very easy to use with any linux based applications and call as a command from anything you are using.

  6. Hello RevK. Nice job writing your own driver for the ZXP series... Respect !
    I am (just) a Java developer, bought me a ZXP3 with ethernet - in the wrong assumption that it understands ZPL ... but it doesn't. As you mention, support for non-windows, or even Java - is ZERO. They just want you to run on Windows, and buy their software, integration of their products (e.g. automation) is not their concern ... They expect you to print each card (e.g. in my case an automated membership program) by hand ... on windows, with their software (license license licenses...)

    So, I hope you can help me out. E.g. can I call your driver in Java (e.g. JNI) ? Or do I have to re-write it in Java (as support to community) ... but with a little help... because I do not read C-code that well...

    Hope someone out there can help me get started...