Problem while performing StretchBlt on HP 1010, HP 1018, HP 1020 andHP 3050

Discussion in 'Windows Vista Drivers' started by Harish, May 6, 2008.

  1. Harish

    Harish Guest

    Our application uses Windows GDI library to perform rendering and
    display of data/output onto
    the devices such as Screen and Printer.

    While I am trying to print the data onto a series of printers (HP
    1010, HP 1018, HP 1020 and HP
    3050) I am facing a typical problem.

    Explaination
    ------------------

    1. Appropriate DC for the intended device is created [Printer DC
    created for a selected printer in this case]
    2. The data is displayed onto the identified position onto the DC

    The details of data (fields) to be displayed and their position onto
    the DC is calculated before the printing begins.

    If sufficient space is available for displaying/printing a field
    (data), then it is displayed directly onto the DC (using TextOut.

    However at situations, the space available for printing (displaying) a
    piece of data may not be enough. In such scenario, I display such
    information onto a temperory (display) DC and then perform
    StretchBlt(....) onto the printer DC.

    StretchBlt is capable of performing both Stretch / shrink from source
    DC to the destination DC.

    [MSDN: The StretchBlt function copies a bitmap from a source rectangle
    into a destination rectangle, stretching or compressing the bitmap to
    fit the dimensions of the destination rectangle, if necessary. The
    system stretches or compresses (shrinks) the bitmap according to the
    stretching mode currently set in the destination device context].

    In this case:
    - Data is first displayed / outputted onto tempDC
    - Then StretchBlt is performed from tempDC to PrinterDC


    The rectangular area on the destination DC is more than source
    rectangular area then data is stretched
    If the rectangular area on the destination DC is less than source
    rectangular area then data is shrinked

    StretchBlt(...) allows us to specify the raster operation to use while
    performing this task as its last parameter.

    Here I am using SRCAND. When I use SRCAND raster operation the data is
    displayed in actual font size instead of shrinking. This results on
    loss of data (as sufficient width/height) is not available to
    displayed data

    The same operation works on several other DeskJet/LaserJet (including
    HP) printers. But it fails on the above mentioned set of printers.

    If I try to use other raster operation such as SRCCOPY, it is able to
    shrink the data and display properly. I can't use other operations. I
    have to use SRCAND (as I would like to retain any data that is already
    displayed within the rectangular area).

    I also observed that, if the destination rectangular area is more than
    source rectangular area: then it is able to stretch and display the
    data without any loss (even with SRCAND raster operation)

    Please let me know, if any of you have already encountered such
    problem and any solution

    Thanks & Regards,

    Harish Sohani
    Tally Solutions Pvt Ltd.
    Bangalore.
     
    Harish, May 6, 2008
    #1
    1. Advertisements

  2. Harish

    Tim Roberts Guest

    Devices are not required to support StretchBlt at all. Printers are
    notorious for getting it wrong, and even the GDI simulation sucks.

    It would be a much better plan for you to implement your own StretchBlt
    operation with your own stretch/shrink algorithm, and blt the final bitmap
    to the printer.

    In general, it is safest to assume that printers are stupid.
     
    Tim Roberts, May 8, 2008
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.