Hi Tim,
All is working OK but I'm not exactly sure why?. I know that with the way I
have Citrix setup that I have been running individual dpspool.ini files for
each user and there may have been an issue with that when I was testing.
I run a modified Ist page header so that each user has their own printdoc
folder in their own dpspool directory. Each report prompts for RV249 - user
initials, and RV250 looks like this in each report
cat.c["c:\wtsrv\profiles\"RV249"\dpspool\printdoc\";
apply.format["G999";today - date[1;1;year[today]] + 1]
apply.format["G99999";now];
".{1}"]
Each users dpspool start file uses a dpspool.ini placed within their dpspool
folder - this simplifies printer mapping etc and avoided the old problem of
a print job printing multiple copies for each user with dpspool running.
Dpspool.exe resides only on the server. So I found a problem with the wrong
(default) dpspool.ini file being used when in test mode due to wrong startup
file being used, but I believe that hard coding within each Report should
override what's in the dpspool.ini file ?? Have I got that right?
It must be something else but it started printing correctly after I went
thru the following procedure having read your latest email notes. Everything
appeared to be OK so I came to the conclusion that the <249> codes were not
being recognised by either printer I was testing on. Custom form was No. 178
and I had this in the first page header
Printer Control: <249>S178<249> <244>FCourier New<244> <244>P14<244>
and thought I'd add <249>C2<249> as a test. Didn't have room to put it on
same line so put it on the line above. Printed out via DPSpool and 2 copies
printed fine - Thought maybe the <249> codes had to be on their own line but
I simply removed the C2 coding (didn't change anything else - honest) - and
since then its worked without a problem. I must have tweaked something else
but sorry I have no idea what. (which annoys me - I like to know these
things :-)
Many THANKS again Tim for your input and detailed notes which really did
help my understanding and, I wish I could be more clear on what I had wrong
that I changed to get it working correctly
Regards
Colin
----- Original Message -----
From: "Tim Rude" <[EMAIL PROTECTED]>
To: "Dataperfect Users Discussion Group" <[email protected]>
Sent: Sunday, 29 July 2007 15:11
Subject: Re: [Dataperf] DPSpool / Printer Configuration Question
> Colin,
>
> I'm a little confused about what you're describing, so maybe a
> generalized description of what the margin settings do and how this
> affects DPSpool (and the Windows printer drivers) may help you.
>
> When your DP report has the print margins configured with the Bottom
> Margin at zero (as the DPSpool documentation calls for), DP sends a
> Form-Feed code when it's time for a new page. When you look at the
> report in the DPSpool viewer, this code looks like a cross with a circle
> at the top, also known as the 'Female' sign or the 'ankh' sign. Clicking
> the mouse cursor over this character reveals it as <012>.
>
> When DPSpool encounters this code, it in turn sends a form feed to the
> printer, telling it to eject the current page. For sheet fed printers,
> this just spits out the current piece of paper. But for dot matrix
> printers using continuous form paper, it tells the printer to advance
> the paper to the next perforation (or to where the printer thinks the
> next perforation is). This means that for a dot matrix printer, it's
> crucial that the Windows driver knows exactly what size paper is loaded
> into the printer so it knows how far it is between perforations. That's
> why I had you create the custom paper size in the Windows Print Server
> in an earlier message in this thread. Now you need to be sure to tell
> DPSpool (by including the appropriate code in your report) to use this
> custom paper size. You can use the Printer Information tool on DPSpool's
> printer setup screen to determine what paper size number corresponds to
> the custom paper size you created.
>
> With these settings in place, you should be able to print the entire job
> correctly.
>
> Going back to the DP Report Margins setting, what happens if you ever
> specify something other than zero for the Bottom Margin setting? Well,
> in this case DP handles page ejects completely differently. Then it
> never sends the form-feed code. Instead, it determines for itself what
> the paper size is by adding together the Top Margin, Text Lines, and
> Bottom Margin amounts. Then it keeps track of how many lines have been
> printed on the paper so far, and when a page eject is needed it sends a
> number of blank lines (hard returns) to advance the print head down to
> the next page. For a dot matrix printer using continuous feed paper,
> this might work if your math is correct and (most importantly) if you're
> printing directly to the printer (not using DPSpool). But under Windows
> and DPSpool, the pages are handled differently. Whether you're printing
> on continuous feed paper (i.e. dot matrix) or sheet fed paper (i.e.
> laser or inkjet), the Windows printer driver controls what goes to the
> paper, and which page it goes to.
>
> When the Windows printer driver receives more text than will fit on the
> current page, it essentially discards anything outside of that specific
> page's printable area. It doesn't start a new page until it specifically
> receives the Form Feed command. If (because of your setting the Bottom
> Margin to something other than zero) your DP report is trying to control
> the pagination by hard returns rather than using the form feed code, the
> printer driver never realizes that you want to start printing on a
> second (or third, or fourth, etc.) page. It says, "I'm still working on
> page one so I'm ignoring all of this stuff that stretches on past the
> bottom of page one's printable area." It makes sense, and it makes the
> drivers behave the same regardless of what type of printer or paper
> you're using.
>
> That's why the DPSpool instructions tell you to always set the Bottom
> Margin setting to zero, so DP uses the official Form-Feed code method of
> page ejection, rather than faking it with hard returns. Then the printer
> driver knows when to start a new page and nothing should get lost into
> the ether. :)
>
> Hopefully this explanation will give you a better understanding of what
> you need to do to get your reports working properly with DPSpool.
>
> Tim Rude
>
> ----- Original Message -----
> From: "Colin Roberts" <[EMAIL PROTECTED]>
> To: "Dataperfect Users Discussion Group" <[email protected]>
> Sent: Thursday, July 26, 2007 8:28 PM
> Subject: Re: [Dataperf] DPSpool / Printer Configuration Question
>
>
> > Sorry Tim, Just re-read my email and I got it completely around the
> wrong
> > way. All I said in previous email stands except the item 7 bottom
> margin
> > details is reversed in the two scenarios.
> > So.... it prints the whole form without page breaks when the bottom
> margin
> > is set to zero (and that's how it looks in the viewer) and only prints
> the
> > 1st page when BM is set to 3 but the output looks ok in DPspool print
> viewer
> > before its released)
> >
> > Regards
> >
> > Colin
> >
> > ----- Original Message -----
> > From: "Colin Roberts" <[EMAIL PROTECTED]>
> >
> > _______________________________________________
> > Dataperf mailing list
> > [email protected]
> > http://lists.dataperfect.nl/mailman/listinfo/dataperf
> >
>
> _______________________________________________
> Dataperf mailing list
> [email protected]
> http://lists.dataperfect.nl/mailman/listinfo/dataperf
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
