Richard Stallman <[EMAIL PROTECTED]> writes: > Omitting the trailer causes GNU pr to try to print on > the very last line of the output page, which is a portability hassle: > some printers and printer emulators ignore newline before formfeed on > the last line of a page, while others don't. > > Wouldn't the trailer force a move to the next page, > exactly the opposite of what we want?
Sorry, I see I wasn't clear. By "omitting the trailer" I meant that GNU pr attempted to print on the very last line of the output page, omitting the usual trailer of 5 blank lines at the bottom of the output page. Printing on the very last line is a portability problem, since printers and printer emulators vary as to what they do if you output the characters of that line, then '\n', then '\f'. Some printers will then print a blank page; others won't. And you cannot work around the problem by omitting the '\n', because in that case some printers will not go back to column 1 in the new page. One other thing: there are even worse portability problems if you output on the very last column of the last output line of the page. Some printers then wrap to the next page, so that \f then generates a blank page regardless of whether you precede it with \r. Others don't. > submit a patch along those lines shortly, to bug-coreutils. This is > an incompatible change, since it will output 7 fewer lines per page > when you specify -F; > > Don't you mean 7 more lines? I don't follow. I meant that it outputs 7 fewer data lines (i.e., lines containing a copy of the input file). This is because the header now contains 5 lines, not 3, and the trailer now contains 5 lines, not 0. > Anyway, if this change means less output per page, why do it? In other pr implementations (notably BSD), the -F option does not change the appearance of the output page; it changes only whether \f is used. This makes sense to me. First, pr's implementation method for separating pages ought to be independent of the appearance of the resulting pages. Second, it means pr dodges the portability hassles mentioned above. Finally, when in doubt it is better for GNU pr to be compatible with BSD pr. > I'd rather change just enough to fix the problem. It would make sense to give GNU pr an option to control the number of lines in the header and the footer; this would give you the output format you prefer. Someone who implements this option can deal with the formfeed portability hassles mentioned above. My suggestion is to try outputting \r before \f after outputting to the very last line of the page, but it will require a some testing with real-world printers and printer emulation to see how well this works. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
