PCL Compression / optimization 1

[JokkeDK]

Hi,

In my efforts regarding this topic, I recently discovered the PCLdiet program from

http://www.walterware.com/pcldiet.html.

This program might be just what I am looking for, so I contacted Mr Walter by email with an attached PCL-file for testing. But it seems, that he is not responding. More than a week has passed now...

Does anyone know, if he is still around?
Does anyone know of a similar product?

I need to optimize/compress some old overlay (macro) files, which seems to be much larger and complex than necessary. Any hints on how to go about making my own program for the job, would be appreciated too!

Thanks,
Jonas

 

[jlasman]

Compressing raster data is probably the only thing that will significantly reduce the size of a PCL file.

What is the nature of the PCL code? Sure, some commands may be able to be grouped, saving a few bytes here and there, but if your overlay is LARGE, I would expect that the bulk of it is probably a raster image. IF the raster data is already compressed, then you may not be able to acheive very much in reducing the file size.

If you want to email a sample file, I will have a look at it.




Jim Asman
jlasman@telus.net

 

[JokkeDK]

Thank you for replying,

Actually the issue here is probably not the size of the job. But more the speed, or rather the time consumed by the printer's controller while printing the job.
A typical job is around 3Mb, including 6 overlay-pages resulting in ie. 50,000 printed pages. A smaller job with ie. 5,000 pages would probably by around 2.5Mb.
So the overlays are taking up the majority of the space used. There's very little variable data per page, just a few strings of text: page number and such...
The overlays are generated from CorelDraw with a standard Win98 HP LaserJet 4 driver. There are some raster images (compressed? I don't know) in there, but not much. Mostly it is lines (tables) and text.

The jobs run on a Konica DP75 laserprinter (75ppm) connected to a WinNT4 server via 100Mbit Ethernet. So traffic on the network is minimal compared to the amount of print.
However, once the job is running, there seems to be a HUGE transfer of data between the printer's controller and the actual printer (these are connected via Firewire (I think)).
And it seems that the printer is about 2-3 times faster than the controller can deliver these data: The printer waits for 5 sheets (10 pages duplexed), prints these, wait ~20 seconds, prints 5 sheets, wait ~20 secs, and so on.

The overlay changes on every page:
OVL1 on page 1
OVL2 on page 3
OVL3 on pages 5,7,9 and 11
OVL4 on pages 6,8,10 and 12
OVL5 on pages 13,15,...,209 and 211
OVL6 on pages 14,16,...,210 and 212.
Recurring hundreds of times.
I have tried changing the way, the overlays are called (call/execute/overlay) - all the same.

This way I can't utilize the printer's nominal speed more than 30-40% :-(

Tomorrow, I will send you an example of a job by email.
If you have further comments or suggestions, they will be greatly appreciated.

 

[jlasman]

Very often, PCL code from windows drivers, wasn't created with performance as the main criterion.

Whether you call or overlay the macro isn't likely to affect the performance all that much.

In the perfect world you would download ALL the macros to the printer at the beginning of the job, and then enable the appropriate macro on each page. This assumes, of course, that each macro has a unique ID and there is enough printer memory to store all of them. The macros themselves are are only sent to the printer once for the entire print run.

If this is the way you are doing it now, then the only thing I could suggest it to rewrite that macros. In the past, I have coded a form that was > 800K as windows output and my file was on the order of 10K. If your macros are static and don't change from job to job, then you might look at redoing them.

I would doubt that any "compression" is going to fix your performance issue.

If it is done properly, you should be able to get the printer going at close to its rated speed.

But let's have a look at what is there now before making any judgement.



Jim Asman
jlasman@telus.net

 

[JokkeDK]

HI again,
> PCL code from windows drivers, wasn't created with
> performance as the main criterion

I suspected just that...

> download ALL the macros to the printer at the
> beginning of the job...
> If this is the way you are doing it now...

It is. The macros are downloaded with IDs 1 to 6 at the beginning of the job, together with the fonts used in these macros.
Then each page of the job begins with Overlaying the appropriate macro, after that the variable data, then formfeed, etc.

> If your macros are static and don't change from
> job to job, then you might look at redoing them.

They are (almost) static. But the number of different macros (.PRN-files) exceeds 1,000. So any kind of manually rewrite is kind of far out...

> I would doubt that any "compression" is going
> to fix your performance issue

Okay. I will rephrase the quest:
I want a program, that runs through a file of PCL code and optimizes the code for maximum speed. It doesn't matter if the number of bytes in the code is increased. (I just assumed that smaller equals faster, but perhaps that's not the case.)

 

[jlasman]

I don't know of any progam that can decode the logic of a PCL file and then rewrite it a more efficient manner.

You might look at creating a set of forms that contain all of the STATIC information on the page. Then have a series of macros the contain the variable data in the form, These macros could be calld by the main form or application itself. But again I will have to see the form as it to offer reasoned suggestions.

If you can exclusively make use of the printer's internal fonts, then you may find a big savings is filesize just by getting rid of the soft fonts.


Jim Asman
jlasman@telus.net

 

[richa60]

I have used pcldiet. It doesn't appear to be supported any more as I too tried for a long time to get a response from Mr. Walter.

pcldiet is a DOS based program. I sometimes find it to be a bit touchy but have always managed to make it work. For me, it seems to work best with the pcl drivers provided with Windows 98, and using the command line in the DOS window under Windows 98.

It does reduce the size of the files (sometimes dramatically) and it has a number of other features which I find to be valuable.

My favorite feature (and one which I would love to find in a newer product) is the ability to make the positioning in a pcl file relative rather than absolute, so that you can take (say) a pcl file of a company logo and place it on a page at the X and Y coordinates of your choice rather than at the position that they were on the page they were designed in.

 

[pagetech]

There is no single method of optimizing a PCL file. You pick the appropriate method depending on the nature and composition of the PCL you need to optimize.

If your PCL is mostly raster, then a PCLDiet like routine will help. If you know that you are only going to use a particular printer then you can also re-rasterize RLE compressed files into Adaptive Compression or proprietary compression methods from Lexmark, etc.

If your PCL has redundant downloading of fonts for each form page, then we have a FILTER program (using the "-7" argument) that can optimize a file by eliminating download font redundancies. The FILTER.exe comes with all our PCLTool products.

As with almost anything relating to PCL... there are no quick, all purpose solutions.

BP