All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Sweet <mike@easysw.com>
To: Charles Hemstreet <charles_at_hp@hotmail.com>
Cc: printing-architecture@freestandards.org
Subject: Re: [Printing-architecture] Architecture meeting agenda 20030612. . .
Date: Thu, 12 Jun 2003 14:55:34 -0400	[thread overview]
Message-ID: <3EE8CCA6.6070700@easysw.com> (raw)
In-Reply-To: <Sea2-F67CjOuF1Qp4hZ000315aa@hotmail.com>

Charles Hemstreet wrote:
> New meeting time for our architecture teleconference:
> ...
> ftp://ftp.pwg.org/pub/pwg/fsg/architecture/arch1-6-12-03.jpg
> 
> ftp://ftp.pwg.org/pub/pwg/fsg/architecture/arch2-6-12-03.jpg

As I can't attend any of the teleconferences due to scheduling
conflicts, here are some comments on the current diagrams:

     1. The diagram separates the bidi handling from the driver,
        which won't work for several consumer inkjet devices that
        I personally know of.  Either remove this box or put it
        in-line so that the output from the printer driver can be
        massaged by the vendor filter.

        Example: the EPSON inkjet printers use a special packet
        mode via USB or parallel port to provide continuous status
        updates; this special handling can be put in a "monitor"
        filter in-line between the driver filter and backend to
        packetize the output and provide ink status, etc. as the
        job is printed.  If you implement it the way the diagram
        is, then the driver has to do all of the device-specific
        stuff (and that device-specific stuff varies based upon
        the interface, and it isn't always possible to automatically
        determine the right mode - it needs to be configurable)
        and the back-channel filter somehow needs to be able to
        send as well as recieve data without trashing the driver's
        output.

     2. There absolutely cannot be a direct link between a device
        backend or vendor filter and a vendor-supplied UI.  Such
        an interface opens up major security issues not to mention
        that it likely won't work in a networked environment and
        will kill any interoperability.

        Any driver/filter communications should be in the form of
        state information that is communicated to the scheduler,
        which can then provide the information to apps in a
        consistent way.  Vendors can provide UIs that query this
        information, and the *same* interface can be used by all
        vendors.

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





  reply	other threads:[~2003-06-12 18:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-12 17:24 [Printing-architecture] Architecture meeting agenda 20030612. . Charles Hemstreet
2003-06-12 18:55 ` Michael Sweet [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-06-13 13:41 Pete Zannucci

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=3EE8CCA6.6070700@easysw.com \
    --to=mike@easysw.com \
    --cc=charles_at_hp@hotmail.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.