# With all due respect, I think any attempts at specifying standard
# print job formatting controls for IPP v1.0 is just TOO much.
# Where do you stop with such specifications? When I read what Keith
# has proposed, it makes me wonder why many other "common" formatting
# features aren't included.
# Developing a standard for transmitting print jobs (and getting related
# status) is one thing, but specifying job formatting facilities would
# appear to be a "tip of the iceberg" sort of thing that can very quickly
# get out of control.
# Am I alone in this opinion?
# ...jay
# ----------------------------------------------------------------------
# -- JK Martin | Email: jkm at underscore.com --
# -- Underscore, Inc. | Voice: (603) 889-7000 --
# -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
# -- Hudson, NH 03015-4915 | Web: http://www.underscore.com --
# ----------------------------------------------------------------------
No, you are not. For an example of the various things that people want
in a text to 'page' display system, get the a2ps UNIX print package -
it has 26 OPTIONS, some of which are truly bizarre... An there is
a new version that handles non-latin languages that is 200Kbytes of executable
code - the mind boggles on what must be going on here. And you plan to put
this into a low cost printer :-) ?
Let me pose some of the problems with incorporating text formatting into a
spooling system.
1. Do you recognize triglyphs? Why not? On what file types?
2. How to you handle the infamous backspace overprint?
And these are just TWO problems that people run into.
Text formatting, I strongly feel, should NOT be part of the specification.
Now you are probably thinking,
"But the HP/LEXMARK/WHATEVER PJL/HCK/XYZ printer control language provides
a way to do this sort of thing, and we want to have a way to hook into
similar/different facilities in the future in a common manner."
Yes, but the text formatting facilities appear to be trying to do is control
'low level page format' in a 'high level' manner. Now I will be the first
to admit that there is some need to allow (say) some way to shift the position
of a printable area on an output device, and perhaps do this on a page dependent
basis. However, the problem becomes incredibly difficult to manage when you want to
do everything at a high level. I see this sort of manipulation as being
'print device/operator' interaction, rather than user interaction.
If you want to get a feel for what I am talking about, think about a high
speed binding copier, that does double sided copies, 4 up, and duplexes them,
and binds them. Now imagine that you simply throw a PostScript file at
this beast, and VOILA! a book appears.
I hesitate to say this, but I think that trying to come up with ALL of the
facilties to specify/control this beast is beyond the scope of us mere mortals...
If you INSIST on providing some sort of information /hints/etc,
once again I recommend a more general approach -
that of have keys sets and values, but not embedded into the specification.
For example, you could have:
PrintJobFormatControl width height this that
PrintJobFormatControl.width 10
PrintJobFormatControl.height 12
PrintJobFormatControl.this 12
PrintJobFormatControl.that 12
Note that this method allows you to indicate what options/attributes
you are going to specify/use, as well as the values. These can
then be interpreted by the appropriate system.
The benefit of this is that systems that do not support/recognize/care
about them can ignore them.
Prof. Patrick Powell
Dept. Electrical and Computer Engineering,
San Diego State University,
San Diego, CA 92182-1309
Office (619) 594-7796; Lab (619) 594-7578 FAX (619) 594-7577
email: papowell at sdsu.edu