Hello All:

The Story so far
----------------

I want to compress a PCL output file via a standard UNIDRV based
printer driver in w2k. I need to do this so that a compressed PCL file
is read by another custom tool which will extract and interpret the
PCL Data.

To do this, I need a language monitor with my unidrv based printer
driver. According to my picture, The story goes that the pcl data is
received in the language monitor from the print processor. The
language monitor will compress and send the data to microsoft's own
port monitor via the FILE port and the file is saved and compressed.


Problem:
--------

I have compiled Microsoft's own sample of a language monitor, namely
the pjlmon package but I only could do this if I change the following:

1: There is a case statement with a syntax error using a ';' instead
of ':'
2: The assignments to the function pointer types mismatch so I had to
create wrappers which match those in the MONITOREX structure used in
the sample.

I installed microsoft's language monitor successfully after some
hassle but I still have more issues. Namely:

1: I had to remove references to critical sections everywhere.
2: I had to remove a validation UpdateTimeoutsFromRegistry in the
InitializePrintMonitor.

My problem is that my WritePort in the sample is not being called. I
have included some file output traces to check for this.
I also see that in MSDN, docs state that InitializePrintMonitor2 is to
be used for language monitors. It is not the case in MS's own sample.

Does anyone have experience on MS Language Monitors who can shed a
light upon my problem please?


Thanks and Best Regards

Duncan Camilleri

I am not clear on why you think that you need to write a language monitor to
compress the data from the driver. The language monitor should be used for
reading/writing status from/to the device. It isn't meant to be handling the
actual print data itself. So I suggest that you re-examine your approach. If
all you want to do is compress the data, you can either do this within a
port monitor or even within a rendering plug-in. My recommendation would be
to do it within a plug-in.

--
- Ashwin

Microsoft Printing, Imaging and Fax Team
This posting is provided "AS IS" with no warranties, and confers no rights.

"Duncan" <dnc77@hotmail.com> wrote in message
news:772ce810.0402250710.45cd4ecb@posting.google.c om...

I'll develop this for you if you wish.. please email for a quotation..
With Best Regards,
Andy

"Ashwin [MS]" <ashwinn@online.microsoft.com> wrote in message news:<OR#ikhI$DHA.2664@TK2MSFTNGP09.phx.gbl>...

Hi Ashwin:

Thanks for your prompt reply on my issue. I am quite a novice in this
area of development.

PORT MON
--------

I would receive data via the WritePort Function of a lang monitor,
compress it and send it using the port monitor's own call.

I understand that the port monitor's WritePort function is to send
directly the data to the port driver. So if I compress the data in
Lang Monitor and send it via the port monitor's WritePort function I
would be writing to my port which would be a file. Right??

I can use the standard FILE: port and therefore need not create a port
monitor to allow the creation of another port. Is this correct?


PLUGIN
------

Also, regarding the plug-in idea;

Do I in fact have access to raw PCL data within a driver plug in
because I had some problems. If I do have access to pcl data within a
rendering plug in, can you give me direction as to where?


Docs specify that scanline data is received in the plugin's
Compression function. I understand this to be bmp rather than pcl.

But I could not get the Compression function called in my plugin
either - Is there something which needs to be done apart from enabling
it in the ::GetImplementedMethod() call?


Thanks and regds

Duncan Camilleri

"Ashwin [MS]" <ashwinn@online.microsoft.com> wrote in message news:<OR#ikhI$DHA.2664@TK2MSFTNGP09.phx.gbl>...

You are correct in that you will not have to create your own port monitor if
you are printing to the existing FILE: port. But the language monitor is not
designed to be handling the compression of output data. So I wouldn't
recommend that you implement this within a language monitor.

If you do not want to write a port monitor, you can implement the
FilterGraphics callback within a rendering plugin. This basically gets raw
scanline data just before Unidrv is about to dump it down the stack. So in
other words, this would be the data the port monitor would receive in the
normal scenario. If you implement FilterGraphics, you basically get called
by Unidrv with the data. You can then perform any processing you wish on the
data and dump it out to the spooler (using DrvWriteSpoolBuf) which will take
care of writing the data out to the appropriate port. This would be a lot
cleaner solution than writing a language monitor or even a port monitor for
that matter.

--
- Ashwin

Microsoft Printing, Imaging and Fax Team
This posting is provided "AS IS" with no warranties, and confers no rights.

"Duncan" <dnc77@hotmail.com> wrote in message
news:772ce810.0403010629.1256e9f@posting.google.co m...