From: Michael Sweet <mike@easysw.com>
To: Mark Hamzy <hamzy@us.ibm.com>
Cc: printing-architecture@freestandards.org
Subject: Re: [Printing-architecture] Print scenario
Date: Thu, 12 Jun 2003 15:04:01 -0400 [thread overview]
Message-ID: <3EE8CEA1.4030007@easysw.com> (raw)
In-Reply-To: <OF341B5F3C.677DE0AA-ON86256D41.0072A259-86256D41.00734A57@us.ibm.com>
Mark Hamzy wrote:
>
>
>
> The following is a scenario for an application that wants to print.
> These are the steps that I think the application will perform. What areas
> in this scenario do we need to work on/standardize?
>
> 1 enumerate print queues
> * Use Foomatic for this?
PAPI!
> 2 display job dialog
PAPI!
> 3 receive job properties in standardized format
> * rely on PPD file format for this?
PPD is one source of the information, however we have already
discussed adding a format-neutral mapping of capabilities to
attributes in PAPI so that an application can use PAPI to
tailor the output to a printer, choose job options, etc.
> 4 query page presentation parameters
> - size of page
> - margin information
> - resolution
> - color/monochrome
> - fonts
> * parse PPD file for this information?
See above.
> 5 generate print job
> - postscript/PDF
> - html
> - plain text
> - bitmap file (png, jpg, etc)
> - SVG file
> * linux applications generate postscript files
HTML is not suited to printing due to its use of externally
referenced data like images. XHTML-Print is the PWG equivalent
and supports in-line images, among other things.
The document-format-supported attribute from PAPI can and should
be used by an app to confirm that the printer/printing system can
print the file.
> 6 submit print job with job properties. The queue processor will run some
> transformation. Ex: use Ghostscript to convert postscript to printer
> output.
> * CUPS will accept postscript
CUPS will accept anything in your above list except SVG.
> 7 track print job / display status
> - real-time display?
>
> 8 receive end of job notification
These last two are optional IMHO - job notification is a separate
issue, and while some apps might choose to provide this, it is
more logically something that should be provided in a separate
application/monitor that runs as part of the user's window
environment. Adding job monitoring to every app will just add
bloat in the form of increased memory usage, increased bandwidth
usage between client and server, and increased CPU usage on both
client and server.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Printing Software for UNIX http://www.easysw.com
prev parent reply other threads:[~2003-06-12 19:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-10 20:59 [Printing-architecture] Print scenario Mark Hamzy
2003-06-12 19:04 ` Michael Sweet [this message]
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=3EE8CEA1.4030007@easysw.com \
--to=mike@easysw.com \
--cc=hamzy@us.ibm.com \
--cc=printing-architecture@freestandards.org \
/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.