From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BEBF.CB8AC82D" Date: Thu, 16 Apr 2009 11:21:21 -0700 Message-ID: From: "Petrie, Glen" Subject: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Till Kamppeter , peter sikking Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BEBF.CB8AC82D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Have you ever considered creating/defining a Common Status/Monitoring Dialog. CUPS may have something already but does it support multi-function devices sub-units like fax, scan, memory card, etc and can it provide the status/monitoring information on a sub-unit by sub-unit basis or as a roll-up for the entire MFD or both???? =20 glen ------_=_NextPart_001_01C9BEBF.CB8AC82D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Have you ever considered creating/defining a Common Status/Monitoring Dialog.   CUPS may have something already = but does it support multi-function devices sub-units like fax, scan, memory card, = etc and can it provide the status/monitoring information on a sub-unit by = sub-unit basis or as a roll-up for the entire MFD or = both????

 

glen

------_=_NextPart_001_01C9BEBF.CB8AC82D-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BEDA.EA672465" Date: Thu, 16 Apr 2009 14:35:29 -0700 Message-ID: References: <4B3C1712-1367-404C-B77B-E7C5E5110C28@apple.com> From: "Petrie, Glen" Subject: Re: [Printing-architecture] [Printing-summit] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Sweet Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org, Till Kamppeter This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BEDA.EA672465 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the inputs Michael. This provides some seeds for the implementation details. I am hoping Peter will provide similar comment for the look-and-feel of the interface. =20 Glen =20 =20 ________________________________ From: Michael Sweet [mailto:msweet@apple.com]=20 Sent: Thursday, April 16, 2009 2:18 PM To: Petrie, Glen Cc: Till Kamppeter; peter sikking; printing-architecture@lists.linux-foundation.org; printing-summit@lists.linux-foundation.org Subject: Re: [Printing-summit] Another Common Dialog =20 Due to numerous practical issues, most MFPs that support fax and print have to use two separate print queues; detecting this from the print dialog or monitoring application is fairly easy (compare device URIs and capability bits, merge queues that differ only by capabilities), and supporting this at the OS level is essential (and then you can really make things easy by creating both queues, "foo" and "foo_fax"...) =20 Scanning functionality is managed separately from CUPS at the OS level (usually SANE + a USB driver) but can be merged in the UI as long as the OS provides the necessary hooks. =20 Supporting memory cards (presumably exposed as USB mass storage or some sort of network share) is also possible, again as long as the OS has the necessary hooks. =20 On Apr 16, 2009, at 11:21 AM, Petrie, Glen wrote: Have you ever considered creating/defining a Common Status/Monitoring Dialog. CUPS may have something already but does it support multi-function devices sub-units like fax, scan, memory card, etc and can it provide the status/monitoring information on a sub-unit by sub-unit basis or as a roll-up for the entire MFD or both???? =20 glen _______________________________________________ Printing-summit mailing list Printing-summit@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/printing-summit =20 ________________________________________ Michael R Sweet, Senior Printing System Engineer =20 ------_=_NextPart_001_01C9BEDA.EA672465 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the inputs Michael. =  This provides some seeds for the implementation details.  I am hoping Peter will = provide similar comment for the look-and-feel of the = interface.

 

Glen

 

 

From: = Michael Sweet [mailto:msweet@apple.com]
Sent: Thursday, April 16, = 2009 2:18 PM
To: Petrie, Glen
Cc: Till Kamppeter; peter = sikking; printing-architecture@lists.linux-foundation.org; = printing-summit@lists.linux-foundation.org
Subject: Re: = [Printing-summit] Another Common Dialog

 

Due to numerous practical issues, most MFPs that support fax and = print have to use two separate print queues; detecting this from the print = dialog or monitoring application is fairly easy (compare device URIs and = capability bits, merge queues that differ only by capabilities), and supporting this at = the OS level is essential (and then you can really make things easy by creating = both queues, "foo" and = "foo_fax"...)

 

