Report Writer (manual duplexing)

[slestak]

Hi Guys,

Trying to devise a way to do manual duplexing in RW.  I have a large report that page breaks between customers.  This report will ultimately be bursted and mailed to each customer individually.  The problem is having one customer start on the back of another customers data.

I know how to determine if a customer needs an extra form feed (based on whether @RV.PAGE is odd or even).  But what I haven't figured out is how to push a form feed from report writer.

Any ideas?

[Tom Pellitieri]

I haven't tested this, but I think this will work.

Add a WORK/USERDATA/PARMS field as a primary break.  For example, in Break Fields, use:

@WORK<1>(P CUST.NUM(P ...

Set WORK<1> to zero in Process at Start.  In Process after Break, if @RV.BREAK.FLD = 2 and @RV.PAGE is even (top of back side of page), increment @WORK<1>.

Certainly worth a try.

--Tom Pellitieri

[precisonline]

Here's how I would approach the issue... In the detail section, add an extra D line followed by a P line at the bottom of the section.  The P is a page break.  Use a conditional on the extra D line to skip 1 line when you want the page break, skip 2 when you don't.

[Tom Pellitieri]

Okay.. this is why Kevin is THE GURU!!

I've been working with Report Writer for nearly 15 years and did not know about the "P" option... 

--Tom

[slestak]

I think we missed something.  I think we will need a process in Process After Break process slot.  How does your method account for a customer that spans multiple pages.  It need to check for @RV.PAGE odd/even only when cust.num break occurs.

I also noticed there does not appear to be a modulo operator in RW.

[slestak]

What about if we could put something in to basically "Close" the report on the primary break value.  That would be very cool.  Then we would have a new print job for each customer.

[precisonline]

Interesting ideas, definitely.  In your Process After Break you could call a BASIC routine that does this:

SUBROUTINE RESTART.PRINT.JOB
$INCLUDE DMSKELCODE COMMON
PRINTER OFF
PRINTER CLOSE
PRINTER ON
RETURN

Not sure it'd work, but it should be worth a try.

[Tom Pellitieri]

I just tried a report with my break section ending with two lines:

B
P

On the "B" line, I had a conditional with MOD(@RV.PAGE,2)=0,2,1

One problem - the "P" line actually takes a line in the output!  If your break section fills the odd-page exactly, the condition appears to add a blank line, then the page break for the "P", then a page break for the section.  The next section winds up starting on an even page, instead.

Mind you, this self-corrects with the next item, but you wind up with a blank face page.

Not perfect, but it works.

--Tom

[precisonline]

The P line ends up printing a blank line?  Well crap, that's not pretty.

[Tom Pellitieri]

I gave this a bit more thought and research.

When I look at my reports in _HOLD_, they have every page filled with blank lines.  They do not rely on the Form Feed to start the new page, even though they are used.

Having said that, here's what I think is going on...

I *think* that RV.PAGE is not updated until the break section is completed.  The break is handled when the first record of the next section is in @RECORD.  It has been observed that fields in the header section use values from the next section when the break occurs at the top of the page.  I think this may be a related issue.

For what it's worth:  the "bug" only appears when the data and break section totally fills a page.  The next section starts on an even page, with a blank odd page before it.  The annoyance is that this next section has a blank front page, but at least it is separated from the prior duplexed section.

--Tom

[precisonline]

The lack of form feed characters is actually based on the printer configuration as I recall.  In the printer class there's a FF setting that controls this.

With the @RV.PAGE and break logic, I would tend to agree with your assessment because the last thing that the break section does is page breaks if the (P is added to a break field.  You're right of course, if the page is full and a page break is triggered after that, there's going to be a blank page.

Doesn't this seem to support the idea that having separate print jobs might be a better way to go?

[Tom Pellitieri]

I agree that separate jobs would be cleaner.. especially if you reset the page counter!

As to the Form Feeds - they're in there.  I get 65 full lines, then the header for pages beyond 1 begins with ASCII 12...

--Tom