It has been my assumption all along that we would have to include these command
sequences. There's simply no way around it. Is it time to bite the bullet and
start this process?
**********************************************
* 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/15/2000 04:23:42 PM
To: upd%pwg.org@interlock.lexmark.com
cc: (bcc: Don Wright/Lex/Lexmark)
Subject: UPD> command sequences
The more I think about it, the more I am convinced that we need command
sequences in the UPDF file.
It is simply an illusion that a driver uses a certain HP model as a
reference. I really think every clone and every port of a PDL to a specific
model has its proprietary conditions and even improvements, which are not
100% compatible with the target HP model.
From my time in Germany, where we developed drivers for many different
companies, I know that a lot of proprietary command sequences have been
invented in the past and that there are tons of proprietary paper source,
paper size, print media, typeface, symbol set and other parameters.
Only very few models would work with a UPD, that anticipates the correctness
of a print file.
Beside the difficulties to describe binary print files - are there other
reasons to not specify command sequences in a UPDF?
Like marketing or policy reasons?
In case we solve the problems to describe that technically, has any company
any other problem?
Norbert
This archive was generated by hypermail 2b29 : Thu Feb 17 2000 - 10:27:10 EST