[Printing-architecture] printerd

[Printing-architecture] printerd

[Till Kamppeter]

Hi,

Tim Waugh has developed a new piece of printing infrastructure. It is 
some D-Bus service owned by the desktop user which takes PDF print jobs 
from the application and dispatching it to CUPS, Google Cloud, network 
printers, ...

This could especially solve problems like per-user print destinations 
like Google Cloud Print printers.

Tim has put up some slides

http://cyberelk.net/tim/wp-content/uploads/2012/04/printerd.pdf

Could we let him present them in some session of the OpenPrinting Summit?

Here is a link with some more background info

http://cyberelk.net/tim/2012/03/08/session-printing/

and first code:

https://gitorious.org/printerd

    Till



On 04/24/2012 11:57 AM, Tim Waugh wrote:
> FWIW, I wrote up a couple of slides in case you want me to talk about it:
>    http://cyberelk.net/tim/wp-content/uploads/2012/04/printerd.pdf
>
> (Note: I won't be here on Thursday)
>
> Tim.
> */
>

Re: [Printing-architecture] printerd

[Ira McDonald]

[-- Attachment #1.1: Type: text/plain, Size: 2606 bytes --]

Hi Tim and Till,

Yes, please, Tim should present these slides this morning
(California time) at 11:00am US Pacific Daylight Time,
right after the Color Management topic.

Mike - please add a session this morning titled "New
Printer Spooler - printerd" and upload these slides.

Tim - I hope this time works for you - if not, please let us
know RIGHT AWAY.  Sometime this California morning
is really the only flexible time left in our schedule.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Wed, Apr 25, 2012 at 4:39 AM, Till Kamppeter <till.kamppeter@gmail.com>wrote:

> Hi,
>
> Tim Waugh has developed a new piece of printing infrastructure. It is some
> D-Bus service owned by the desktop user which takes PDF print jobs from the
> application and dispatching it to CUPS, Google Cloud, network printers, ...
>
> This could especially solve problems like per-user print destinations like
> Google Cloud Print printers.
>
> Tim has put up some slides
>
> http://cyberelk.net/tim/wp-**content/uploads/2012/04/**printerd.pdf<http://cyberelk.net/tim/wp-content/uploads/2012/04/printerd.pdf>
>
> Could we let him present them in some session of the OpenPrinting Summit?
>
> Here is a link with some more background info
>
> http://cyberelk.net/tim/2012/**03/08/session-printing/<http://cyberelk.net/tim/2012/03/08/session-printing/>
>
> and first code:
>
> https://gitorious.org/printerd
>
>   Till
>
>
>
> On 04/24/2012 11:57 AM, Tim Waugh wrote:
>
>> FWIW, I wrote up a couple of slides in case you want me to talk about it:
>>   http://cyberelk.net/tim/wp-**content/uploads/2012/04/**printerd.pdf<http://cyberelk.net/tim/wp-content/uploads/2012/04/printerd.pdf>
>>
>> (Note: I won't be here on Thursday)
>>
>> Tim.
>> */
>>
>>
> ______________________________**_________________
> Printing-architecture mailing list
> Printing-architecture@lists.**linux-foundation.org<Printing-architecture@lists.linux-foundation.org>
> https://lists.linuxfoundation.**org/mailman/listinfo/printing-**
> architecture<https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture>
>

[-- Attachment #1.2: Type: text/html, Size: 3922 bytes --]

[-- Attachment #2: redhat-printerd-tim-waugh.pdf --]
[-- Type: application/pdf, Size: 129593 bytes --]

Re: [Printing-architecture] printerd

[Michael Sweet]

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

Ira,

I have no problem including some discussion of this after the ICC discussions are concluded, but I don't know about the timing (i.e. how much time we'll spend on ICC?)


On Apr 25, 2012, at 7:06 AM, Ira McDonald wrote:

> Hi Tim and Till,
> 
> Yes, please, Tim should present these slides this morning
> (California time) at 11:00am US Pacific Daylight Time,
> right after the Color Management topic.
> 
> Mike - please add a session this morning titled "New 
> Printer Spooler - printerd" and upload these slides.
> 
> Tim - I hope this time works for you - if not, please let us
> know RIGHT AWAY.  Sometime this California morning
> is really the only flexible time left in our schedule.
> 
> Cheers,
> - Ira
> 
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - TCG Embedded Systems Hardcopy SG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto:blueroofmusic@gmail.com
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
> 
> 
> 
> On Wed, Apr 25, 2012 at 4:39 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> Hi,
> 
> Tim Waugh has developed a new piece of printing infrastructure. It is some D-Bus service owned by the desktop user which takes PDF print jobs from the application and dispatching it to CUPS, Google Cloud, network printers, ...
> 
> This could especially solve problems like per-user print destinations like Google Cloud Print printers.
> 
> Tim has put up some slides
> 
> http://cyberelk.net/tim/wp-content/uploads/2012/04/printerd.pdf
> 
> Could we let him present them in some session of the OpenPrinting Summit?
> 
> Here is a link with some more background info
> 
> http://cyberelk.net/tim/2012/03/08/session-printing/
> 
> and first code:
> 
> https://gitorious.org/printerd
> 
>   Till
> 
> 
> 
> On 04/24/2012 11:57 AM, Tim Waugh wrote:
> FWIW, I wrote up a couple of slides in case you want me to talk about it:
>   http://cyberelk.net/tim/wp-content/uploads/2012/04/printerd.pdf
> 
> (Note: I won't be here on Thursday)
> 
> Tim.
> */
> 
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
> 
> <redhat-printerd-tim-waugh.pdf>

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


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

Re: [Printing-architecture] printerd

[Ira McDonald]

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

Hi Mike and Tim,

I'm not sure how much time we'll spend on color management,
but I wanted to schedule some fixed timeslot for those calling
in.

We could move this back to 10:30am US Pacific and plan for
a long lunch hour, but I thought we might wind up spending
quite a lot of time talking about color management.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Wed, Apr 25, 2012 at 11:04 AM, Michael Sweet <msweet@apple.com> wrote:

> Ira,
>
> I have no problem including some discussion of this after the ICC
> discussions are concluded, but I don't know about the timing (i.e. how much
> time we'll spend on ICC?)
>
>
> On Apr 25, 2012, at 7:06 AM, Ira McDonald wrote:
>
> Hi Tim and Till,
>
> Yes, please, Tim should present these slides this morning
> (California time) at 11:00am US Pacific Daylight Time,
> right after the Color Management topic.
>
> Mike - please add a session this morning titled "New
> Printer Spooler - printerd" and upload these slides.
>
> Tim - I hope this time works for you - if not, please let us
> know RIGHT AWAY.  Sometime this California morning
> is really the only flexible time left in our schedule.
>
> Cheers,
> - Ira
>
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - TCG Embedded Systems Hardcopy SG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto:blueroofmusic@gmail.com
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
>
>
>
> On Wed, Apr 25, 2012 at 4:39 AM, Till Kamppeter <till.kamppeter@gmail.com>wrote:
>
>> Hi,
>>
>> Tim Waugh has developed a new piece of printing infrastructure. It is
>> some D-Bus service owned by the desktop user which takes PDF print jobs
>> from the application and dispatching it to CUPS, Google Cloud, network
>> printers, ...
>>
>> This could especially solve problems like per-user print destinations
>> like Google Cloud Print printers.
>>
>> Tim has put up some slides
>>
>> http://cyberelk.net/tim/wp-**content/uploads/2012/04/**printerd.pdf<http://cyberelk.net/tim/wp-content/uploads/2012/04/printerd.pdf>
>>
>> Could we let him present them in some session of the OpenPrinting Summit?
>>
>> Here is a link with some more background info
>>
>> http://cyberelk.net/tim/2012/**03/08/session-printing/<http://cyberelk.net/tim/2012/03/08/session-printing/>
>>
>> and first code:
>>
>> https://gitorious.org/printerd
>>
>>   Till
>>
>>
>>
>> On 04/24/2012 11:57 AM, Tim Waugh wrote:
>>
>>> FWIW, I wrote up a couple of slides in case you want me to talk about it:
>>>   http://cyberelk.net/tim/wp-**content/uploads/2012/04/**printerd.pdf<http://cyberelk.net/tim/wp-content/uploads/2012/04/printerd.pdf>
>>>
>>> (Note: I won't be here on Thursday)
>>>
>>> Tim.
>>> */
>>>
>>>
>> ______________________________**_________________
>> Printing-architecture mailing list
>> Printing-architecture@lists.**linux-foundation.org<Printing-architecture@lists.linux-foundation.org>
>> https://lists.linuxfoundation.**org/mailman/listinfo/printing-**
>> architecture<https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture>
>>
>
> <redhat-printerd-tim-waugh.pdf>
>
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>

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

[Printing-architecture] colord profile per-user in CUPS server

[Kai-Uwe Behrmann]

Tim,

the slides from last years colord presentation answere the question,
which profile will be selected inside CUPS server this way:

"Mapping the device to the profile: Preferences are per-user" [1]

Your stated during my presentation, that colord is a per system 
configuration, suggesting that only system profiles will be used inside 
CUPS server.

How does these both contrary statements go together? Will CUPS see a 
per user printer profile from colord or not?

kind regards
Kai-Uwe Behrmann
-- 
www.oyranos.org

[1] http://www.linuxfoundation.org/collaborate/workgroups/openprinting/openprinting-summit-san-francisco-2011
     https://www.linuxfoundation.org/sites/main/files/colord.pdf

Re: [Printing-architecture] colord profile per-user in CUPS server

[Richard Hughes]

On 26 April 2012 07:06, Kai-Uwe Behrmann <ku.b@gmx.de> wrote:
> the slides from last years colord presentation answere the question,
> which profile will be selected inside CUPS server this way:

I hope Tim doesn't mind if I answer this one.

> "Mapping the device to the profile: Preferences are per-user" [1]

The http://www.freedesktop.org/software/colord/specifics.html page is
a good reference to how it all really works behind the scenes.

Basically, colord is a system service. This means it can only access
profiles in the system context. It stores system configuration in a
sqlite database, also in the system context. What it does also allow
is session clients (like gnome-settings-daemon or colord-kde) to
register devices and profiles from the user (session) context with the
system daemon using DBus. The session passes a file descriptor, so
that the user profile can be used in the system context. A filename
would not work due to the basic UNIX permission model and the fact
that the files in the users home directory are different security
contexts to files in /usr.

So, yes, you can have a file in the users home directory that is used
by CUPS, on the assumption the user is logged in and the home
directory is thus accessible. This isn't great for shared user
workstations, so colord provides a privileged (controlled by a
PolicyKit authentication) method InstallSystemWide[1] which writes the
mapped FD to an actual file in /var/lib/colord/icc which makes the
profile available to all users regardless if the original user is
logged in or not. The file is identical to the file sent as a fd over
DBus, and so has the same profile-id. This means that any existing
mappings continue to work as system profiles are always preferred to
identical user-profiles.

One thing we're also doing is encoding the MAPPING_format and
MAPPING_qualifier [2] into the actual profile metadata at calibration
time which is used if there is no apriori override from the client
which sets up database entries in colord. This allows us to have a
user experience quite a lot how Mike Sweet described yesterday where
you only have one moving piece rather than two. This has the advantage
that we *show* the user what profile what would be used for the given
set of printer options, and don't allow the user to manually select a
profile to use. Of course, advanced users can just set an output
profile in the print-ready pdf itself, which means that the
colord-provided printer system output profile is not used at all. This
ensures that advanced color-geek users can set whatever exact profile
they like and for people that don't care anything about how color
management works (the 99.9999%), it "just works". Note, in the GKT GUI
we only show the profile title[3], and don't allow a specific ICC
output profile filename to be chosen. It's expected that apps that
care (basically Scribus, perhaps Krita/GIMP) will add a custom print
setup page and add the entry there.

If you've got any more questions about colord, I'd ask that you join
the colord-users mailing list where other people can answer questions
as well as Tim and I. Thanks,

Richard.

[1] https://gitorious.org/colord/master/blobs/master/src/org.freedesktop.ColorManager.Profile.xml#line203
[2] https://gitorious.org/colord/master/blobs/master/doc/metadata-spec.txt#line41
[3] http://people.freedesktop.org/~hughsient/temp/Screenshot-Print-1.png

Re: [Printing-architecture] colord profile per-user in CUPS server

[Michael Sweet]

Richard,

The only addition to the current infrastructure that I'd recommend is to create CUPS printer instances when a profile is created that contain the settings used for that profile.

For example, if a user/admin installs a profile for Acme Ultrasmooth Fine Art paper, create/replace a corresponding instance (and probably give the user a chance to rename this) called "Acme_Ultrasmooth_Fine_Art_Paper" that can be selected in the print dialog to effectively choose this profile and the corresponding settings.

I don't know if the current GTK+/GNOME print dialog exposes instances, but it would make sense to do so along with any PPD-defined presets - we've had this in OS X's print dialog for a very long time and it eliminates a lot of button pushing for the user for common usage...


On Apr 26, 2012, at 12:11 AM, Richard Hughes wrote:

> On 26 April 2012 07:06, Kai-Uwe Behrmann <ku.b@gmx.de> wrote:
>> the slides from last years colord presentation answere the question,
>> which profile will be selected inside CUPS server this way:
> 
> I hope Tim doesn't mind if I answer this one.
> 
>> "Mapping the device to the profile: Preferences are per-user" [1]
> 
> The http://www.freedesktop.org/software/colord/specifics.html page is
> a good reference to how it all really works behind the scenes.
> 
> Basically, colord is a system service. This means it can only access
> profiles in the system context. It stores system configuration in a
> sqlite database, also in the system context. What it does also allow
> is session clients (like gnome-settings-daemon or colord-kde) to
> register devices and profiles from the user (session) context with the
> system daemon using DBus. The session passes a file descriptor, so
> that the user profile can be used in the system context. A filename
> would not work due to the basic UNIX permission model and the fact
> that the files in the users home directory are different security
> contexts to files in /usr.
> 
> So, yes, you can have a file in the users home directory that is used
> by CUPS, on the assumption the user is logged in and the home
> directory is thus accessible. This isn't great for shared user
> workstations, so colord provides a privileged (controlled by a
> PolicyKit authentication) method InstallSystemWide[1] which writes the
> mapped FD to an actual file in /var/lib/colord/icc which makes the
> profile available to all users regardless if the original user is
> logged in or not. The file is identical to the file sent as a fd over
> DBus, and so has the same profile-id. This means that any existing
> mappings continue to work as system profiles are always preferred to
> identical user-profiles.
> 
> One thing we're also doing is encoding the MAPPING_format and
> MAPPING_qualifier [2] into the actual profile metadata at calibration
> time which is used if there is no apriori override from the client
> which sets up database entries in colord. This allows us to have a
> user experience quite a lot how Mike Sweet described yesterday where
> you only have one moving piece rather than two. This has the advantage
> that we *show* the user what profile what would be used for the given
> set of printer options, and don't allow the user to manually select a
> profile to use. Of course, advanced users can just set an output
> profile in the print-ready pdf itself, which means that the
> colord-provided printer system output profile is not used at all. This
> ensures that advanced color-geek users can set whatever exact profile
> they like and for people that don't care anything about how color
> management works (the 99.9999%), it "just works". Note, in the GKT GUI
> we only show the profile title[3], and don't allow a specific ICC
> output profile filename to be chosen. It's expected that apps that
> care (basically Scribus, perhaps Krita/GIMP) will add a custom print
> setup page and add the entry there.
> 
> If you've got any more questions about colord, I'd ask that you join
> the colord-users mailing list where other people can answer questions
> as well as Tim and I. Thanks,
> 
> Richard.
> 
> [1] https://gitorious.org/colord/master/blobs/master/src/org.freedesktop.ColorManager.Profile.xml#line203
> [2] https://gitorious.org/colord/master/blobs/master/doc/metadata-spec.txt#line41
> [3] http://people.freedesktop.org/~hughsient/temp/Screenshot-Print-1.png
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] colord profile per-user in CUPS server

[James Cloos]

>>>>> "MS" == Michael Sweet <msweet@apple.com> writes:

MS> I don't know if the current GTK+/GNOME print dialog exposes instances,

It notices them, but it doesn't really support them.

As an example, I have instances like:

,----< excerpt from ~/.cups/lpoptions >
| Dest mc/booklet number-up=2 Duplex=DuplexTumble
| Dest mc/short Duplex=DuplexTumble
| Dest mc/long Duplex=DuplexNoTumble
| Dest mc Duplex=None
| Default mc Duplex=DuplexNoTumble
`----

GTK apps only show a single mc queue, but conflate it into 
number-up=2 DuplexNoTumble, which isn't even a defined instance.

Qt4, OTOH, seems to get it right, showing each instance as a separate
queue, with correct settings for each.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [Printing-architecture] colord profile per-user in CUPS server

[Till Kamppeter]

James, I suggest to report this as a bug to GTK upstream. First, the settings for the default case are wrong and second, instances shoul be supported, they are a CUPS feature to save settings for common tasks and in color management age it is especially important. The print dialogs should also have a "Save settings as ..."-like button to save settings into a new instance and a "save"-like button to save the settings into the current instance.

   Till



On Apr 26, 2012, at 4:36 PM, James Cloos <cloos@jhcloos.com> wrote:

>>>>>> "MS" == Michael Sweet <msweet@apple.com> writes:
> 
> MS> I don't know if the current GTK+/GNOME print dialog exposes instances,
> 
> It notices them, but it doesn't really support them.
> 
> As an example, I have instances like:
> 
> ,----< excerpt from ~/.cups/lpoptions >
> | Dest mc/booklet number-up=2 Duplex=DuplexTumble
> | Dest mc/short Duplex=DuplexTumble
> | Dest mc/long Duplex=DuplexNoTumble
> | Dest mc Duplex=None
> | Default mc Duplex=DuplexNoTumble
> `----
> 
> GTK apps only show a single mc queue, but conflate it into 
> number-up=2 DuplexNoTumble, which isn't even a defined instance.
> 
> Qt4, OTOH, seems to get it right, showing each instance as a separate
> queue, with correct settings for each.
> 
> -JimC
> -- 
> James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture

Re: [Printing-architecture] colord profile per-user in CUPS server

[James Cloos]

>>>>> "TK" == Till Kamppeter <till.kamppeter@gmail.com> writes:

TK> James, I suggest to report this as a bug to GTK upstream.

This existing bugs are (at least):

https://bugzilla.gnome.org/show_bug.cgi?id=582747
https://bugzilla.gnome.org/show_bug.cgi?id=657706

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [Printing-architecture] colord profile per-user in CUPS server

[Kai-Uwe Behrmann]

Am 26.04.12, 08:11 +0100 schrieb Richard Hughes:
> On 26 April 2012 07:06, Kai-Uwe Behrmann <ku.b@gmx.de> wrote:
>> Tim,
>>
>> the slides from last years colord presentation answere the question,
>> which profile will be selected inside CUPS server this way:

>> "Mapping the device to the profile: Preferences are per-user" [1]
>
> The http://www.freedesktop.org/software/colord/specifics.html page is
> a good reference to how it all really works behind the scenes.

Yes, that's from where the above citation originates.

> So, yes, you can have a file in the users home directory that is used
> by CUPS, on the assumption the user is logged in and the home
> directory is thus accessible. This isn't great for shared user

So, Tim's yesterdays statement was unfortunately misleading. Thanks for 
clearifying that.

>> Your stated during my presentation, that colord is a per system 
>> configuration, suggesting that only system profiles will be used inside
>> CUPS server.
>
> How does these both contrary statements go together? Will CUPS see a per 
> user printer profile from colord or not?

The description of colord inside CUPS server, including the comparision 
table, in my yesterdays presentation, hit pretty much the situation,
and I feel none of my concerns have been dispelled:
* colord configuration is time(session) dependent
* contrary CUPS server organises jobs in print queues
* thus interference of colord in multi user sessions are likely
* ICC Profile selection is largely undefined due to above reasons
* That means colord+CUPS become hard and laborous to debug for users.

All in all, the colord hook inside CUPS server appears to be a 
pretty problematic and orthogonal approach.

The two other presented configuration approaches integrate nicely into 
CUPS server. Thus the per queue ICC profile and per job ICC embeddeding 
into PDF OutputIntent are in my opinion much more robust, useable and 
maintainable for enterprise and professional support.

kind regards
Kai-Uwe Behrmann
-- 
www.oyranos.org

[1] ftp://ftp.pwg.org/pub/pwg/openprinting/summits/April2012_OPSummit/CM-Print-Paths2012.pdf

Re: [Printing-architecture] colord profile per-user in CUPS server

[Richard Hughes]

On 26 April 2012 17:45, Kai-Uwe Behrmann <ku.b@gmx.de> wrote:
> The description of colord inside CUPS server, including the comparision
> table, in my yesterdays presentation, hit pretty much the situation,
> and I feel none of my concerns have been dispelled:
> * colord configuration is time(session) dependent

No, not at all. If you install a profile system wide then it's
available for all users at login time.

> * contrary CUPS server organises jobs in print queues

I don't understand this point, sorry.

> * thus interference of colord in multi user sessions are likely

Can you describe what you mean by 'interference' please?

> * ICC Profile selection is largely undefined due to above reasons
> * That means colord+CUPS become hard and laborous to debug for users.
> All in all, the colord hook inside CUPS server appears to be a pretty
> problematic and orthogonal approach.

I guess that comes down to opinion. Also it's probably pertinent to
note that colord works in a very similar way to ColorSync. And also,
that colord is being used by hundreds of thousands of users on Linux
*right now* rather than being a concept.

> The two other presented configuration approaches integrate nicely into CUPS
> server. Thus the per queue ICC profile and per job ICC embeddeding into PDF
> OutputIntent are in my opinion much more robust, useable and maintainable
> for enterprise and professional support.

Please, how many more times... If you embed an output ICC profile then
it gets used rather than the profile used specified by colord. It's
not an either/or situation.

Richard.

Re: [Printing-architecture] colord profile per-user in CUPS server

[Kai-Uwe Behrmann]

Am 26.04.12, 18:05 +0100 schrieb Richard Hughes:
> On 26 April 2012 17:45, Kai-Uwe Behrmann <ku.b@gmx.de> wrote:
>> The description of colord inside CUPS server, including the comparision
>> table, in my yesterdays presentation, hit pretty much the situation,
>> and I feel none of my concerns have been dispelled:
>> * colord configuration is time(session) dependent

> No, not at all.

Sorry, your negation does not fit to your other statement below.

Richard Hughes:
"Mapping the device to the profile: Preferences are per-user"

>> * contrary CUPS server organises jobs in print queues
>> * thus interference of colord in multi user sessions are likely

> Can you describe what you mean by 'interference' please?

Yes. A small multi user session scenario:
User A is logged into the system and user B's print job gets printed on 
the same machine. User A's ICC session profile kicks in through colord. B 
needs to invest time, material and money to find out, that colord needs to 
be uninstalled to get to relyable printing.

>> * ICC Profile selection is largely undefined due to above reasons
>> * That means colord+CUPS become hard and laborous to debug for users.
>> All in all, the colord hook inside CUPS server appears to be a pretty
>> problematic and orthogonal approach.
>
> I guess that comes down to opinion. Also it's probably pertinent to
> note that colord works in a very similar way to ColorSync. And also,
> that colord is being used by hundreds of thousands of users on Linux
> *right now* rather than being a concept.

What is your technical point here? Fuzzy marketing statements can not 
provide a helpful answere to a technical problem.

>> The two other presented configuration approaches integrate nicely into CUPS
>> server. Thus the per queue ICC profile and per job ICC embeddeding into PDF
>> OutputIntent are in my opinion much more robust, useable and maintainable
>> for enterprise and professional support.
>
> Please, how many more times... If you embed an output ICC profile then
> it gets used rather than the profile used specified by colord. It's

Oh, so you tested that? Can you point me to the according test methods?

> not an either/or situation.

For the one ICC profile per print queue concept colord will override the 
ICC selection undesireably.

regards
Kai-Uwe Behrmann
-- 
www.oyranos.org

Re: [Printing-architecture] printerd

[Michael Sweet]

Till,

Sounds like good material for the "Future of Open Printing" session on Friday.

(and perhaps opens up another opportunity for the dbus-based print dialog?)


On Apr 25, 2012, at 1:39 AM, Till Kamppeter wrote:

> Hi,
> 
> Tim Waugh has developed a new piece of printing infrastructure. It is some D-Bus service owned by the desktop user which takes PDF print jobs from the application and dispatching it to CUPS, Google Cloud, network printers, ...
> 
> This could especially solve problems like per-user print destinations like Google Cloud Print printers.
> 
> Tim has put up some slides
> 
> http://cyberelk.net/tim/wp-content/uploads/2012/04/printerd.pdf
> 
> Could we let him present them in some session of the OpenPrinting Summit?
> 
> Here is a link with some more background info
> 
> http://cyberelk.net/tim/2012/03/08/session-printing/
> 
> and first code:
> 
> https://gitorious.org/printerd
> 
>   Till
> 
> 
> 
> On 04/24/2012 11:57 AM, Tim Waugh wrote:
>> FWIW, I wrote up a couple of slides in case you want me to talk about it:
>>   http://cyberelk.net/tim/wp-content/uploads/2012/04/printerd.pdf
>> 
>> (Note: I won't be here on Thursday)
>> 
>> Tim.
>> */
>> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair