MSDN - Printing on thermal printers

Author

Printing on thermal printers

Francisco Duran

2004-03-28, 10:07 pm

I am working in a .NET based Point of Sale solution. As a requirement I
need to print on thermal printers. I am looking for a recommendations or
best practices to achive this as the .NET Framework classes for printing are
not working very well. As a matter of fact, the .NET framework classes
don't work with the thermal printers I have access to, because they only
accept certain characters and they don't work very well with Graphics (true
type fonts?).

I need to know if there's another way to print, even if there are some
primitives to print a single line at a time. I don't need print previews or
printer selection windows as the only thing required is to send receipts to
the printer as soon as the point of sale receives the payment from the
customer.

Any link or code sample would be very appreciated or if you know a
third-party product that achieve the same goal please let me know.

Thanks in advance for your help.

Best Regards,

Francisco Duran

Ronny Ong

2004-03-28, 10:07 pm

The first thing you should do is check with the printer manufacturers to see
if they have a Windows print driver. Even if they didn't have one yesterday,
you might be surprised today.

I worked with some POS type thermal printers from 1993 to 1997 which
required raw character output, and as I migrated my code from DOS to Win16
and later Win32, I never expected to be able to use those printers as true
Windows printers. Then one day in 1998, the printer manufactuer surprised me
by releasing a Windows driver (not just for their current models, but also
for the same model we had been using since 1993).

If you can't get a Windows driver, your next step should be to try
configuring the printer with the "Generic / Text Only" driver. This driver
comes with every version of Windows I can remember. To find it in Windows
XP, go into the Add Printer Wizard, select the connection type (probably
Local) and make sure to uncheck the "Automatically detect" checkbox. Select
your port, then choose "Generic" on the left-hand side, under Manufacturer.
This driver will let you render a page normally in any Windows app
(including .NET apps), but the driver will only send ASCII text to the
printer. You have to be careful about vertical positioning, otherwise it
will get

about where to insert linefeeds. (In other words, Windows
will let you render a line at any position on the page, but an ASCII-only
printer can only move the print carriage down a full line at a time,
typically 1/6th of an inch, and if you force the driver to guess whether
something belongs on the current line or the next line, it may guess wrong.)

The drawback of the Generic / Text Only driver is that you cannot send any
printer-specific control sequences (unless they consist entirely of
displayable characters). If you need to do that, write your output to a
temporary file, then shell out to the OS and run a command to copy the file
directly to the printer port. For example, assuming that your printer port
is lpt1 and your file is named receipt.txt:

copy /b receipt.txt lpt1:

The /b ensures that the full contents of the text file are sent raw. This is
only necessary if your printer control sequences might use hex 1A (decimal
26, commonly seen in old BASIC-oriented documentation as CHR$(26)).

If you are using a newer version of Windows AND you are using an lpt port
for the printer AND it's not a real lpt port (meaning it's mapped to a
non-parallel device via special driver or network redirector) then you may
run into security issues trying to copy directly to the port, even if the
user has full administrative rights to everything. If you find yourself in
that situation, it might be time to invest in some different printers.

"Francisco Duran" <fduranm@hotmail.com> wrote in message
news:%23de5HEFCEHA.2560@TK2MSFTNGP12.phx.gbl...
>I am working in a .NET based Point of Sale solution. As a requirement I
> need to print on thermal printers. I am looking for a recommendations or
> best practices to achive this as the .NET Framework classes for printing
> are
> not working very well. As a matter of fact, the .NET framework classes
> don't work with the thermal printers I have access to, because they only
> accept certain characters and they don't work very well with Graphics
> (true
> type fonts?).
>
> I need to know if there's another way to print, even if there are some
> primitives to print a single line at a time. I don't need print previews
> or
> printer selection windows as the only thing required is to send receipts
> to
> the printer as soon as the point of sale receives the payment from the
> customer.

Fernando M. I. Carreiro

2004-03-28, 10:07 pm

Hello there,

Why not use the "System.IO.File" or "System.IO.FileStream" classes to write
directly to the PRN, LPT or COM device for the printer.

If you require sending Binary Codes, use the "System.IO.BinaryWriter" class.

If, it is a COM port, you can call the lower level WIN32 API from C# to
first set the correct parameters. There is an excelent article including the
MSDN Library the explains this process and provides sample code. The article
is from the MSDN Magazine, October 2002 and is entitled:
"Use P/Invoke to Develop a .NET Base Class Library for Serial Device
Communications"
MSDN Link:
http://msdn.microsoft.com/msdnmag/i...mm/default.aspx

Best Regards,
Fernando

-------------------------------------------------------------
"Francisco Duran" <fduranm@hotmail.com> wrote in message
news:%23de5HEFCEHA.2560@TK2MSFTNGP12.phx.gbl...
> I am working in a .NET based Point of Sale solution. As a requirement I
> need to print on thermal printers. I am looking for a recommendations or
> best practices to achive this as the .NET Framework classes for printing
are
> not working very well. As a matter of fact, the .NET framework classes
> don't work with the thermal printers I have access to, because they only
> accept certain characters and they don't work very well with Graphics
(true
> type fonts?).
>
> I need to know if there's another way to print, even if there are some
> primitives to print a single line at a time. I don't need print previews
or
> printer selection windows as the only thing required is to send receipts
to
> the printer as soon as the point of sale receives the payment from the
> customer.
>
> Any link or code sample would be very appreciated or if you know a
> third-party product that achieve the same goal please let me know.
>
> Thanks in advance for your help.
>
> Best Regards,
>
> Francisco Duran
>
>

Ronny Ong

2004-03-28, 10:07 pm

Because the managed classes do not support PRN or LPTx directly. They will
return an error for any device name, or anything which isn't a true file
(such as a pipe). I didn't believe this until I tried it myself. Seems very
illogical, given the way DOS and Windows have historically honored those
device names.

The article about COM ports you referenced is basically applicable to PRN
and LPTx, too. You still have to call the Win32 CreateFile() API through
P/Invoke before passing the handle you receive to one of the FileStream
constructors which accept an IntPtr. The only difference is that you don't
have to set parameters like baud rate, parity, etc. if it's a parallel port
device.

"Fernando M. I. Carreiro" <anonymous@discussions.microsoft.com> wrote in
message news:OpX5RvPCEHA.3976@TK2MSFTNGP10.phx.gbl...
> Why not use the "System.IO.File" or "System.IO.FileStream" classes to
> write
> directly to the PRN, LPT or COM device for the printer.
>
> If you require sending Binary Codes, use the "System.IO.BinaryWriter"
> class.
>
> If, it is a COM port, you can call the lower level WIN32 API from C# to
> first set the correct parameters. There is an excelent article including
> the
> MSDN Library the explains this process and provides sample code. The
> article
> is from the MSDN Magazine, October 2002 and is entitled:
> "Use P/Invoke to Develop a .NET Base Class Library for Serial Device
> Communications"

Fernando M. I. Carreiro

2004-03-28, 10:07 pm

Thanks Ronny,

I didn't know that one. I tried it out and you are right. However, the
version in the Article is still valid and works, but is a little too
complex.

A simpler solution might be to use the "Scripting Engine Class" from C#, as
it does not suffer from the DEVICE problem. The EXAMPLE below, should
resolve Francisco's problem!

Regards,
Fernando

EXAMPLE Code
-------------------------------------
using System;
using Scripting;

namespace LPTT
{
class LPTtest
{
[STAThread]
static void Main(string[] args)
{
Scripting.FileSystemObject fso = new
Scripting.FileSystemObjectClass();
Scripting.ITextStream f =
fso.OpenTextFile("LPT2", Scripting.IOMode.ForWriting, false,
Scripting.Tristate.TristateUseDefault);
f.WriteLine("Hello World");
f.Write("\x0C"); // Page Feed Code at end.
f.Close();
}
}
}
----------------------

"Ronny Ong" <ronnyong@killspam-bigfoot.com> wrote in message
news:uLfcOpXCEHA.464@TK2MSFTNGP11.phx.gbl...
> Because the managed classes do not support PRN or LPTx directly. They will
> return an error for any device name, or anything which isn't a true file
> (such as a pipe). I didn't believe this until I tried it myself. Seems
very
> illogical, given the way DOS and Windows have historically honored those
> device names.
>
> The article about COM ports you referenced is basically applicable to PRN
> and LPTx, too. You still have to call the Win32 CreateFile() API through
> P/Invoke before passing the handle you receive to one of the FileStream
> constructors which accept an IntPtr. The only difference is that you don't
> have to set parameters like baud rate, parity, etc. if it's a parallel
port
> device.
>
>
> "Fernando M. I. Carreiro" <anonymous@discussions.microsoft.com> wrote in
> message news:OpX5RvPCEHA.3976@TK2MSFTNGP10.phx.gbl...
>
>

Sponsored Links