All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Sweet <mike@easysw.com>
To: Pete Zannucci <pzaan@us.ibm.com>
Cc: printing-architecture@freestandards.org
Subject: Re: [Printing-architecture] RE:Scenarios for using the various Open Print API
Date: Tue, 03 Dec 2002 15:10:58 -0500	[thread overview]
Message-ID: <3DED0FD2.1050703@easysw.com> (raw)
In-Reply-To: OF63108296.468827EB-ON85256C84.0058D5DF@pok.ibm.com

Pete Zannucci wrote:
> ...
> We need to come to a consensus on what additional types
> of information an application might need to be able to
> generate a job to it's satisfaction.  We have discussed
> how to provide printable area and margin information.
> That is a start.  Their may be other things that some apps.
> would like to know about a device and that should be added
> as a possible separate api (get all the pertinent info.
> back from a device on what it supports) or could possibly
> be added as an additional grouping of attributes.

I'm not sure if the current PWG color attributes cover this,
but providing the native colorspace as well as any profile
information for the printer/driver might be useful.  Right
now all IPP provides is a "color-supported" boolean attribute,
but knowing if the destination device/driver supports true
CMYK/N-color rendering (typically used in a production
workflow with apps like Photoshop, etc.) could be useful.

> There are two sides of adding additional attributes that
> worry me.
>       1. No protocol support for the attributes so
>          current devices will not be able to handle or
>          provide the information back on a query.

Assuming that PAPI is providing the information, it can
supplement the attributes as needed.

>       2. Since there is no support there will need to be
>          an intermediary such as a ppd or a driver when
>          using such a device.

I would say that this will be the case for the forseable
future, and unless printer manufacturers suddenly have a
cheap chipset they can put in their low-end devices, such
support will only ever be available in high-end devices.

In any case, PAPI can handle the low-level details and
provide the app with a common, consistent interface, right?

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike@easysw.com
Printing Software for UNIX                       http://www.easysw.com



  reply	other threads:[~2002-12-03 20:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-03 16:51 [Printing-architecture] RE:Scenarios for using the various Open Print API Pete Zannucci
2002-12-03 20:10 ` Michael Sweet [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-01-16 20:31 Claudia Alimpich
2002-11-21 19:09 Claudia Alimpich
2002-11-21 19:29 ` Michael Sweet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3DED0FD2.1050703@easysw.com \
    --to=mike@easysw.com \
    --cc=printing-architecture@freestandards.org \
    --cc=pzaan@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.