[MFD] Question on Resolution Versus Qaulity

[MFD] Question on Resolution Versus Qaulity

Ira McDonald blueroofmusic at gmail.com
Thu Feb 2 16:53:38 UTC 2012


Hi Glen,

I see the logic of your comments.

But IPP/2.0 Second Edition *did* specifically resolve this
"quality" versus "resolution" question based on quite a lot
of mailing list and face-to-face discussion.  This is stated
in on page 21, section 6.2, item 8 of PWG 5100.12.

So a conforming IPP Printer has to behave accordingly.

We can add more discussion in IPP JPS3, if that seems
appropriate, but we really can't reverse the IPP/2.0 SE,
because that would not be backward compatible.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Thu, Feb 2, 2012 at 10:06 AM, Petrie, Glen <glen.petrie at eitc.epson.com>wrote:

>  Mike,****
>
> ** **
>
> Interesting but I still believe my conclusions support both a simple and
> sophisticated user-centric model.  A simple user-centric model will always
> use the “quality” setting and, for added “control”, will set “content type”
> to get the desired output.   Sophisticated users will want to control the
> finer details and, thus, may want a specific resolution.   ****
>
> ** **
>
> As to “draft” operations or any other quality setting operations:  in
> general, no print vendor is going to use simpler/faster dithers or
> color-transform or not perform print row interleaving, if it reduces the
> overall printed quality of the output simply because the user set quality
> setting to draft/normal/high in a Print Client.   There would be
> insignificant amount of processing required; no need to support multiple
> dither/color transforms routines; and an unnoticeable amount of additional
> (if any) overall print time.   If a user specifies a resolution versus
> quality; then, saving ink was not his/her intent; he/she wants a specific
> resolution for his/her specific reason.  While bi-directional versus
> uni-directional printing are affected by quality settings; print service
> internal selection (not user set) would also use content-type (for example;
> high-quality text (bi) versus high-quality photo(uni)) which, of course, bi
> versus uni, can also be done as a function of resolution and the
> content-type.****
>
> ** **
>
> The constraint is solved by;****
>
> ** **
>
>    1. The content-type MUST be set;  ****
>       1. The default could be “text and graphic”****
>    2. If user sets resolution; then the Print Services uses this
>    resolution along with content-type.  The Print Service will ignore any
>    quality-setting and set any internal processing based on resolution and
>    content-type only.  ****
>       1. If the resolution set is not supported; then return an error.
>       (How this could occur from a print client that received printer capability
>       data is unknown but just in-case the user is allowed to “type” in any
>       resolution they want!) ****
>    3. If user set quality but not resolution, then****
>       1. The Print Service uses content-type and quality-setting to
>       determine a resolution and internal processing.****
>
> ** **
>
> IMHO, the user must always be in control.  Setting resolution is more
> specific than setting quality, since quality is qualitative versus
> quantitative; thus, if a user sets a resolution; then that what should be
> done. ****
>
> ** **
>
> I think we will have to agree to disagree and simply move on!****
>
> ** **
>
> glen****
>
> ** **
>
> ** **
>  ------------------------------
>
> *From:* Michael Sweet [mailto:msweet at apple.com]
> *Sent:* Wednesday, February 01, 2012 5:00 PM
>
> *To:* Petrie, Glen
> *Cc:* mfd at pwg.org
> *Subject:* Re: [MFD] Question on Resolution Versus Qaulity
> ****
>
>  ** **
>
> Glen,****
>
> ** **
>
> On Feb 1, 2012, at 3:45 PM, Petrie, Glen wrote:****
>
>   Conceptually there is no reason a printer could not support a draft
> mode for multiple resolutions (and this is in fact the case in CUPS/Mac OS
> X), so preventing both from being specified will do a disservice to the
> user and printer/driver.********
>
> ** ******
>
> [gwp] So if we have “draft” at 75, 150, 300; and the user can select both
> “draft” and 300; then what is the value of “draft” to the Print Service
> since the Print Service was told to print at 300 dpi.****
>
>  ** **
>
> "Draft" might select (for example) bidirectional printing on an inkjet
> with no interleaving of dot rows. It could also use a simpler/faster
> dithering algorithm,  simpler/faster color transform, use less inks (i.e.
> just CMYK instead of CMYKcmk), etc.****
>
> ** **
>
>   [gwp] Users are more likely to select “quality” equals “draft” and
> “contentOptimize” equals “photo” and not a dpi (ops: resolution).   If a
> user ‘really understands’ the Print Service performance for differing dpi’s
> (again ops: resolution’s); then “quality” should never win because the user
> knows exactly what dpi they want!****
>
>  ** **
>
> Users do not know how quality and resolution interact, and in the absence
> of the JPS3 mechanisms for doing constraint resolution there is no way for
> the client to know either.****
>
>  ****
>
>   Quality != Resolution.  They may be related, and there may in fact be
> constraints that cause a particular combination to conflict, but they are
> not mutually exclusive and express separate intent.  The IPP/2.0
> recommendation to prefer Quality over Resolution when there is a conflict
> is a pragmatic approach to automatic conflict resolution.********
>
> ** ******
>
> [gwp] Print-Resolution is a function of both Quality AND
> Content-Optimize.   Any printer today can determine a resolution from these
> two values.  If a user specifies a resolution then the Print Service should
> use the resolution (resolution is always the winner) since the user is
> stating they want the specified resolution that gives them a desired
> quality for the content!****
>
>  ** **
>
> and if that resolution is supported by the printer then by all means it
> should use it! But if not, the printer should let the client know it can't
> use that resolution and  use the closest resolution instead...****
>
>
>
> ****
>
> [gwp] The conclusion is then****
> ******
>
>  ******
>
>    1. Specified Resolution wins over “Quality”  - always, since the User
>    specified ‘use this resolution”.****
>
>   ** **
>
> The user specified "use this quality". One has to win, and IMHO (and based
> on what we agreed to and approved in IPP/2.0 SE) Quality wins over
> Resolution.****
>
> ** **
>
> ****
>
>    1. ** **
>    2. Content-Optimize MUST be required – for a printer to properly
>    determine the correct resolution when resolution is not specified.****
>
>   ** **
>
> That's what defaults are for...****
>
>
>
> ****
> ****
>
>    1. ** **
>    2. Print-Quality  is [Quality (-Intent) + Content-Optimize ] or [
>    Resolution] but not both.********
>
>   ** **
>
> Again, these elements are related but not mutually exclusive.****
>
> ** **
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair****
>
> ** **
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
> _______________________________________________
> mfd mailing list
> mfd at pwg.org
> https://www.pwg.org/mailman/listinfo/mfd
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20120202/7430f392/attachment-0002.html>


More information about the mfd mailing list