2013 R2, RDLC and Dot-Matrix Printers

bhalpin

Hi.

A couple of years back I was horrified when I had to do document reports in 2009 R2 that would be output to a dot-matrix printer. When I warned the customer that the result might be slow/awful they came back saying tests with base NAV reports (run as Classic) seemed to print fine. So I did the reports and they were happy.

I'm facing the same request today, but this customer is on 2013 R2, so we're into RDLC. The tractor-feed forms are pre-printed, so there's no graphics - just text. But still, I'm worried ...

Does anyone have any experience with RDLC reports on a dot-matrix printer? (I'll be scouring garage-sales on the weekend for one to test with unless you all tell me it's not worth trying.)

Thanks!

Rob_Hansen

Great comment on the garage sales! I was going to reply simply to say "Dot matrix printers still exist??" but you did better. 10 points.

daborg

A lot depends on the age of the printer and if it has a "real" Windows driver or some generic text driver. The generic ones are not so "speed friendly". Another thing you need to look out for is the font that is used in the report. Dot-matrix printers only support a specific set of fonts and sizes, so in all likelihood, you need to change the font of all fields in the report to use one of the printer-friendly ones. You'll need to do some research on the specific printer model to find out what fonts it has support for.

There are plenty of articles around the web describing dot-matrix printing and SSRS with varying degrees of success and performance. I imagine the same principles would apply to our RDLC reports too.

clausl

And the reason for the customer not buying new printers is just because that is an investment and they can then trow out a lot of pre printed tractor-feed forms out the window, or are there any other business reasons to stick with the Matrix printers?

/Claus Lundstrøm

bhalpin

Well, I can't really answer why they want to continue with the pre-printer forms. However a lot of our customers who implement a new ERP system are sort of forced to technically (old system has no support any longer) or regulatory reasons (food industry - so increasing quality/safety audit requirements). Past that they are resistant to change (who isn't?). We do our best to advise on new best/practices, but in the end they pay us. Know what I mean?

Thanks for prior post about the 'technicals' regarding this issue - if this goes all the way to implementing their reports using a dot-matrix, I'll update this thread with anything I learn.

jglathe

Interesting. I had a similar problem when I migrated bakeries from Navision 3.56 or dbase-based to a solution based on Financials 2.x, 2001/2002. They all use dot matrix printers, for good reasons. They need the carbon copy for their workflow, other solutions are simply clumsy as hell. We have done extensive tests to get the printers anywhere near the original printing speed from the text-based applications. The solution was to use the fonts the printers had built in, and to find a driver that did an acceptable job at using them from a windows application. Even then, the printout was less than half as fast in Financials... but it's fast enough, the setup is still running with much more orders than 2002.
The main problem appears to be the recognition that these things are still in use and have their place. Windows developers seem to have forgotten about them since day 1 (or Windows 95). Application developers found no acceptable support in Windows... the rest is history

with best regards

Jens

kine

You can try to use the generic text printer driver to send the report with correct font and size to the printer as text to print it correctly. We were using it for classing, I never used it for RDLC yet, but in general, it is still same, instead graphics output it just send the text. Thus it could work, but you will need to elaborate with the positions and settings of the fonts and with the setting of the drivers (you can set some escape sequences to select different build-in font characteristics of the printer).

clausl

jglathe wrote:

They all use dot matrix printers, for good reasons. They need the carbon copy for their workflow, other solutions are simply clumsy as hell.

Hi Jens,

Could you be more clear on the good reasons for keeping Matrix printers. Why is a copy of the report not good enough, is it because they manual write on the paper and then this is also shown on the carbon copy? Or are there other reasons?

/Claus

jglathe

Hi Claus,

clausl wrote:

Why is a copy of the report not good enough, is it because they manual write on the paper and then this is also shown on the carbon copy? Or are there other reasons?

Exactly. They use the shipping document as a collector for deviations and notes alongside the picking/delivery process. The customer signs the shipping document, and the carbon copy goes back to order dispatch where all changes are entered into the system, and post-processing on the notes is done. There are 3 stations who add information on the document: picker, delivery man, and customer. To get the same without carbon copy you would need to make a copy after the signature of the customer. I wouldn't say impossible, but as I said... clumsy, cumbersome, expensive, and far less reliable than a simple carbon copy.

with best regards

Jens

bhalpin

Update.

Nearly there, but ...

When tested on a laser printer, the output is in landscape and lines up perfectly with the tractor-feed forms (if you turn the laser page sideways.)

When printed on their dot-matrix the text is printed vertically up/down the page instead of across. (!)

So, the report is printing in landscape mode.

Now the fun: In the properties of the report we try changing the format to landscape and the page size to 11 (wide) x 8.5 (high). The second we set the page width the mode snaps from portrait to landscape again. It seems that if you set a page width that is greater than the height that it assumed (and forces) landscape mode.

We don't want landscape (with the text printing vertically on the page), we want portrait with a 'wide' page.

Is there some way of getting past this?

Thanks in advance!

ppavuk

Ages ago, probably in 2003 or so I had customer, who used a dot-matrix printers. The big and fast ones, which print a page in 4 second or so in 5 copies

finally, after messing with printer drivers quite a while I just created a text file using file.write(textline). of course, for formatting (like bold, font size, pitch, etc...) i had to use <Esc> characters (if you still can remember what is it ) . Then file has been stored to the network location, and on the machine where printer has been connected a small VB6 program monitored the folder and just send the text files to lpt1 using copy /b

This setup worked quite well for years and years.

bhalpin

Hi.

Yes, I remember those days. Could probably recite Epson & HP sequences for pitch, character set, etc. from memory ...

I had thought of a solution like this, but the plot has thickened a bit. We had the client test a base NAV landscape report and it printed correctly. Not quite sure what exactly is going on though, as they have two printers and we can't get straight what was tested on which printer, etc.

The fun continues ...

ppavuk

Honestly, if i had been asked to deal with dotmatrix again - I'd go the text file route then probably using .net we can do even better now, just sending the stream straight to the printer or so...

bhalpin

Solved.

Got on GoToMeetng with on-site user and they demo'd the printing. With printer selection dialog up they said "It's set to Landscape". Before they hit Print I stopped them and said "Why not try Portrait?"

It worked.

[-o<

ppavuk

bhalpin wrote:

Solved.

Got on GoToMeetng with on-site user and they demo'd the printing. With printer selection dialog up they said "It's set to Landscape". Before they hit Print I stopped them and said "Why not try Portrait?"

It worked.

[-o<

As usual, the problem has been between a chair and computer!