UPD Mail Archive: UPD> command sequences

UPD> command sequences

From: Norbert Schade (nschade@xionics.com)
Date: Fri Feb 18 2000 - 10:03:20 EST

  • Next message: don@lexmark.com: "Re: UPD> command sequences"

    I think we are on a good way here.
    I second the idea not to specify vector language. This is typically
    identical in all PDL implementations.
    We may come up with a list of functionality and command sequences, which we
    expect the driver to know and activate depending on a certain target model.
    I need a little bit more time to start that.
    Items in the list can be: Vector language, bitmap download, outline
    download, etc.
    Raster graphic to be checked.
    The list of command sequences to be supported in UPDF includes: job language
    (to be checked with IPP), session and page settings (paper handling, etc.),
    font selection and others.
    This list should be specified in our spec. That is exactly the kind of
    policy I talk about from time to time to provide some orientation for driver

    I see problems in reading fixed binary commands from a binary file. I'd like
    us to provide more flexibility here. We have a good chance to step ahead GPD
    We need to support formulas. The simpliest example is a command sequence for
    the height of scalable fonts. You will not list every point size. So you
    want to specify the height as a flexible parameter. I could imagine we can
    make it better than something like '%D', where the driver has to know that
    'D' in the height command is the height. There are more complex sequences
    with several parameters and working with methods like '%D' would be kind of
    restrictive by only being able to work with the predefined values.
    To give an odd example: If a special printer model would expect the width
    instead of the height as the parameter in our above sample, you would not
    have any chance to specify it, as the driver is assuming without any doubt
    that '%D' is the height in the print file.
    That's why I call a method like '%D' working with predefined parameters,
    while something like '%Height' (or similar syntax, to be discussed) would
    provide what I call speaking variables / meaningful variable names (help me
    with my bad English).
    It is very useful to even be able to do some simple calculations. Let's say
    it would be necessary to do something in 1200dpi (current device
    resolution), although the application is sending in a value in 600dpi
    (current graphic resolution). To stay with '%Height' sample this could then
    be '%Height*2'. The main issue to care for is the variable length of the
    But then you can feed the driver with nearly any kind of command sequence
    I'd like that to be on the agenda for the next conference I'll be joining
    (Tokyo or New York). The item should be called 'parameter converter'.

    Generally I think very much that we are heading the right direction with
    command sequences in the meantime.

    This archive was generated by hypermail 2b29 : Fri Feb 18 2000 - 10:08:48 EST