On the subject of Vector Language....
I don't think we should assume that every printer uses the same language or that
all printers use a language from some predefined set. We must consider the case
where a printer has a unique and proprietary language. How would the UPD know
about it? How should the UPDF tell the driver about it? Is this a separate XML
file or one that is included by the UPDF?
**********************************************
* Don Wright don@lexmark.com *
* Director, Strategic & Technical Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************
nschade%xionics.com@interlock.lexmark.com on 02/18/2000 10:03:20 AM
To: upd%pwg.org@interlock.lexmark.com
cc: (bcc: Don Wright/Lex/Lexmark)
Subject: 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
developers.
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
here.
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
name/formula.
But then you can feed the driver with nearly any kind of command sequence
description.
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.
Norbert
This archive was generated by hypermail 2b29 : Fri Feb 18 2000 - 13:13:08 EST