Re: [Printing-architecture] [Printing-summit] Another Common Dialog

Re: [Printing-architecture] [Printing-summit] Another Common Dialog

[Petrie, Glen]

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

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-summit@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/printing-summit

 

________________________________________

Michael R Sweet, Senior Printing System Engineer

 


[-- Attachment #2: Type: text/html, Size: 9367 bytes --]

Re: [Printing-architecture] [Printing-summit] Another Common Dialog

[Till Kamppeter]

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

Re: [Printing-architecture] [Printing-summit] Another Common Dialog

[peter sikking]

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

Re: [Printing-architecture] [Printing-summit] Another Common Dialog

[peter sikking]

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

Re: [Printing-architecture] [Printing-summit] Another Common Dialog

[peter sikking]

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

Re: [Printing-architecture] [Printing-summit] Another Common Dialog

[Till Kamppeter]

Hin-Tak Leung wrote:
> --- On Tue, 21/4/09, Suffield, David <david.suffield@hp.com> 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

Re: [Printing-architecture] [Printing-summit] Another Common Dialog

[Olaf Meeuwissen]

Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:

> --- On Tue, 21/4/09, Suffield, David <david.suffield@hp.com> wrote:
>
>> > From: Johannes Meixner [mailto:jsmeix@suse.de] 
>> > 
>> > 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.  
>
> [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 = 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 = 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.html
  http://lists.alioth.debian.org/pipermail/sane-devel/2009-January/023507.html
  http://lists.alioth.debian.org/pipermail/sane-devel/2009-January/023528.html

Hope this helps,
-- 
Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962               Help support software freedom
                 http://www.fsf.org/jf?referrer=1962