When you set up a receipt printer in AX for Retail you have the choice to use either OPOS or Windows drivers. With very few exceptions, you should always use OPOS drivers for standard receipt printers.
Edit 2015-03-24: This article was written for AX for Retail 2009. Since this time the product team has added official support for printing with Windows drivers in AX for Retail 2012, 2012 R2 and 2012 R3, primarily to add additional options for other regions and languages. The page break fix noted in code should no longer be necessary. However, much of the article is still relevant as it will generally take some programming to get the layout of receipts to work properly as it is not as standardized as OPOS printing.
As noted in the Retail Headquarters User’s Guide, using the Windows driver for printing receipts is a deprecated feature and may be removed altogether in future releases. Unfortunately, this also means that requests for bug fixes in this area will generally be denied.
The good news is that the code for to Windows printers is in a plug-in that you can customize. This article will give you some tips on this code, as well as provide you with a bug fix that you can implement. There are three main things that I will discuss with respect to printing with the Windows driver: lack of barcode and image support, a bug with page break functionality, and some thoughts about paper size.
First a little background on how the Windows printing works.
There are two plug-ins that important with respect to the printing process: the Printing service and the Peripherals service. The Printing service handles all of the layout of what is being printed; it reads from the Form Layout table and replaces data fields with information from the transaction being printed. The resulting string (and it really is just a simple text string) then gets passed to the Peripherals plug-in which handles the communication with the printer.
The Peripherals plug-in is of most interest for this article, specifically the branch of code that starts with the PrintReceipt() method of the printers.cs file:
When this code gets hit, the receipt has already been created in memory and is ready to send to the printer. The decision to send to an OPOS printer (OPOSPrinting method) or a Windows printer (WindowsPrinting method) fully depends on the setting on the Printer tab of the POS Hardware Profile window:
Images and Barcodes: The WindowsPrinting() method uses an standard method for communicating with the printer: the System.Drawing.Printing class. A very simplistic way of looking at this way of printing is to think of drawing an image of the page in memory and then sending that image to the printer. Printing simple text alone using this method is somewhat difficult; adding complex formatting (images, different fonts, etc.) is something that we have left for Partners and Customers to customize.
When printing to an OPOS device, you can send special OPOS codes to the printer to print either a barcode or an image, both of which are directly managed by the printer. Because System.Drawing.Printing is not specific to any one printer or class of printers, this shortcut is not available for Windows printers. In fact, if you print these fields to a Windows printer, you’ll notice that they show up as placeholders like this: <L> and <B:00001>. If you are looking to add barcode and image functionality, the code in the printDoc_PrintPage() method is where you would start.
Edit 2015-03-24: When official support for Windows drivers was added for AX for Retail 2012 it included automatic barcode printing.
Page Breaking: The printDoc_PrintPage() method is also where there is a bug in page break functionality. OPOS printers have no concept of page breaks – if you add 100 lines to a receipt, it will just keep scrolling the paper and printing. System.Drawing.Printing requires that you calculate the page size and add page breaks manually. The implementation that we ship does not have this code for page breaks. This means if you have a long receipt, even if you are printing to scrolling paper, sooner or later a page break will get hit and the receipt will just quit printing.
Attached below is code that shows one way that you can incorporate page breaking into the code. Since we are printing with a fixed-sized font (7-point Courier New) we can calculate how many lines can be printed on a “page.” The code then writes out each line of the receipt until it hits that number of lines. It then stops writing, flushes to the printer, and sets the PrintPageEventArgs.HasMorePages Property for whether another page should be printed. The PrintDocument.PrintPage Event entry on MSDN includes an excellent example showing how page breaks should be calculated.
I have included both the original version of “Printer.cs” and the version with my changes. Create a new project for the Peripherals plug-in and merge in the code changes. This fix has not gone through formal testing and you may find a better way to keep track of paging, but it works in my limited testing and should be a good starting point.
Edit 2015-03-24: This bug is fixed in AX for Retail 2012.
Page Size: Printing to an OPOS device is very simplistic; a fixed-width font is used and a relatively narrow page size is used. If you need to print to a Windows printer and use different paper sizes, there are limitations but a few things you can try.
First of all, you can try different font styles and sizes. The printDoc_PrintPage() method hard-codes to 7-point Courier New:
Simply changing this font (it’s in five places) will spread your text across the page. Make sure to use a fixed-width font or your receipts won’t line up properly. You will also have to experiment with the values of the offsets for placing the text (coordinate variables x and y).
Also, a not-so-obvious feature of the Form Layout designer is the ability to change the number of columns in any of the three sections. Simply right-click on a blank area and select “Number of columns” from the pop-up menu. Change the value to change the width of your paper. A lot of trial and error will be needed to match up font size and paper width, but it should give you some options.
Hopefully this gives you a place to start if you need to use a Windows driver to print receipts. There are limitations to using System.Drawing.Printing for printing; if you’re looking for more flexibility (pre-printed forms, better use of graphics, headers and footers per page, etc.) you may want to look at other options such as third-party controls or report writers.
As always, feel free to get in touch with our Support team if you need development assistance with printing or other AX for Retail customizations.
I have another problem that is the receipt is always aligned to right after print it .. I use windows driver and the default receipt format
Ahmed - the code that formats the page before sending it to the printer is pretty standard Windows classes (WindowsPrinting() method). Because of this it may have something to do with the regional settings on the computer you're printing from. I would try taking the code from WindowsPrinting and try it in a standalone C# project to help you narrow it down.
I noted from your article that the Windows driver may be deprecated in the future.
What is the alternative for printing off a customer order if this feature was removed?
Hi I want to print Continue in the bottom of the page. If the printer prints more than one page(Windows Printer). Can you please help me out.
Simon: Due to requirements needed in various regions, to the best of my knowledge, removal of Windows driver support is no longer being considered.
Raghunath: You should be able to calculate how many lines are on a page and then incorporate an extra line with "... Continued ..." into the calculation. You can then inject that extra line on those pages. In other words, just manipulate the text string to insert those extra lines before you send the page break command.
Hi Shane - in R3, i can't find WindowsPrinting() method, could you give me a path to see the code? if using windows printer to print the receipt is always aligned to right
Hi Dwi - I just took a spin through the R3 code for this topic and the method is in the same place as previous versions: Services\Peripherals\Printer.cs
Hope that helps get you started...
How can i restrict the page to (8.5 * 11 inches) while printing in a printer
I need to print retail POS receipt on 6*8.25 inches custom paper. In A4 size paper and on XPS, the receipt output is coming correctly but not on 6 * 8.25 inches paper. Some data (say 4 items info) is missing on first page and remaining data is showing on 2nd page.
Is there anyway i need to see all the data on custom size paper. By the way is there a provision to see the report size based on Receipt type?
Thanks in advance!
Is there a provision to specify the width and height of paper size in Retail POS headquarters?
I need to print a receipt on 6 * 8.25 inches paper size. Unfortunately some items are missing on the paper but those items are coming correctly if we feed A4 size paper. Any thoughts?
Nice arcitcle, got lots of information about intalling receipt printers with drivers
We are trying to print a receipt that uses images and bar code in a Windows Printer. You wrote above that we cannot do that, right? My question is, even though we cannot do this functionallity speaking, is it possible to implement this feature via code?
Thank you in advance.
it is possible to add item image to receipt? using windows drivers ?
Thomas and RK:
You would need to experiment with the calculations done in printDoc_PrintPage() to determine where to do page breaks. For page width you can change the number of columns in the form layout designer and possibly change the font name and font size as defined by the defaultFontName and defaultFontSize constants in Printer.cs. It will take some trial and error to get it to work properly. See notes in the Page Size section above.
Gabriel and Ahmad:
You can add images to the receipt but you have to do it programmatically within the printDoc_PrintPage() method. You may need to research usage of the System.Drawing.Printing class to merge images into the text that is printed. Keep in mind that you're essentially building one large bitmap for each page and sending it to the printer.
Good news on barcodes: when official support for Windows drivers was added for 2012, barcode functionality was also included. Barcode fonts are now embedded into the DLL and are printed similar to how OPOS prints them.