Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

PCL page splitter

Status
Not open for further replies.

surge19

Programmer
Mar 28, 2006
6
US
We need a utility to count the pages in a PCL file and split the file into smaller pieces which can be printed separately.

pclsplit.exe by pagetech(pagetech.com) does this, but there's a licensing fee.

Wouldn't such a utility be relatively easy to make?

How is the binary page data divided into different pages, does the printer just take in X number of lines per page? How do you count lines?


Or is there a free command line utility for this?


 
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
 
I agree with everything that Jim has said.

The only other point I'd add is that there are a number of PCL sequences which cause an implicit form-feed.

For example, a 'set orientation' sequence which specifies an orientation which is different to the current orientation will cause an implicit form-feed (unless the sequence is encountered before the current page has been marked in any way).

So, again, you'd need to parse the PCL stream in an intelligent fashion to determine where such a page break might occur.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top