UPD Mail Archive: UPD> Manual duplex

UPD> Manual duplex

From: Norbert Schade (norbertschade@comcast.net)
Date: Fri Mar 05 2004 - 08:17:07 EST

  • Next message: Norbert Schade: "UPD> UPDF last call, day 5"

    This is a personal statement and demonstrates one view of how to use the information stored in a UPDF device description.

    Larger picture
    I see manual duplex as part of some functionality I call 'Paper Path Preview'.
    This includes information to the end user on how to insert print media properly into the tray (face-up/down, leading edge), what will happen to the media in the device (flipped once or twice in a duplex unit) and how the output bin will influence the path and the final face.

    Manual duplex is just a very special case of using that information twice.

    Target module for implementation
    1. priority: Spooler
    The number of conditions due to special behavior of input trays, output bins and other factors is finite. As a matter of fact, it's not overwhelming. A generic solution is the target. That would mean a device description like the one in UPDF does not provide dialog information for manual duplex. However it provides the proper attributes for the path the print media takes. This is implemented in UPDF (I don't know of any other concept). Check the attributes in features MediaInputTrayCheck, OutputBin, and Sides.
    2. priority: Driver
    The driver may jump in as a substitute, if the spooler is not capable. This may be operating system specific.

    Features involved (from a UPDF point of view)
    - feed orientation: saved with the media size feature
    - page orientation: saved with the OrientationRequested feature
    - long-edge/short-edge: saved with the Sides feature
      - there is an extra attribute telling about flipping
    - face-up/down (input): saved with the input tray
    - media flipped in output bin: saved with the output bin
    - input trays available for the second path of manual duplex: this can easily be covered by dependencies
    - output bins available for manual duplex: this can easily be covered by dependencies

    One special implementation sample
    1. Device settings of a pretty popular sample device
    - input tray: short-edge first, face-up, landscape is 90 degrees anti-clockwise
    - output tray: top, media gets flipped once
    2. Implementation in spooler
    The spooler/driver has a number of text modules (in this simple sample we do not think about animated pictures).
    For this sample the page orientation does not affect the functionality. We can ignore it.
    2.1. short-edge
    Text module: something like 'remove the print medium from the output tray and insert it without turning nor flipping.'
    2.2. long-edge
    Text module: something like 'remove the print medium from the output tray and insert it while turning it 180 degrees without flipping.'

    I know the sample is simplistic, but that's about it. the rest would be cosmetic.

    Some details about the special device description (as I would do it)
    - of course, fill out all paper path related attributes in the description
    - filter out input trays you don't want to be available for manual duplex
    - filter out output bins you don't want to be available for manual duplex

    You know of any other concept providing the necessary information without a huge and dedicated function call? Tell me!
    This is a true data driven approach.
    I think when you see the UPDF paper path attributes, they are almost self-explaining.

    Regards
    Norbert Schade

    Norbert Schade
    69 Prescott Drive
    North Chelmsford
    MA 01863
    phone: 1-978-251-1017
    email: norbertschade@comcast.net



    This archive was generated by hypermail 2b29 : Fri Mar 05 2004 - 08:22:31 EST