I don't know of a free utility that will do this.
Genarally, there are two ways to end the page. First, there is simply a formfeed (0x0c) inserted in the stream where the page ends. This is typically the way windows drivers do it. The problem in just counting formfeeds is that the FF characters can appear in fonts, in images, and other binary data that appears in PCL jobs, and do NOT represent an end of page. So the utility has to interpret the stream to decide if the encountered 0x0c is a control code to eject the page or simply binary data.
The other method as you are expecting, is based on a bottom margin at a physical address somewhere down the page. Whenever a linefeed or half linefeed puts the cursor over the bottom margin, the printer ejects the page.
The printer does NOT, however, count lines. While the bottom margin is defined in terms of a top margin and text length at a given line spacing, it is very common to change the line spacing in the middle of a page. Once the margin has been set, subsequent linespacing changes do NOT change the margin. So you are right back to to the proposition of interpreting the entire job stream to decide if this next linefeed should cause the page to eject. Of course, there is nothing to say that a given PCL job couldn't use both methods.
That is not to say that if YOU control all of the factors and can be 100% sure that you have only straight text at a given linespacing and text length, you could certainly count lines with some degree of success. The moment you add fonts or other binary data into the mix, it all falls apart.
If you are using a windows driver to generate the PCL file, you you will probably won't find any LF's at all. Rather, every word or even every letter is printed at a given x,y address. So you simply have to interpret the entire job to find where the page breaks land.
Something like pclsplit.exe is not a trivial piece of software.
Jim Asman
