I'm trying to duplicate the printing we did on AREV using OIPI with a dot-matrix printer. We need the dot-matrix for printing multiple part forms.

At the moment, we're having a dicken of a time getting the font to look like what was in AREV (so the type can fit in designated area) and be nice looking. We tried using Arial Narrow and Courier and we get mixed results. We can fit it in the space, but things might look a bit squished (compared to AREV) or the text won't print to the right as we want it to.

Am I expecting too much to expect OI to print exactly like AREV when using dot-matrix. We used the printer driver and the generic/text driver as well.

Any experience, suggestions or comments would be appreciated.

Ray Chan

P.s. Posted on otherside as well. thanks.

Ray ..

I am sympathetic. I have had the same problem using an Epson LQ-1500 and OIPI to print in pre-printed forms. The particular form I had to print was a HCFA 1500 which is very very precise as to where the print has to go. It took over 100 hours of work to get it right and it still isn't perfect. For example, the printer will only print 63 lines per page no matter what. In AREV / DOS, it will print 66 lines perfectly. Also, the font-height spacing is not precisely 6 lines per inch. It's fractionally less than this such that by the print head is at line 51 or so, it's about a half a line off. I resorted to doing micro-spacing to correct it (font change to little tiny font, print a line with a blank char and then change it back). Very ugly indeed. The default Courier driver with OI's standard print routine won't work at all. Neither will Printer.DLL.

Don Miller

C3 Inc.

Don,

Thanks for your response. I'm not working on a HCFA1500, but something simpler but needs multiple copies. For multiple part forms nothing will do except a dot-matrix.

Is this a Windows limitation in using Dot-Matrix or is this something that might be fixable in OI. How have other Windows-base application gotten around this printing problems in using dot-matrix (if at all)? Personally, we would prefer to use laser, but again for multiple part forms you need a dot-matrix. I imagine that for many Pick developers being able to print multiple part forms may be important. Just a thought.

Thanks again for your response here and "over there",

Ray

100 hrs at least!! AND that is only to get to close ..

During the process I mistakenly move to a different printer. Didn't try printing after setting the other printer as a benchmark but after some additionaly coding .. YEOW!!!! all of a sudden things were shifted down lines over etc. Turns out the driver for the second printer has a 'forced' top margin. THis is a windows/printer driver thing. On my HP it worked much much better .. though only close.

I am really not looking forward to micro printing between lines but if necessary I am sure that I will go to that.

We actually created a form to enter the xy coordinates based on a specific font then print using textxy. SO I could add a prompt for fudge xy. Already have a offset for xy for the entire form .. helps with diff printers

I don't think this is an OIPI problem as such although I do think that it should know what the fonts are doing and handle appropriately. But that is the vb control that tony is using.

It is odd that Word can get this almost perfect ..

[email protected] onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

David Tod Sigafoos ~ SigSolutions

Phone: 503-639-4240

DSig & Ray

TMK about the only pieces of software that get printer metrics right across the board are Microsoft stuff. I've seen some 3rd party printer utilities that are pretty good too. Even Adobe Acrobat makes mistakes on dot-matrix printers. I don't think that the problem is easily fixable in OI or OIPI. What's really bizarre is that on OIPI, the display is mostly PERFECT. Just when it goes to the printer. Another bad-news printer driver is the OKI 16-pin Microline series. It's compounded by the problem that it seems to have a HUGE buffer (32 K or more), so there's no chance to fiddle with anything. It won't print until the print job is closed or the buffer fills up. This has caused me fits printing checks. In fact, I can't update the checks file during print time at all. I have to ask Did The Checks Print OK ? If ok then take a pass through the checks file and assign the check numbers to what was printed. Otherwise, re-process the job (from wherever the job messed up). Truly unprofessional, to say the least. AREV / DOS never did this. The problem is again caused by a multi-part carbonless check.

Don

Ray,

We have eliminated all our multipart forms by preprinting the form on paper and then printing the data for the correct number of copies on either a laser or inkjet printer. Once I got the data in place everything goes perfectly.

Might be worth a try. We found it was getting more difficult to find the ribbons for some of the dot matrix printers and we got speed and accuracy and silence in the bargain.

Richard Richter

Richard,

Well if we could we would, but this form, e.g., has two adhesive labels on part 1 of the form that our users remove and applied to folders. The way the form is carbonized the data is printed thru the adhesive label and onto the first and second part of the form which is used for other stuff.

I was just at the auto shop. Now they have a windows based system and I watched them print my multi-part bill/invoice using a dot-matrix printer. Everything looked pretty spiffy to me. They were probably wondering why I was so curious about their printing. Like don't you need a life .

