print on dot matrix printer in .net

Question

anyone can please tell me the code how to print documents on dot matrix printer in C# windows application.

Answer 1

How is this different from printing on inkjet or laser printer?

MSDN: Printing Overview

Preview and Print from Your Windows Forms App with the .NET Printing Namespace

Answer 2

You can print to dot matrix "graphically", which is built-in in Windows, albeit slower.

But if you only want to print pure text with simple formattings, you need to send escape commands to your dot matrix printer, which is faster than graphical printing. Different printers has different escape commands.

Here are typical escape commands(for epson): http://www.printfil.com/manualen/c5.htm

This might help: http://www.sacpcug.org/archives/0306/prc0603.html

What I do in VB6 then was to print to Generic / Text Only printer, you open the PRN or LPT1 as a file handle, then print escape commands on the file handle, all escape commands will be redirected to whatever printer is attached to LPT1 or PRN. You can do the same thing with C#, just open the PRN or LPT1 as a file, then print to it.

To add Generic / Text Only printer, Control Panel > Printers > Add Printer. On manufacturer, select Generic, then on printers, select Generic / Text only.

You can do the same (printing on Generic / Text Only) for Zebra printers which have their own escape commands for printing bar codes, which is faster than letting Windows print to it graphically.

Answer 3

When you print to an inkjet or laser printer, you generally do not use built-in fonts of the printer. You use Windows fonts. What happens is that the printer driver either builds an image of pixels (including the text) and sends it to the printer, or sends commands designed to draw lines, spline curves, and other shapes to the printer, with fonts expressed as lines and splines (outlines).

When you print to an older dot matrix printer, you can do it that way, but it’s slow. Each line of text has to be “built” from pixels, and often the lines of text do not match up with the passes of the print head (especially for fonts much larger or smaller than 12-point).

The old way of using these printers, the way they were intended, was to send the actual ASCII codes of the text to the printer. Send the number 65 (decimal), and you get a capital (upper-case) “A” for instance. The number 49 (decimal) would print the digit “1” while the number 32 would be a blank space, 33 an exclamation point (“!”), and so on. One byte = one character. The dot-matrix printer had its own built-in font, and would look the ASCII code up in its font ROM, and from there determine the exact timings of which print wires would have to strike the page exactly when to produce those letters.

By using ESCape codes, you could specify such effects as pseudo-boldfaced (basically striking the letter twice, with the second copy shifted to the right by only one dot width), double-wide (striking each column of wires twice in a row for each one time that it would normally be struck, thus doubling the width of the letter), underline (striking the bottom print wire throughout regardless of whether the letter shape calls for it at that point or not), and so on.

The printer’s own ROM handled all of these mechanical details about print wires and such. All your program had to supply is the actual ASCII codes of the text (including control codes such as the number 13 [Carriage Return aka CR] to return the print head to the left margin [or, for a bidirectional printer, prepare to print the next line in the reverse order of the previous line], usually followed by the number 10 [Line Feed aka LF] to roll the paper up one line to prepare for printing the next line).

If you wanted to print in fancy fonts that the printer didn’t have, or print graphics, you had to use an ESCape code to set the printer into “graphics mode” in which you basically sent bytes whose bits would specify to fire the individual wires of the printhead under direct program control, rather than looking up character shapes in the printer’s Font ROM. When you print normally from Windows using a printer-specific driver, this is usually what happens.

For daisy-wheel or other fixed-character printers (e.g. IBM Selectric type-ball mechanisms), the ASCII code would spin the wheel or ball to the proper position and then strike the ribbon and thus print the letter on the page, or send the right hammer up to hit the ribbon and thus the page (TeleType or old typewriter mechanism). It was not possible to do pixel graphics with these except by printing repeated periods and micro-advancing the print head and paper the width/height of a period instead of a character / row of text, respectively (which would generally wear out the period character of the daisy-wheel or ball really quickly, so many of them had metal-reinforced periods for that very reason).

Answer 4

Whilst it wasn't in C#, I have written Access reports that used the native fonts of an Epson printer. It was a few year ago - using Windows XP - but when the printer was selected as the default it was possible to choose the "native" fonts of the printer via the font chooser.

It was pretty neat - I could use any font I liked for the headings, which were slow to print. Then I could select the native printer font for the detail rows, which were fast. Doing it that way I had to be careful that all the "native" font detail stauff had exactly the same vertical alignment, otherwise it became slow again.