Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Printing Reports  RSS feed

Tim Holloway
Posts: 18705
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
(topic change carried over from )
Well, going all the way back to my COBOL days, the way I've usually printed reports was to output the detail lines via a report-print subroutine. In the old days, it looked something like this:

The only real difference in the modern-day approach is that "line-number" has become a Y-coordinate, incremented by LINE_HEIGHT and the LINESPERPAGE item is now the y value that signals the break between page details and the footer.
And, of, course, printLine gets replaced with
graphics.drawString( reportLine, LEFT_MARGIN, y );
If you prefer Report Writers, they're a different animal, since very few general-purpose programming languages include one. IBM COBOL used to have one, but it was yanked decades ago. Microsoft is diddling around with one for VB to replace Crystal Reports, but it was pretty feeble. FoxPro's may be the best of the lot.
One thing you COULD do in that regard, BTW is upgrade the FoxPro reports to Visual FoxPro, buy a copy of Adobe Acrobat and route the FoxPro output to the Acrobat printer. Although performance-wise, it would probably go faster to keep the old FoxPro 2.6 reports and run them through the code I outlined about using gnujpdf.
I'm afraid that true line-oriented printing is almost extinct. Even on mainframes, the printers themselves are graphical devices. Legacy apps may THINK they're printing lines-by-line, but they're going through the same basic process as I listed up top when the printing subsystem actually gets ready to do the actual output.
[ January 30, 2002: Message edited by: Tim Holloway ]
[ January 30, 2002: Message edited by: Tim Holloway ]
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!