Scanning functionality is managed separately from CUPS at the OS = level (usually SANE + a USB driver) but can be merged in the UI as long as the = OS provides the necessary hooks.

 

Supporting memory cards (presumably exposed as USB mass storage = or some sort of network share) is also possible, again as long as the OS has the necessary hooks.

 

On Apr 16, 2009, at 11:21 AM, Petrie, Glen wrote:



Have you ever considered creating/defining a Common Status/Monitoring Dialog.   CUPS = may have something already but does it support multi-function devices sub-units = like fax, scan, memory card, etc and can it provide the status/monitoring information on a sub-unit by sub-unit basis or as a roll-up for the = entire MFD or both????

 

glen

___________________________________= ____________
Printing-summit mailing list
Printing-summi= t@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/printing-summit

 

_____________= ___________________________

Michael R = Sweet, Senior Printing System Engineer

 

------_=_NextPart_001_01C9BEDA.EA672465-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <49E7A822.7030703@gmail.com> Date: Thu, 16 Apr 2009 23:50:26 +0200 From: Till Kamppeter MIME-Version: 1.0 References: <4B3C1712-1367-404C-B77B-E7C5E5110C28@apple.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Printing-architecture] [Printing-summit] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Petrie, Glen" Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org, Michael Sweet Petrie, Glen wrote: > Thanks for the inputs Michael. This provides some seeds for the > implementation details. I am hoping Peter will provide similar comment > for the look-and-feel of the interface. To see which devices (scanners, card readers, printers) belong together as one MF unit, one only needs to look at the output of "lsusb -vvv" or "lshal". Till From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <49E8CCB8.4000201@gmail.com> Date: Fri, 17 Apr 2009 20:38:48 +0200 From: Till Kamppeter MIME-Version: 1.0 References: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> In-Reply-To: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: peter sikking Cc: "Petrie, Glen" , printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org peter sikking wrote: > Glen, > >> Have you ever considered creating/defining a Common Status/Monitoring >> Dialog. > > for printing: sure that is the next project, together with > printer installation. > >> CUPS may have something already but does it support multi-function >> devices sub-units like fax, scan, memory card, etc and can it provide >> the status/monitoring information on a sub-unit by sub-unit basis or >> as a roll-up for the entire MFD or both???? > > for users printing, faxing, scanning, memory card reading are > totally unrelated activities. so it follows that faxing, scanning, > memory card reading is never going to be seen in a printing dialog > and also not in a status/monitoring dialog. > I would say so, too. The scanner should appear in scanning applications, memory cards should simply get auto-mounted and appear on the desktop (at least for locally connected devices, for network devices they should appear when scanning for file system shares in the network). Sending faxes should be done by a print queue where the printing dialog shows an appropriate widget for the fax number. A dialog to put these functions together is not needed. It can even get counter-intuitive if an MF device and a scan-only device is connected to the same machine. Till From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> From: peter sikking In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 20:21:27 +0200 References: Subject: Re: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Petrie, Glen" Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org, Till Kamppeter Glen, > Have you ever considered creating/defining a Common Status/ > Monitoring Dialog. for printing: sure that is the next project, together with printer installation. > CUPS may have something already but does it support multi-function > devices sub-units like fax, scan, memory card, etc and can it > provide the status/monitoring information on a sub-unit by sub-unit > basis or as a roll-up for the entire MFD or both???? for users printing, faxing, scanning, memory card reading are totally unrelated activities. so it follows that faxing, scanning, memory card reading is never going to be seen in a printing dialog and also not in a status/monitoring dialog. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <484F18A6-7ADF-4878-AD2F-2178B655199D@mmiworks.net> From: peter sikking In-Reply-To: <49E8CCB8.4000201@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 20:54:28 +0200 References: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> <49E8CCB8.4000201@gmail.com> Subject: Re: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Till Kamppeter Cc: "Petrie, Glen" , printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org Till wrote: > peter sikking wrote: >> for users printing, faxing, scanning, memory card reading are >> totally unrelated activities. > > I would say so, too. it is not just a good idea, it is the truth. > Sending faxes should be done by a print queue where the printing > dialog shows an appropriate widget for the fax number. even that is mind-boggling incomprehensible for users. I will fight tooth and nail to avoid that solution. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 11:58:51 -0700 Message-ID: References: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> <49E8CCB8.4000201@gmail.com> <484F18A6-7ADF-4878-AD2F-2178B655199D@mmiworks.net> From: "Petrie, Glen" Subject: Re: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: peter sikking , Till Kamppeter Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org Not if my function is to manage the MFD.... but memory are on the priority right now. > -----Original Message----- > From: peter sikking [mailto:peter@mmiworks.net] > Sent: Friday, April 17, 2009 11:54 AM > To: Till Kamppeter > Cc: Petrie, Glen; printing-architecture@lists.linux-foundation.org; > printing-summit@lists.linux-foundation.org > Subject: Re: Another Common Dialog >=20 > Till wrote: >=20 > > peter sikking wrote: > >> for users printing, faxing, scanning, memory card reading are > >> totally unrelated activities. > > > > I would say so, too. >=20 > it is not just a good idea, it is the truth. >=20 > > Sending faxes should be done by a print queue where the printing > > dialog shows an appropriate widget for the fax number. >=20 > even that is mind-boggling incomprehensible for users. > I will fight tooth and nail to avoid that solution. >=20 > --ps >=20 > founder + principal interaction architect > man + machine interface works >=20 > http://mmiworks.net/blog : on interaction architecture >=20 >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Hal V. Engel" Date: Fri, 17 Apr 2009 12:32:16 -0700 References: <49E8CCB8.4000201@gmail.com> <484F18A6-7ADF-4878-AD2F-2178B655199D@mmiworks.net> In-Reply-To: <484F18A6-7ADF-4878-AD2F-2178B655199D@mmiworks.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904171232.16547.hvengel@astound.net> Subject: Re: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: printing-architecture@lists.linux-foundation.org On Friday 17 April 2009 11:54:28 am peter sikking wrote: > Till wrote: > > peter sikking wrote: > >> for users printing, faxing, scanning, memory card reading are > >> totally unrelated activities. > > > > I would say so, too. > > it is not just a good idea, it is the truth. > > > Sending faxes should be done by a print queue where the printing > > dialog shows an appropriate widget for the fax number. > > even that is mind-boggling incomprehensible for users. > I will fight tooth and nail to avoid that solution. > I also agree with Peter here. A user sending a fax expects to see fax specific dialogs. Till however is correct that hidden below that fax specific UI could be a print queue but the user should NEVER be aware of how it is actually implemented. Hal From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <49E8ECCF.8050700@gmail.com> Date: Fri, 17 Apr 2009 22:55:43 +0200 From: Till Kamppeter MIME-Version: 1.0 References: <49E8CCB8.4000201@gmail.com> <484F18A6-7ADF-4878-AD2F-2178B655199D@mmiworks.net> <200904171232.16547.hvengel@astound.net> In-Reply-To: <200904171232.16547.hvengel@astound.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Hal V. Engel" Cc: printing-architecture@lists.linux-foundation.org Hal V. Engel wrote: > On Friday 17 April 2009 11:54:28 am peter sikking wrote: >> Till wrote: >>> peter sikking wrote: >>>> for users printing, faxing, scanning, memory card reading are >>>> totally unrelated activities. >>> I would say so, too. >> it is not just a good idea, it is the truth. >> >>> Sending faxes should be done by a print queue where the printing >>> dialog shows an appropriate widget for the fax number. >> even that is mind-boggling incomprehensible for users. >> I will fight tooth and nail to avoid that solution. >> > > I also agree with Peter here. A user sending a fax expects to see fax > specific dialogs. Till however is correct that hidden below that fax specific > UI could be a print queue but the user should NEVER be aware of how it is > actually implemented. So fax should look like this: On the implementation side we have print queues for faxes, the PPD files of fax queues contain the following CUPS extension: *cupsFax: true (see http://www.cups.org/documentation.php/doc-1.4/spec-ppd.html). This allows distinguishing print queues and fax queues. Applications are supposed to have a "Print ..." and a "Fax ..." entry. If a queue type (printing, faxing) is not present, the corresponding menu entry gets grayed out. Clicking "Print ..." gives the printing dialog as Peter has designed it, but only print queues (and no fax queues) are listed. Clicking "Fax ..." gives a dialog (slightly) different to Peter's printing dialog, for example with an additional "zone" with one or more widgets to choose the fax destination (by typing in, calling address book, ...) and only the fax queues listed. The exact design for an ideal fax dialog can also be left to OpenPrinting. WDYT? Till From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: From: peter sikking In-Reply-To: <200904172344.n3HNivf6025718@dsl092-065-009.bos1.dsl.speakeasy.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 18 Apr 2009 11:39:24 +0200 References: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> <49E8CCB8.4000201@gmail.com> <484F18A6-7ADF-4878-AD2F-2178B655199D@mmiworks.net> <200904172344.n3HNivf6025718@dsl092-065-009.bos1.dsl.speakeasy.net> Subject: Re: [Printing-architecture] [Printing-summit] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Robert Krawitz Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org, till.kamppeter@gmail.com Robert wrote: >>> for users printing, faxing, scanning, memory card reading are >>> totally unrelated activities. >> >> I would say so, too. > > it is not just a good idea, it is the truth. > > Other than that with all-in-ones they're all physically in the same > box (and the manufacturers sell them that way). as long as you remember that it is unrelated user tasks packed into one physical box, then I am happy. > We get quite a few > complaints about the scanner not functioning in multi-function > devices; users appear to expect that these devices be handled as a > single coherent unit. I think the complaint is that the scanner is not working. they would love if you could make that work for them. do you really think any of them would expect a scan workflow that goes through the print dialog? --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: From: peter sikking In-Reply-To: <49E8ECCF.8050700@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 18 Apr 2009 11:57:06 +0200 References: <49E8CCB8.4000201@gmail.com> <484F18A6-7ADF-4878-AD2F-2178B655199D@mmiworks.net> <200904171232.16547.hvengel@astound.net> <49E8ECCF.8050700@gmail.com> Subject: Re: [Printing-architecture] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Till Kamppeter Cc: printing-architecture@lists.linux-foundation.org Till wrote: > Hal V. Engel wrote: >> On Friday 17 April 2009 11:54:28 am peter sikking wrote: >>> Till wrote: >>>> Sending faxes should be done by a print queue where the printing >>>> dialog shows an appropriate widget for the fax number. >>> even that is mind-boggling incomprehensible for users. >>> I will fight tooth and nail to avoid that solution. >>> >> >> I also agree with Peter here. A user sending a fax expects to see >> fax >> specific dialogs. Till however is correct that hidden below that >> fax specific >> UI could be a print queue but the user should NEVER be aware of how >> it is >> actually implemented. > > > So fax should look like this: On the implementation side we have print > queues for faxes, the PPD files of fax queues contain the following > CUPS > extension: > > *cupsFax: true > > (see http://www.cups.org/documentation.php/doc-1.4/spec-ppd.html). > This > allows distinguishing print queues and fax queues. Applications are > supposed to have a "Print ..." and a "Fax ..." entry. yes. this is the key to making things normal for users. > If a queue type > (printing, faxing) is not present, the corresponding menu entry gets > grayed out. both will need access installation workflow (the next project...) > Clicking "Print ..." gives the printing dialog as Peter has > designed it, but only print queues (and no fax queues) are listed. yes. excellent. > Clicking "Fax ..." gives a dialog (slightly) different to Peter's > printing dialog, for example with an additional "zone" with one or > more > widgets to choose the fax destination (by typing in, calling address > book, ...) and only the fax queues listed. The exact design for an > ideal > fax dialog can also be left to OpenPrinting. WDYT? just like I said for the pdf export dialog: it will be a cousin of the print dialog, not a twin brother. we can recycle a lot of good UI concepts and code for these dialogs, but sound UI practice demands that the design of each is optimised for the particular activity. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: From: peter sikking In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 21 Apr 2009 11:09:19 +0200 References: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> Subject: Re: [Printing-architecture] [Printing-summit] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Johannes Meixner Cc: "Petrie, Glen" , printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org Johannes Meixner wrote: > On Apr 17 20:21 peter sikking wrote (shortened): >> for users printing, faxing, scanning, memory card reading are >> totally unrelated activities. so it follows that faxing, scanning, >> memory card reading is never going to be seen in a printing dialog >> and also not in a status/monitoring dialog. > > Yes and no - it depends - as always - on the details what > exactly is meant. > > In contrast to separated stand-alone devices where printing, > faxing, scanning, memory card reading works independent > of each other, all-in-one devices introduce hardware-dependent > constraints. > > For example when the all-in-one device is busy with > memory card reading, nothing else might be possible > so that the device status/monitoring in all dialogs > (i.e. also in the printing dialog) must display that > the device is busy with memory card reading. > > The crucial point here is whether or not status/monitoring > is meant regarding the actual hardware device. > > In contrast e.g. a print queue status/monitoring belongs > of course only to the printing dialog. interesting complication. can this lead to the situation that when the print dialog comes up (or users Just Print) that the printer (part) actually looks unavailable/not there to the desktop computer? --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <29BE1E67-4A6A-40D7-86EC-A21E518E756A@mmiworks.net> From: peter sikking In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 21 Apr 2009 11:14:36 +0200 References: <1F40945E-38C1-4ADC-B54C-DEF213F8A625@mmiworks.net> Subject: Re: [Printing-architecture] [Printing-summit] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Johannes Meixner Cc: "Petrie, Glen" , printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org Johannes Meixner wrote: > On Apr 17 20:21 peter sikking wrote (shortened): >> for users printing, faxing, scanning, memory card reading are >> totally unrelated activities. so it follows that faxing, scanning, >> memory card reading is never going to be seen in a printing dialog >> and also not in a status/monitoring dialog. > > Yes and no - it depends - as always - on the details what > exactly is meant. > > In contrast to separated stand-alone devices where printing, > faxing, scanning, memory card reading works independent > of each other, all-in-one devices introduce hardware-dependent > constraints. > > For example when the all-in-one device is busy with > memory card reading, nothing else might be possible > so that the device status/monitoring in all dialogs > (i.e. also in the printing dialog) must display that > the device is busy with memory card reading. > > The crucial point here is whether or not status/monitoring > is meant regarding the actual hardware device. > > In contrast e.g. a print queue status/monitoring belongs > of course only to the printing dialog. interesting complication. can this lead to the situation that when the print dialog comes up (or users Just Print) that the printer (part) actually looks unavailable/not there to the desktop computer? --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <49EDFEFA.3050504@gmail.com> Date: Tue, 21 Apr 2009 19:14:34 +0200 From: Till Kamppeter MIME-Version: 1.0 References: <513682.96359.qm@web23108.mail.ird.yahoo.com> In-Reply-To: <513682.96359.qm@web23108.mail.ird.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Printing-architecture] [Printing-summit] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hin-Tak Leung Cc: "printing-architecture@lists.linux-foundation.org" , Johannes Meixner , DavidSuffield , "printing-summit@lists.linux-foundation.org" Hin-Tak Leung wrote: > --- On Tue, 21/4/09, Suffield, David wrote: > >> Hi Johannes, >> >>> From: Johannes Meixner [mailto:jsmeix@suse.de] >>> Hello David, >>> >>> On Apr 17 17:55 Suffield, David wrote (shortened): >>>>> As far as I know you cannot derect a scanner >> or memory card unit >>>>> in a HP all-in-one device on the operating >> system level, see >>>>> https://bugzilla.novell.com/show_bug.cgi?id=469721#c9 >>> [...] >>>> All newer HP all-in-ones with photocard readers >> enumerate >>>> as Mass Storage device. Some of the first >> photocard readers >>>> required 1284.4/MLC, but not anymore. >>> How does the scanner unit enumerate nowadays? >> There is no change with scanner USB enumeration. As far as >> I know there is no well defined "scanner" interface like the >> "mass storage" interface. > > Sorry to catch this thread a little late and missed the earlier exchange... just want to say that the USB specification has an imaging device class (I don't remember the precise name), besides printer and mass storage. The imaging device class is where many usb-capable digital camera/camcorder appears as. I think the class is called ptp but can't remember the name... > > granted most scanners uses twain under windows and sane on linux, (and some sort of twain-sane bridge in wine), but often proprietary - somebody correct me. presumably libsane has a way of enumerating scanner devices, if there is no bus contention between accessing other functionalties > such as printing and storage? As far as I remember libsane considers as scanner what has a vendor/product ID pair in the hardcoded list of one of the SANE backends (or even a hardcoded overview list which is part of SANE). Till From mboxrd@z Thu Jan 1 00:00:00 1970 References: <513682.96359.qm@web23108.mail.ird.yahoo.com> From: Olaf Meeuwissen Date: Wed, 22 Apr 2009 09:25:06 +0900 In-Reply-To: <513682.96359.qm@web23108.mail.ird.yahoo.com> (Hin-Tak Leung's message of "Tue\, 21 Apr 2009 17\:05\:14 +0000 \(GMT\)") Message-ID: <87r5zla61p.fsf@avasys.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Printing-architecture] [Printing-summit] Another Common Dialog List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hin-Tak Leung Cc: "printing-architecture@lists.linux-foundation.org" , Johannes Meixner , DavidSuffield , "printing-summit@lists.linux-foundation.org" Hin-Tak Leung writes: > --- On Tue, 21/4/09, Suffield, David wrote: > >> > From: Johannes Meixner [mailto:jsmeix@suse.de]=20 >> >=20 >> > How does the scanner unit enumerate nowadays? >>=20 >> There is no change with scanner USB enumeration. As far as >> I know there is no well defined "scanner" interface like the >> "mass storage" interface.=C2=A0=20 > > [snip] ... just want to say that the USB specification has an imaging > device class (I don't remember the precise name), besides printer and > mass storage. The imaging device class is where many usb-capable > digital camera/camcorder appears as. I think the class is called ptp > but can't remember the name... There was a scanner device class in a draft of the USB spec (ID =3D 6) but that never made the cut for the final standard :-( As a result the bulk of the USB scanners now use the vendor specific class (ID =3D 255). There may be some that use something else but there is NO reliable way you can identify a scanner device short of consulting a database (which needs to be updated continuously to account for new devices hitting the shelves). FWIW, SCSI devices are a little bit better off but even there all is not well. Although the bulk identify themselves as a SCANNER, there are a number of (Epson and HP) devices that think they are a PROCESSOR. There has been some discussion regarding SCSI scanner on the sane-devel mailing list in the threads below: http://lists.alioth.debian.org/pipermail/sane-devel/2009-January/023456.h= tml http://lists.alioth.debian.org/pipermail/sane-devel/2009-January/023507.h= tml http://lists.alioth.debian.org/pipermail/sane-devel/2009-January/023528.h= tml Hope this helps, --=20 Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=3D1962