Crystal's handling of printer settings is, quite frankly, hooped. I
talked to the Crystal guys at the booth at PDC05 and they gave me some
reasons as to why it is this way, but for "normal" corporate printing,
it's just messed up.
In the version of Crystal Designer that comes with Visual Studio 2003,
you have two choices:
1. Choose "no printer" in the printer settings of your report. This
means, "Whatever are the default settings for the default printer on
the machine where this report is rendered, I want the report rendered
to that printer's default page size, orientation, duplexing, etc. etc."
2. Choose a printer in the printer settings of your report. Then you
can indicate that you want 8.5 x 14 landscape printing (for example).
However, this assumes that you are always going to print the report to
the _exact same printer_ in production. Of course, it's "never" like
that.
When you choose a printer for your .rpt file, this is what happens:
Crystal Designer grabs the DEVMODE structure for the exact printer you
specify, and lets you change the DEVMODE settings. That's what you're
doing when you set "Landscape" and the paper sizes. It then stores the
changed DEVMODE in the .rpt file.
When the Crystal Report rendering engine loads the .rpt file, one of
the first things it does is goes hunting for a printer with the _exact
same name_ as the one from which it grabs the DEVMODE structure
originally. If it can't find that exact same printer on your production
machine, it switches to the default printer for the production machine,
and tries to apply the DEVMODE settings from the .rpt file to that
production printer. If the default printer doesn't like the DEVMODE
settings from the .rpt file and mangles a bunch of them to suit its
tastes, then that's just the way it goes.
If you then switch printers in code (by setting a new printer name for
the report document object that you loaded via Crystal), then Crystal
will try to apply the DEVMODE settings to the new printer you have
assigned. However, if the DEVMODE settings have already been thrashed
by trying to apply them to the default printer, then that's just too
bad.
The whole thing is set up assuming that you are going to print your
report to exactly the same kind of printer with exactly the same name
on every machine.
We have had some success by making sure that we create printers on our
development box with exactly the same names as they have in production.
However, we have only one production server. People with multiple
production servers may find that this isn't possible for them.
Even if your printers have exactly the same names, you can be hosed by
custom forms. You see, the DEVMODE structure in the .rpt file stores
the _form code_ from the printer, not the name or size of the form. If
you're creating custom forms on your printers, there's no guarantee
that the same form will be represented by form #104 on all printers in
your organization. Since that's what the DEVMODE stores, just 104, you
may end up getting kooky results on one or two printers.
I've complained to Crystal several times about this. To me, it's
ass-backwards: I want to describe the overall shape of my report: paper
size, orientation, duplexing, etc. Then, later, I want to specify a
printer.
The response I got at PDC'05 was that the Crystal Designer takes great
pains to make sure that the report appears on the printer _exactly_ as
it does in the Designer, so they grab precise printer metrics and
precise page sizes and fonts, and for that they need the DEVMODE
structure.
My answer is that that is wonderful, but most business reporting
applications just want to specify some general things about the report,
and get some good-looking output. I don't _care_ if the text wraps at a
different word on different printers because there's a 1/64" difference
between the page widths. I just want output.
One of the guys at PDC'05 said that he thought this was fixed in
Crystal XI, but I haven't tried it out yet, so I can't vouch for that.
