WinXp and Okidata dot-matrix printer

[Guest]

We have several Okidata Microline 590 dot matrix printers with which we print
shipping labels and 4 part invoices. We are able to print perfectly to these
printers from Windows 98SE, however, under Windows XP Pro the lines are
creepy up the papge until the invoice data begins printing in the middle of
the invoice and the same happens with the shipping labels...but this only
happens under Windows XP Pro.

Microsoft Tech Support says that this is a driver issue while Okidata has
not responded to request for assistance. Has anyone out there experienced a
similar issue, and if so, what did you do to resolve it?

Thanks!
Joseph

 

[Chuck]

This issue is back to haunt us again! The same problem occurred between win
3.1(1) and win 95 on more than one make and model of dot matrix printer. It
usually happened when older drivers were (partially) converted to be
compatable with a new windows version, or an older driver version was used
without conversion. The older drivers usually used "legacy" calls to
communicate with windows. The default behavior of some of these calls was
known to change very slightly from windows version to version.

If you have a system still running win 98 and that works correctly--and are
trying to figure out what is going on--
The brute force method is to save to a printer ready file instead of sending
to the Oky printer.
You do the same thing with a Win XP system.
Next, the two files are compared using a hex editor. The differences will
most likely be related to the problem.

How to get out of the problem (Maybe)
Is the printer driver set to use the "RAW" or image mode instead of
something else? If not, try changing it.
(Unfortunately, the change to "RAW" mode may slow things down a bit.)

Your printer may "Emulate" other printers, such as an Epson. You might try
using the Emulated printer driver and emulation mode.

Changing the printer default from/to normal, compressed, or expanded may
help or make things worse.

A last resort, because of poor documentation and fiddling around to get
things to work might be to use the Microsoft windows "Generic" ASCII printer
driver.

It may be possible to Skip a portion of the form, and prevent the extra
spacing.

One thing to try/check has to do with what the printer does with FF, CR/LF
and LF. Dot matrix printers traditionally have settable options as to how to
advance when getting these codes. It is possible to setup a file with the
codes and send it via a copy (binary option) command to the printer. Text
files with the number of lines in the file equal to less than one page, more
than one page, and multiple pages can also be generated and sent to the
printer. These tend to illustrate printer behavior when jobs span or don't
span several pages.

Remember that there is a difference between most dot matrix printers and
most ink jet printers. The ink jet and laser printers by behavior are "page
printers", and the dot matrix printers are "line" or character printers. The
default behavior between one page and the next can be quite different when
the same codes are sent to the printer.
There may be some undocumented settings in the registry that will help. Only
the printer Mfr or possibly Microsoft is likely to know them.

Changing fonts/styles/size in the printing application may make a
difference.

Changing to a custom form size (If possible) in the driver or application
may help.


Why does this sort of thing occur?

1. Extra CR/LF or LF from driver or windows system or application.
2. Small error in page length calculations (driver) or in printer hardware.
Error in page position sense (printer). Cumulative error in paper advance
(Printer or driver)
3. Conflict between continuous form settings/size and usual page size, such
as 8-1/2x11. This can be a printer control panel, dip switch, or other
option in the driver, or even the printer not detecting the presence of a
continuous feed adapter.
4. A nasty one is a mathematical error due to calculation rounding &
truncation in the driver or internal printer processing.
5. Printers with built-in fonts of various types and sizes seemed to have
the most problems when other than very common fonts, spacing, and size are
used. Mixed sizes and fonts in the same document can get the vertical
position counters to go nuts (driver or printer internal processor).

 

[mike]

What size is the form? Is it a supported size on XP. If it is, it should
show up in your application. If it's a custom size you will have to define
it in Printers and Faxes->File->ServerProperties

 

[Chuck]

Server Properties? How about in the printer driver?

 

[Guest]

try to use oki's driver not okidata's driver

 

[Guest]

Hello Mike, Chuck,Newbie,

The issue might be linked to Control Characters (STX).
I am facing similar issue trying to print to a barcode label printer (on
COM or LPT port) while it was working fine with WIN 98.

=> From what i know, one option could be to print to a "generic" printer
using a "passthru" driver that just pass the file to printer without any
alteration.

Can someone confirm this ? Where can we find such driver ?

 

[Chuck]

Not Again!

This problem has returned from the dark ages!
I guess Oki et al never did get things quite right.
I'm sure that the changes to the parts of windows that are involved have
introduced a different software environment than the one existing when the
Oki's drivers were developed. (GUI, various DLL's, registry info. etc.)
Microsoft supplies a generic text printer driver with windows. (Which has
it's own set of quirks.)
Other options might be to see what printers the Oki will emulate, and try
one of those drivers.

There are some tricks to help determine what is going on.
The brute force method involves sending the data to a file instead of the
printer. This is usually an option in the printer driver.
A Hex editor is used to display the file contents, and determine what codes
are causing the extra line feed. You may find that it occurs because of a
settable printer option (printer control panel, dip switch, etc. and not
directly from the data sent to the printer.) Or, an extra line feed is being
sent to the printer, or the printer is adding one at the end of the page due
to printer firmware settings.
We would also generate a file that had numbers in each line, such that the
first line had 1, and the highest number representing the last number at the
end of several pages, assuming the number of lines per page as listed in the
printer specs.
This gives you a controlled data file that can be saved and sent to the
printer via a command line copy with the binary option.
You can then print the file via the printer drive as well as the
aforementiond copy command, thus giving you a comparison.

Some of the dot matrix printers have a control panel or dip switch option to
print the hex codes sent as hex codes instead of text and formatting/command
codes.

Some dot matrix printers automatically add a line feed/carriage return or
form feed at the end of around 66 line of ASCII text. (Firmware settings,
dip switch or control panel. ) This may vary with the printers settings for
the default ascii printer font.

Some dot matrix printers & driver had to be set to treat everything as
graphics formatted data instead of mixing text and graphics, or text as
text.

There are all kinds of other things to try, such as fudging the top and
bottom margin settings and non printable areas. (when you can set such
things.) Turn skip over perf off at the printer control panel or dip switch.
Lie to the driver by telling it that the form is longer or shorter than it
actually is.



Why does this problem occur?
Non printable area not exactly the same as windows and the driver will/do
accept. Some applications can also be involved, depending on how they pass
data to the printer driver thru windows.
Math rounding error in printer driver or printer firmware
Advance (line feed) distance different than the printer firmware or driver
is set for. (errors accumulate)
A scaling problem between the screen font and the printed font. (This was
not uncommon in the win 3.1 and 95 days)
Occasionally, the cure is to flip all of one bit in a registry entry.
Unfortunately, knowing what bit to diddle involves having access to tech
data for the printer driver as well as the windows internals.
A printer hardware buffer size, if too small, or a minor handshaking problem
can also produce a similar symptom, although it may or may not occuring a
completely repeatable manner.