IFX Mail Archive: RE: IFX> RE: Fax processing confirmation;

IFX Mail Archive: RE: IFX> RE: Fax processing confirmation;

RE: IFX> RE: Fax processing confirmation; document-formats

From: ned.freed@mrochek.com
Date: Mon Mar 12 2001 - 16:10:24 EST

  • Next message: Carl Kugler: "RE: IFX> RE: Fax processing confirmation; document-formats"

    > > > 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

    > [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.


    This archive was generated by hypermail 2b29 : Mon Mar 12 2001 - 16:24:39 EST