JJ Jones wrote:

> Actually, ESC/P has been pretty reliable for simple things like
> changing font sizes, etc. But I haven't gotten to first base on
> barcodes or even graphics code. I would also like to use some simple
> graphics, like blacking-out something with a solid black square.

Thing with graphics is there are various "modes" which the printer may, or
may not, understand, in particular 8 & 24 bit graphics (for 9 & 24 pin
printers). The difference being that more bits are stacked vertically for
the latter - 3 bytes are used to define the stack of bits to printer as
opposed to just 8.

When printing graphics, a stack of bits is scanned across each line - you
need to specify /exactly/ how many stacks of bytes are being sent so that
the printer with accept the full 8 bits for the next n bytes before resuming
normal character/control interpretation.

Similarly when doing bar codes: you will need to specify exactly how many
data bytes are being sent to the command (the data for the bar code, plus
the preamble which specifies the bar code type and size, etc).

> One thing I found out is that there is a 1998 ESC/P manual which has a
> somewhat different escape sequence for barcodes than the 1997 manual
> that I have. For example, the 1997 manual shows the length as 2 bytes
> - an int and a mod. While the 1998 manual shows it as a "word". I
> assume a "word" is 4 bytes in this case.

I would presume the word to be 16 bit, or 2 words, and giving the same result.
....

>>I wish you well with this. We've an Epson thermal label/barcode printer
>>which also uses ESC/P. I've never got further than having MS Word print
>>to it from Win98. I'd like to get it printing barcodes though - I found
>>the ESC/P manuals too baffling for my small brain.

Examining the original example:

1B,28,42,0D,00,04,02,00,7D,00,03,30,31,32,33,34,35 ,30

or as characters:

<ESC> ( B [13] [0] [4] [2] [0] [125] [0] [3] 0 1 2 3 4 5 0

We have (presuming data correct):

<ESC> - command prefix
( - Command: an extended one, next char gives actual command
B - Command: print a bar code
[13][0] - A lo-hi (little-endian 16 bit word) length of data to follow
(13 bytes)
[4] - Bar code type: 4 = UPC-E
[2] - Module Width: 2 dots
[0] - Space adjustment (none)
[125][0] - A lo-hi Bar length = 125 units
[3] - Control flag: 0000 0011 = No human readable chars
Printer adds check digit
0..0 - Bar code data (7 as printer adds 8th check digit) - 0123450

The size of the unit depends upon the printer and the parameter. 24 pin
printers using a smaller unit than 9 pin printers.

I vaguely remember when testing bar codes (when working in mail order retail
years ago) that they don't print until the paper is advanced. Try adding a
few Carriage Return line feeds (CRLF - 0x0D 0x0A) to the end of the test
print, ie send:

0D 1B 42 0D 00 04 02 00 7D 00 03 30 31 32 33 34 35 30 0D 0A 0D 0A 0D 0A

>>What I have seen suggested here in the past is kbarcode. I don't know
>>how well it's maturing but it's probably worth a look. If you are able
>>to produce *any* code that produces reliable output from an ESC/P
>>printer I'd very much like to see it - as a starting point for my own
>>endeavours, especially seeing as I don't even know where to start with
>>this!

It is possible to print bar codes using the graphics mode (I used that
before we got a printer that could do bar codes, but I only had the
definitions for 2 of the possible bar codes).