> > > My point is that if the purpose of the attribute exchange is to avoid
> > > incompatibilities between sender and receiver, the current design isn't
> > > going to work reliably. For example, there is the scenario of a client
> > > sending a PS3 file to a PS2 IPP Printer.
> > You're making the very big assumption that PostScript breaks down cleanly by
> > simple version numbers. But it never has been this way, and hasn't been since
> > Level 2 was defined. Devices are free to implement subsets of level 2 or level
> > 3 and can check the declarations in a document to see if the document uses
> > anything outside of the subset they implement. So a simple version number just
> > doesn't work very well for PostScript.
> Wouldn't it be better than nothing?
It would probably be worse, given the number of partial implementations of
PostScript levels out there, many of which incorrectly claim to support Level 2
or Level 3 or whatever. And you're also assuming that only alternative to the
parameter is "nothing", and that's just not so -- existing software understands
how to read DSC information and dispatch appropriately based on it. There's
ample evidence that the fine grained feature model is practical.
> Can't we find something between blind
> trial-and-error and requiring every client to have a priori knowledge of
> every existing printer-make-and-model?
Of course we can. We've already designed it. All you have to do is use it.
> But don't Media feature tags describe physical characteristics, rather than
> how those characteristics are described in a PDL?
Nope. They do a lot more than describe the characteristics of a document. They
can also be used to describe the capabilities of a device.
> Couldn't a given Mime
> media feature have a different expression in different versions of PS or
> PCL?
Some features are generic cross-format stuff but others are specific to a
particular format. For example, it would be entirely reasonable to have a "LZ
compression" feature tag specific to application/postscript. And supposing for
a moment that there's similar functionality in PCL, it would not be reasonable
to use the same feature tag since a given printer might implement this with one
format and not the other.
There's even a "feature calculus" you can use to express more complex
relationships. For example, I believe it would be possible to write a feature
expression that describes a printer that supports B&W PCL and Postscript but
color is only available in PCL.
It seems logical to use generic media feature tags whenever possible, of
course.
> [I admit I don't know much about media feature tags. Can you point
> me to some references?]
The RFC index lists many RFCs on media features.
> The thing is, these would have to be generally accepted standards in order
> to be useful for interop. It won't do any good for me to define my own new
> tags.
That's why there's a registration procedure.
Ned
This archive was generated by hypermail 2b29 : Mon Mar 12 2001 - 16:24:39 EST