Stimulsoft Reports.Net on Different Printer and Custom Paper

[jagger_terrain]

Hi

Hi good day to all. We are currently developing a big project. And this project we are using Crystal Reports for our reporting needs.
We are currently using the Crystal reports XI.
The problem we are facing right now is whenever we change printer the reports are messed up.
For example in our development area I am using a Epson printer to build and test print a crystal report document
with a custom paper size of 6 in x 10in. and when I roll out this report to the production areas the report
always renders and prints in a Letter size(8.5 x 11) or sometimes whatever is the default paper size set in the printer.
So the print outs or even in the preview the reports are cropped. :biggrin:
I did a lot of research about this and found out that somehow crystal reports is printer driver dependent.
The support engineers from CR told us that whenever we roll out the reports we must recompile the reports
in that particular printer, printer driver and to that custom paper.
(There is a way in the program code to assign printer, paper size and paper orientation but I doesn't really works!!! :pflaster: )
And indeed Crystal Reports is Printer Driver dependent.

Because of this issue we are now looking for a new report writer and seriously shifting from Crystal reports
In this project we are generating a lot of reports. And we have more than a hundred production sites.
And in those production sites they use different printers.
(just imagine compiling those 50 reports in more than 100 production sites! :redeye: )

Now we need a report writer that consistently print in different printer (or different printer driver) and in a custom paper.
Can this problem be solve by Stimulsoft Reports.Net?

[Edward]

Hi

Thank you very much for the explanation in detail.

We never recompile our reports in case of using of different printer drivers or paper sizes.

Were there any additional issues you faced with report creation?

Thank you.

[Brendan]

It sounds like you are facing the exact same problem I faced back in 2005. We were using Crystal reports and our software required printing custom paper form sizes to many different printer brands and models.
Initially when I was working with Crystal I only designed the report against one printer, not evening knowing about this problem. When things went into production it became almost impossible to maintain. Having to create separate report files for the same report because each report file was dependent on some printer code value unique to that printer.

Suffice to say, I abandoned that reporting tool as fast as possible when I discovered its limitations. I started looking at a couple of the new .Net reporting tools that were available around that time. After trialing some of them and discovering they were lacking in certain features I came across StimulReports. Back then it was version 1.3 I think, but even then it was still very easy to use and had the features I needed.

The one thing you need to be aware of is that if your reports are using custom paper sizes, then you need to make sure you setup these custom paper sizes in the Operating System also within Printers & Faxes. This way the .net runtime can make use of them for any printer that supports them which you have installed.

[jagger_terrain]

Hi

Thank you very much for the explanation in detail.

We never recompile our reports in case of using of different printer drivers or paper sizes.

Were there any additional issues you faced with report creation?

Thank you.

That was a quick reply!

That's a good news. We will evaluate StimulReports. We already downloaded a Stimulsoft Reports.Net 2009.1 Trial.
Does this evaluation has limitation in functionality compared to the registered version?
How about sub-reports?

[jagger_terrain]

It sounds like you are facing the exact same problem I faced back in 2005. We were using Crystal reports and our software required printing custom paper form sizes to many different printer brands and models.
Initially when I was working with Crystal I only designed the report against one printer, not evening knowing about this problem. When things went into production it became almost impossible to maintain. Having to create separate report files for the same report because each report file was dependent on some printer code value unique to that printer.

Suffice to say, I abandoned that reporting tool as fast as possible when I discovered its limitations. I started looking at a couple of the new .Net reporting tools that were available around that time. After trialing some of them and discovering they were lacking in certain features I came across StimulReports. Back then it was version 1.3 I think, but even then it was still very easy to use and had the features I needed.

The one thing you need to be aware of is that if your reports are using custom paper sizes, then you need to make sure you setup these custom paper sizes in the Operating System also within Printers & Faxes. This way the .net runtime can make use of them for any printer that supports them which you have installed.

Thank you for your reply! Having read your reply I am excited and motivated to learn this tool quickly.
I will surely be very active in this forum.