Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


bitmap printer driver

OSR_Community_UserOSR_Community_User Member Posts: 110,217
Hi guys.

I´m trying to write a bitmap printer driver,
and i want to know what is the format of data
contained in pBuf pointer in IPrintOemUni::FilterGraphics
function.

thank in advanced.

tolemaC / eleriumcore & unknownproductions
[email protected]

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    You get scan line data in the FilterGraphics callback.

    IPrintOemUni::FilterGraphics - Allows a rendering plug-in to modify scan line data and send it to the spooler. If you implement this, then Unidrv would not spool your data. instead your method will be called every time a buffer of data is sent and is ready to be spooled. The OEMFilterGraphics callback can be used to implement a special compression method, or to perform bit manipulation on the data stream that is sent to the printer, or both. In either case, the driver's built-in compression code is not used. OEMFilterGraphics is presented with a block of data and is required to send all output the data and to emit them using DrvWriteSpoolBuf. The driver will perform no further processing of the raster data after calling OEMFilterGraphics.

    I would recommend to you to first simply experiment with the OEMUNI sample from the DDK as is. That is, just build the sample in a Checked build environment, enable full debug logging (through the sources file for this sample) and install it on a test machine using the OEMDLL.inf. Then, try printing something very simple from wordpad and observe the debug spew in Windbg. You should see the FilterGraphics() callback spitted out a number of times. Then you can try setting a breakpoint at the return in -

    HRESULT __stdcall IOemUni::FilterGraphics( PDEVOBJ pdevobj, PBYTE pBuf, DWORD dwLen)
    {
    DWORD dwResult;
    DebugMsg(DLLTEXT("IOemUni::FilterGraphics() entry.\r\n"));
    m_pOEMHelp->DrvWriteSpoolBuf(pdevobj, pBuf, dwLen, &dwResult);
    if (dwResult == dwLen)
    return S_OK;
    else
    return S_FALSE;
    }

    You might want to experiment with Paint and then with text. When you provide the FilterGraphics callback in your OEM DLL, it will be used for sending the raster data directly to the printer. The number of scanlines in a block is specified through the optional parameter in the *Resolution section in the gpd : *PinsPerPhysPass (this is explained in the DDK too under < 4.6.4.8 Option Attributes for the Resolution Feature >. This parameter is optional and if not mentioned, it is 1, as for most of the InkJet and page printers; else it should be a multiple of 8. In the FilterGraphics callback above, pBuf points to the buffer containing the scanline raster data to be manipulated by the OEM if necessary (eg compress etc) and finally sent out. dwLen is the length of this buffer.

    Examples why OEMs use the FilterGraphics callback in their plugins are: 1. special compression techniques, 2. Bit manipulation of the incoming raster data before sending it out to the printer etc. (which is what you seem primararily interested in, right?) All the data should finally be sent by FilterGraphics to the printer using the function DrvWriteSpoolBuf(). The driver does not do any more processing on this data sent out by FilterGraphics(). Now, if the OEM is indeed doing some special compression/bit manipulation, he is responsible for allocation of the buffers necessary for doing so. If you do not allocate your own buffers, then your output will overwrite the source buffer if the compresses data is smaller than the source.

    Thus, I think, you should be able to accomplish the raster data manipulation in the plugin using OEMFilterGraphics(). What you are given is simply a chance to postprocess the raster data and the access to the data itself. What you do with it is pretty much upto you and completely in your hand.

    - Ashwin

    This posting is provided "AS IS" with no warranties, and confers no rights.

    -----Original Message-----
    From: tolemaC [mailto:[email protected]]
    Sent: Friday, May 24, 2002 12:10 PM
    To: NT Developers Interest List
    Subject: [ntdev] bitmap printer driver


    Hi guys.

    I?m trying to write a bitmap printer driver,
    and i want to know what is the format of data
    contained in pBuf pointer in IPrintOemUni::FilterGraphics
    function.

    thank in advanced.

    tolemaC / eleriumcore & unknownproductions
    [email protected]

    ---
    You are currently subscribed to ntdev as: [email protected] To unsubscribe send a blank email to %%email.unsub%%
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Ok.

    I will create a .bmp file and i will write each the scanline from
    FilterGraphics
    function, i need to know the following for it:

    1. where/when i must create the .bmp file.
    2. in what format is the scanline contained in pBuf parameter of
    FilterGraphics function.
    3. what dimensions will have my bitmap.

    Possible solutions:
    Can i create the .bmp file in the first call having a "firstCall"
    private
    variable in IPrintOemUni implementation?
    Is the scanline format RGB color? or any seemed?
    are the output bitmap dimensions held to print orientation(landscaped,
    portrait)
    being it fixeds?

    well, i hope to resolve it.

    THANKS, in advance. :)

    - tolemaC
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    - You can create the bmp file in the OEMStartDoc hook. You can also
    create it in FilterGraphics itself. But for this you will need to
    maintain a flag in your PDEV structure that will indicate if the bitmap
    has already been created or not.

    - I don't understand what you mean when you say "what format is the
    scanline". GDI predominantly understands only the RGB color transform.
    So you can expect the data to also be in RGB format.

    - About the size, you will be getting a known number of scan lines (1
    row of 1bpp bitmap) OR The number of scanlines is actually equal to =
    *PinsPerPhysPass. For monochrome, you have 1 pixel = 1 byte. Bit depth =
    num of bits/pixel = 1 for monochrome (1bpp). Thus, number of bytes in
    one scan line = num of pixels/line = page width in pixels (bytes).

    Number of scan lines = Height of the image; for 1bpp, thickness of each
    scan line = width of 1 pixel; thus num of scan lines=height of image.

    - Ashwin

    This posting is provided "AS IS" with no warranties, and confers no
    rights.


    -----Original Message-----
    From: tolemaC [mailto:[email protected]]
    Sent: Friday, May 24, 2002 10:32 PM
    To: NT Developers Interest List
    Subject: [ntdev] RE: bitmap printer driver


    Ok.

    I will create a .bmp file and i will write each the scanline from
    FilterGraphics function, i need to know the following for it:

    1. where/when i must create the .bmp file.
    2. in what format is the scanline contained in pBuf parameter of
    FilterGraphics function.
    3. what dimensions will have my bitmap.

    Possible solutions:
    Can i create the .bmp file in the first call having a "firstCall"
    private variable in IPrintOemUni implementation?
    Is the scanline format RGB color? or any seemed?
    are the output bitmap dimensions held to print
    orientation(landscaped,
    portrait)
    being it fixeds?

    well, i hope to resolve it.

    THANKS, in advance. :)

    - tolemaC

    ---
    You are currently subscribed to ntdev as: [email protected] To
    unsubscribe send a blank email to %%email.unsub%%
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE