IPP Mail Archive: IPP> BOUNCE ipp@pwg.org: Non-member sub

IPP Mail Archive: IPP> BOUNCE ipp@pwg.org: Non-member sub

IPP> BOUNCE ipp@pwg.org: Non-member submission from ["TAYLOR,BOB (HP-Vancouver,ex1)" <bobt@hp.com>]

From: Danny.M.Brennan@kp.org
Date: Thu Jun 26 2003 - 19:44:14 EDT

  • Next message: Hastings, Tom N: "RE: IPP> [jobx] - The "color-effects-type" Job Template attribute s [corrected URLs]"

    Hi Tom,

    To me, #2 is the issue to really focus on: is this really two semantic
    concepts,
    or one? If any of these values are semantically really just additional
    enumerations for
    print-quality, I'd much rather we fix this than do the split it.

    As for #2, what "semantic meaning would be lost or mixed" if we just
    extended
    the enumeration for print-quality? Although you can, by having these as
    two attributes, specify "draft" and "photo" - in practice, this is
    virtually never done: "photo" is usually specified in one of a couple
    ways:
    - my media type (i.e., photo-glossy paper model #C239847A)
    - PrintQuality (quality = Photo4800DPI) - i.e., another print-quality
    enumeration
    If it's something other than one of these, it's usually what we call in
    PSI
    capabilities a "macro feature" - i.e., it's not a real attribute sent to
    the
    device, but a feature defined as a macro combination of other features -
    which
    I don't think is a concept currently supported by IPP.

    Fundamentally, "refines the value specified by the print-quality" seems
    like
    a
    weak semantic differentiation, and I believe it is inconsistent with how
    extensions
    to the print-quality concept have been applied in at least the inkjet
    segment of
    the market.

    thanks,

    bt

    > -----Original Message-----
    > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    > Sent: Wednesday, June 25, 2003 1:08 PM
    > To: printing-driver@freestandards.org; Claudia Alimpich; ipp@pwg.org
    > Cc: printing-jobticket@freestandards.org
    > Subject: RE: [printing-driver] RE: [printing-jobticket]
    > Proposal to add ne w IPP print-optimize attribute
    >
    >
    > Bob,
    >
    > I think that the proposal to add "print-optimize" solves two
    > separate problems, not just a single problem of adding some values:
    >
    > 1. Doesn't invalidate the semantics of "print-quality" (which
    > we are treating in the same way as an enumeration in JDF,
    > i.e., a closed end list, in which these are the only values
    > that can be supported: 'draft', 'normal', and 'high').
    >
    > 2. The Optimize mechanism isn't really just additional print
    > quality values, but is more specific as to what to optimize.
    > Therefore, it would be wrong just to add the proposed new
    > values to "print-quality" as you suggest. Semantics meaning
    > would be lost or mixed. (Also the "print-optimize" attribute
    > is like the JDF XxxDetails which is an extensible NMTOKEN
    > value, not an enumeration.)
    >
    > Also note that "print-quality" may be used in combination
    > with "print-optimize". So you can have 'draft', 'normal' or
    > 'high' optimization of, say, 'photo'.
    >
    > ISSUE: We didn't say that a Printer that supports
    > "print-optimize" MUST support "print-quality" as well.
    > Should we, since the definition of "print-optimize" is that
    > it "refines the value supplied (or defaulted) in "print-quality")?
    >
    > Also this isn't a precedent that we can't add values to an
    > existing attribute in IPP or the Semantic Model. It just
    > seems that for this one "print-quality" attribute both
    > reasons support not adding new values to the existing attribute.
    >
    > Tom
    >
    > -----Original Message-----
    > From: TAYLOR,BOB (HP-Vancouver,ex1) [mailto:bobt@hp.com]
    > Sent: Tuesday, June 24, 2003 17:39
    > To: Claudia Alimpich; ipp@pwg.org;
    > printing-jobticket@freestandards.org;
    > printing-driver@freestandards.org
    > Subject: [printing-driver] RE: [printing-jobticket] Proposal
    > to add new IPP print-optimize a ttribute
    >
    >
    > I understand the desire to avoid violating the semantics of
    > the IPP attribute - but adding these enumerations to
    > print-quality does not feel as objectionable to me as
    > splitting a single semantic concept into two different
    > attributes. If this is the precedent we take for extending
    > the semantic model, I'm worried that we'll end up with an
    > increasingly confusing and complex. I would rather we take
    > the minor hit and fix the high & draft definitions in the
    > semantic model than create another ~equivalent attribute with
    > a whole bunch of special semantic rules (e.g. - what should
    > the service do if print-quality=high and print-optimize=save-toner?).
    >
    > bt
    >
    > ---------------------------------------------------
    > Bob Taylor
    > Senior Architect
    > IPG Strategic Technology Development
    > Hewlett-Packard Co.
    > mailto:bobt@hp.com
    > phone: 360.212.2625/T212.2625
    > fax: 208.730-5111
    > ---------------------------------------------------
    >
    > > -----Original Message-----
    > > From: Claudia Alimpich [mailto:alimpich@us.ibm.com]
    > > Sent: Tuesday, June 24, 2003 5:27 PM
    > > To: ipp@pwg.org; printing-jobticket@freestandards.org;
    > > printing-driver@freestandards.org
    > > Subject: [printing-jobticket] Proposal to add new IPP
    > > print-optimize attribute
    > >
    > >
    > >
    > >
    > >
    > >
    > > Last Tuesday during the PWG/FSG meeting in Portland we had a
    > > discussion about the IPP print-quality attribute and FSG's
    > > desire to add two new values, "economy" and "fine", where
    > > "economy" is lower than "draft" and "fine" is higher than
    > > "high". After some discussion we all pretty much decided that
    > > it is not possible to add these new values to the already
    > > existing "draft", "normal", and "high" values because of the
    > > current definitions of the existing values (high is defined
    > > as the highest quality and draft is defined as the lowest
    > > quality). It also seemed like what FSG wanted was a way to
    > > specify print optimization and not additional levels of
    > print quality.
    > >
    > > The FSG working group met today, and based on the input from
    > > last Tuesday's meeting, we would like to propose the addition
    > > of a new attribute, called print-optimize, that is defined
    > as follows:
    > >
    > > print-optimize (type2 keyword)
    > >
    > > This attribute refines the value specified by the
    > print-quality
    > > attribute.
    > >
    > > The standard keyword values are:
    > >
    > > 'image': optimize for image clarity
    > > 'photo': optimize for photo clarity
    > > 'text': optimize for text clarity
    > > 'text-and-image': optimize for both text and image clarity
    > > 'save-toner': optimize for minimal toner usage
    > > 'speed': optimize for printing speed
    > >
    > > We would appreciate your feedback on this proposal including
    > > suggestions for additional values.
    > >
    > > If this proposal looks good, we would like to propose that it
    > > be included in the JobX Spec. If the print-optimize attribute
    > > is approved by PWG by the end of August, then we can propose
    > > that it be added to the JDF 1.2 Spec that is being finalized
    > > in early September.
    > >
    > > Thank you for your time and feedback.
    > > Claudia Alimpich
    > > IBM Printing Systems Division
    > > Boulder CO
    > > 303-924-4418
    > > alimpich@us.ibm.com
    > >
    > >
    > > _______________________________________________
    > > printing-jobticket mailing list printing-jobticket@freestandards.org
    > > http://freestandards.org/mailman/listinfo/printing-jobticket
    > >
    >
    > _______________________________________________
    > printing-driver mailing list
    > printing-driver@freestandards.org
    > http://freestandards.org/mailman/listinfo/prin> ting-driver
    >
    >
    > _______________________________________________
    >
    > printing-driver mailing list
    > printing-driver@freestandards.org
    > http://freestandards.org/mailman/listinfo/prin> ting-driver
    >



    This archive was generated by hypermail 2b29 : Thu Jun 26 2003 - 19:49:18 EDT