Ray

I have posted this link in the past as an ARev solution, but it probably would help in this scenario as well:

http://hem.passagen.se/ptlerup/

The prfile program you will find at this site is FREEWARE. It was designed to print postscript files but I don't use if for that. It can print text files to Windows printers, and, most important here, it is very happy to send straight ASCII text through any printer driver that will tolerate it. I have not yet tried it using OI, but I don't see why it would matter. What you can do is tell it to print an ASCII text file, and by properly configuring its ini file, tell it to send the text straight through to the printer rather than formatting it using the printer driver. This works with all the Okidata, Epson, and Panasonic dot matrix printers I've tried it with. As far as I can remember, any ARev program originally designed for printing on a pre-printed form works fine with this program, and I can't think of a reason why you couldn't do the exact same thing with OI.

To use this program effectively, what you want to do is configure its ini file for different scenarios, and then call it from the command line passing parameters which control which part of the ini file it uses. Play with it a while and you'll see what I mean. If you use it right its use can be 100% transparent to the end user; it will run from the command line without actually being installed into Windows.

David

Sorry, but I thought I had posted the current link. This one is better:

http://www.lerup.com/printfile

Ray,

I know that these commands are for "backward compatability" only, and they just might be a temp fix to your problems. The CPI (characters per inch) codes are for a PANASONIC dot matrix printer.

10_CPI=CHAR(18):CHAR(27):CHAR(80)

12_CPI=CHAR(18):CHAR(27:CHAR(77)

16_CPI=CHAR(27):CHAR(15)

PRINTER ON

PRINT 10_CPI

PRINT 'LINE NUMBER 1'

PRINT 'LINE NUMBER 2'

PRINT 'LINE NUMBER 3'

PRINT 12_CPI

PRINT 'LINE NUMBER 4'

PRINT 'LINE NUMBER 5'

PRINT 'LINE NUMBER 6'

PRINT 16_CPI

PRINT 'LINE NUMBER 7'

PRINT 'LINE NUMBER 8'

PRINT 'LINE NUMBER 9'

PRINT 10_CPI

PRINTER OFF

David,

Thanks for the link and info regarding the freeware. I download PrtFile.

Do you plan on using it with OI after your conversion?

Ray

]Do you plan on using it with OI after your conversion?

I haven't thought about it yet, but I'm sure I will find some uses for it. I'm leaving printing for the last step of the conversion.

David

Don,

We are also having a similar problem. We have a check printing program that prints just fine in AREV. It keeps track of line counts etc and just print, print, print…

In OI the exact same code (not using OIPI) prints to the same printer and almost works. It appears that the second page (as defined by the print driver) is off. The second check spans a normal 11 inch form. The printer driver or OI is removing 4 lines between the stub and the second check body???? The first check and 1/2 of the second check line up perfectly!

I have checked the code and it is identical with regard to how many prints etc. The check form is a check stub with 21 lines and a body with 21 lines for a total of 42 lines. (assuming 6 lpi).

Well I think I got it!!!

Here is what I found. If the checks were printed from AREV everything worked. If printed from OI the windows printer drivers came into play and caused problems. What was happening is the paper size was modifying the print job. I called up my printer driver and chose "Document Defaults". I found a form that was 10x14. My checks are 42 lines or 7 inches. My printed form is exactly half the size of the form the printer thinks is loaded. Anyway after making these changes the Checks came out Perfectly!!!

Hope this helps,

Donald ..

Fascinating!!

Just copied that one for future reference. Good detective work.

Don

Don,

I found out more info. If I set the form length to 14 the first two checks came out fine but we had the same problem with the third check.

However, if we issued a form feed after the second check the third lined up properly. On to defining custom forms…

Once a custom form is setup, Checks8.5x7, you have to select it. The only problem is that OIPI does not expose the form names just the number. Therfore, we had to call the Set_Printer("INIT") multiple times setting the forms until the desired form dimension is found.

HTH

I found a really brute force solution: I do my dot matrix printing in an AREV 3.12 runtime. Since the app originally started in AREV, migrated to AREV before coverted to OI, it wasn't a hassle. No problems at all in checks, bills of lading, etc. I use OIPI for forms that are full page. Only AREV when the form size is non-standard.

It's a kluge but it works…

Don

I agree, there should be a better way of handling forms in OI. Unfortunately, this form has to be printed out of OI.

I found that if you used PRINT statements, you have to have your form be the DEFAULT form for the printer. Setting the form through OIPI only works if you do set_printer("TEXT","text to print") but then the font is screwy. Unfortunately, there is no way to set the Default form through OIPI. :(

HTH,

View this thread on the forum...