Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Till Kamppeter]

Robert Krawitz wrote:
>    Date: Sun, 19 Oct 2008 15:35:31 +0200
>    From: Till Kamppeter <till.kamppeter@gmail.com>
> 
>    Another point is completing the PPD extensions for the Common Printing 
>    Dialog. Most important point is tagging the options, so that they show 
>    up with the right tags being selected.
> 
>    See
> 
>    http://www.linuxfoundation.org/en/OpenPrinting/CommonPrintingDialog
>    http://www.linuxfoundation.org/en/OpenPrinting/PPDExtensions
> 
> I still don't much care for this limitation of 6 tags being available
> for the driver.  If nothing else, we could use some assistance in
> figuring out how to categorize all of the options.
> 
> In general, I'd really like to have a way to hide the advanced
> options.  I know full well that the vast majority of people have no
> interest in them, but that's not a reason to make them entirely
> unavailable to the people who do have reason to use them.
> Philosophically, I don't care for this dumbing down approach.  I know
> I'm not the only person out there who likes to have fine-grained
> controls available!
> 
> (I'd also like to have generalized piecewise or dense curves available
> in CUPS, but that's another matter.)

Perhaps we should find a solution together with Peter Sikking, designer 
of the Common Printing Dialog.

Peter, the Gutenprint driver has far too many option groups for the 
limited amount of tags in the Common Printing Dialog. What is your 
suggestion how to let the options of Gutenprint get presented in the 
Common Printing Dialog?

    Till

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[peter sikking]

Till + Robert,

sorry to not get back to you sooner, it slipped under the holiday radar.

>>   Date: Sun, 19 Oct 2008 15:35:31 +0200
>>   From: Till Kamppeter <till.kamppeter@gmail.com>
>>   Another point is completing the PPD extensions for the Common  
>> Printing    Dialog. Most important point is tagging the options, so  
>> that they show    up with the right tags being selected.
>>   See
>>   http://www.linuxfoundation.org/en/OpenPrinting/CommonPrintingDialog
>>   http://www.linuxfoundation.org/en/OpenPrinting/PPDExtensions
>> I still don't much care for this limitation of 6 tags being available
>> for the driver.  If nothing else, we could use some assistance in
>> figuring out how to categorize all of the options.
>> In general, I'd really like to have a way to hide the advanced
>> options.  I know full well that the vast majority of people have no
>> interest in them, but that's not a reason to make them entirely
>> unavailable to the people who do have reason to use them.
>> Philosophically, I don't care for this dumbing down approach.  I know
>> I'm not the only person out there who likes to have fine-grained
>> controls available!
>> (I'd also like to have generalized piecewise or dense curves  
>> available
>> in CUPS, but that's another matter.)
>
> Perhaps we should find a solution together with Peter Sikking,  
> designer of the Common Printing Dialog.
>
> Peter, the Gutenprint driver has far too many option groups for the  
> limited amount of tags in the Common Printing Dialog. What is your  
> suggestion how to let the options of Gutenprint get presented in the  
> Common Printing Dialog?


well, first of all there are 11 tags available to the printer  
(==driver),
you can use these fully within the vision of gutenprint, which is
fine-grained control. do not confuse good UI design with complexity
reduction with dumbing down. it is about delivering value to the
target user group. when you know I am also the principal UI architect
of the renovation of GIMP, you can see I know a thing or two about
delivering power to pros.

second there are still principles of good interaction design,
like prioritising your parameters, seeing which are a specialisation
of another parameter. another good trick is when there are 3 boolean
options, and 6 combinations make sense, to represent them all as 6
choices for one parameter. when still in a pinch, super-duper
once-per-paper-ink-combination calibration type stuff can be
moved to a separate dialog, where there is space for advanced controls.
the dialog is then opened as an extension to the more basic parameters
in the dialog via a button.

I would still encourage you to treat the 11 tags not as tabs, but to  
dive
into the world of gutenprint and find out what aspects of printing
really interest your audience. and then assign the parameters you have  
to
one or more tags.

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[peter sikking]

Robert,

>>> Peter, the Gutenprint driver has far too many option groups for the
>>> limited amount of tags in the Common Printing Dialog. What is your
>>> suggestion how to let the options of Gutenprint get presented in the
>>> Common Printing Dialog?
>
>>   when still in a pinch, super-duper
>>   once-per-paper-ink-combination calibration type stuff can be moved
>>   to a separate dialog, where there is space for advanced controls.
>>   the dialog is then opened as an extension to the more basic
>>   parameters in the dialog via a button.
>>
> There are a lot of low level ink controls that I would be happy to
> move elsewhere, but it's not clear to me where that "elsewhere" is
> provided.


like I said, separate dialog triggered from the print dialog.

>  In general, though, there aren't all that many boolean
> parameters, and those that we do have really are orthogonal (linear
> vs. S-curve contrast adjustment, borderless, and use of gloss enhancer
> have absolutely nothing to do with one another).

OK, it was worth a try.

>>   I would still encourage you to treat the 11 tags not as tabs, but
>>   to dive into the world of gutenprint and find out what aspects of
>>   printing really interest your audience. and then assign the
>>   parameters you have to one or more tags.
>
> This is an area we could use some assistance on.  I have no feel at
> all for UI design.  In general, the best way to utilize my skills in
> user interface design is to invert whatever I might happen to come up
> with.
>
> I really want Gutenprint to appeal to a very wide range of people,
> from the "I just want it to work" folks all the way to the hard core
> fine art (and other) professionals who want to be able to adjust
> everything for a non-standard ink set and oddball paper.

For anybody to be able to help you at all, you first need to
set a clear vision for what the purpose of gutenprint is in
the printing world of today. And "to appeal to a very wide
range of people" is not it. You will have to say good bye to
some old goals. The (linux) printing world has evolved.
Similar to how GIMP has moved on from 'the sole pixel program
on linux' to an expert tool that does not aim to please
casual users.

I can tell you that when the GIMP team would not have defined
that vision, and tried to be the tool for "a very wide range
of people", I would not have got involved.

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Till Kamppeter]

peter sikking wrote:
> like I said, separate dialog triggered from the print dialog.
>

And how should this dialog look like? Someone has to implement it. The 
printer driver runs on the CUPS server and it cannot send executable 
programs to the clients.

Do we have to consider the design project of the Common Printing Dialog 
as incomplete or even failed then?

Do we have to start a design for a "Common Secondary Printing Dialog" 
before we can implement the Common Printing Dialog?

    Till


>>  In general, though, there aren't all that many boolean
>> parameters, and those that we do have really are orthogonal (linear
>> vs. S-curve contrast adjustment, borderless, and use of gloss enhancer
>> have absolutely nothing to do with one another).
> 
> OK, it was worth a try.
> 
>>>   I would still encourage you to treat the 11 tags not as tabs, but
>>>   to dive into the world of gutenprint and find out what aspects of
>>>   printing really interest your audience. and then assign the
>>>   parameters you have to one or more tags.
>>
>> This is an area we could use some assistance on.  I have no feel at
>> all for UI design.  In general, the best way to utilize my skills in
>> user interface design is to invert whatever I might happen to come up
>> with.
>>
>> I really want Gutenprint to appeal to a very wide range of people,
>> from the "I just want it to work" folks all the way to the hard core
>> fine art (and other) professionals who want to be able to adjust
>> everything for a non-standard ink set and oddball paper.
> 
> For anybody to be able to help you at all, you first need to
> set a clear vision for what the purpose of gutenprint is in
> the printing world of today. And "to appeal to a very wide
> range of people" is not it. You will have to say good bye to
> some old goals. The (linux) printing world has evolved.
> Similar to how GIMP has moved on from 'the sole pixel program
> on linux' to an expert tool that does not aim to please
> casual users.
> 
> I can tell you that when the GIMP team would not have defined
> that vision, and tried to be the tool for "a very wide range
> of people", I would not have got involved.
> 
>     --ps
> 
>         founder + principal interaction architect
>             man + machine interface works
> 
>         http://mmiworks.net/blog : on interaction architecture
> 
> 
> 
> 

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Alastair M. Robinson]

Hi,

peter sikking wrote:

> For anybody to be able to help you at all, you first need to
> set a clear vision for what the purpose of gutenprint is in
> the printing world of today.

Part of what makes this difficult is that gutenprint is at the same time 
behind-the-scenes infrastructure, and also user-facing, since the 
structure of its options system is exposed indirectly through the PPDs.

 > You will have to say good bye to
> some old goals.

I think one thing we may have to revisit will be the assumption that 
gutenprint's options are mapped directly to options in the printing 
dialog.  The introduction of simplified PPDs was a step in this 
direction, but the difficulty we've had in figuring out how to handle 
calibration curves and so on makes me think it may be time to go further.

With the recent push to make the Epson driver more data-driven, and 
pulling previously hard-coded data into XML files, I wonder whether we 
need to consider having an administration tool, completely separate from 
the PPD-based print chain, which can be used by administrators and 
"Domain Experts" (people who know how to handle colour-management and 
calibration, but don't care about code) to fine tune things like the 
low-level ink controls, and calibration curves, which are so hard to fit 
into a user-facing print dialog.

Gutenprint's "Quality" and "Media Type" options between them set a large 
number of options to hard-coded defaults - I envisage this hypothetical 
administration tool being used to *change* these defaults, and save them 
  (along with calibration curves, and ideally ICC profiles too) as files 
which could then be shared with other users.  This would solve another 
difficulty that was brought up when we first started discussing 
calibration and linearization - being able to *distribute* and share 
settings.

None of this detracts from the continued ability of software which uses 
Gutenprint directly, like the advanced print plugin, or PhotoPrint, from 
continuing to offer full control, but it could potentially make life 
much more pleasant for "one-click-print" users.

All the best,
--
Alastair M. Robinson

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Hal V. Engel]

On Friday 24 October 2008 05:35:57 Alastair M. Robinson wrote:
> Hi,
>
> peter sikking wrote:
> > For anybody to be able to help you at all, you first need to
> > set a clear vision for what the purpose of gutenprint is in
> > the printing world of today.
>
> Part of what makes this difficult is that gutenprint is at the same time
> behind-the-scenes infrastructure, and also user-facing, since the
> structure of its options system is exposed indirectly through the PPDs.
>
>  > You will have to say good bye to
> >
> > some old goals.
>
> I think one thing we may have to revisit will be the assumption that
> gutenprint's options are mapped directly to options in the printing
> dialog.  The introduction of simplified PPDs was a step in this
> direction, but the difficulty we've had in figuring out how to handle
> calibration curves and so on makes me think it may be time to go further.
>
> With the recent push to make the Epson driver more data-driven, and
> pulling previously hard-coded data into XML files, I wonder whether we
> need to consider having an administration tool, completely separate from
> the PPD-based print chain, which can be used by administrators and
> "Domain Experts" (people who know how to handle colour-management and
> calibration, but don't care about code) to fine tune things like the
> low-level ink controls, and calibration curves, which are so hard to fit
> into a user-facing print dialog.
>
> Gutenprint's "Quality" and "Media Type" options between them set a large
> number of options to hard-coded defaults - I envisage this hypothetical
> administration tool being used to *change* these defaults, and save them
>   (along with calibration curves, and ideally ICC profiles too) as files
> which could then be shared with other users.  This would solve another
> difficulty that was brought up when we first started discussing
> calibration and linearization - being able to *distribute* and share
> settings.
>
> None of this detracts from the continued ability of software which uses
> Gutenprint directly, like the advanced print plugin, or PhotoPrint, from
> continuing to offer full control, but it could potentially make life
> much more pleasant for "one-click-print" users.
>
> All the best,
> --
> Alastair M. Robinson
 
In many respects I agree with Alastair.  GutenPrint really does need a 
separate administrative interface for these more advanced functions and this 
also needs to be tied to the basic end user UI so that admins can set things 
up so that these are presented to users in an easy to understand way.   I also 
believe that the same thing is true, perhaps to a lessor extent, for all 
printer drivers.  At this point I think the only drivers that have the 
potential to provide user control over calibration curves is GutenPrint but at 
some point in the not too distant future we will have printing work flows that 
implement ICC profiles that could/should be used by all drivers not just those 
from GutenPrint and current UI and admin interfaces do not provide any support 
for this.  OK someone is likely to point out the cupsICCProfile settings that 
are now available in the PPD files.  But these are NOT suitable for local use 
for a number of reasons.

The basic issue that is causing so much difficultly is the static supplied by 
the driver vendor nature of the PPD files vs. the local nature of ICC profiles 
and custom printer calibration.   PPD files were not designed for local 
customization but some way of creating local persistent customization is 
exactly what needs to happen to accommodate things like color management that 
are local in nature and that need to be customized for each installation.   

As an example it is desirable to have groups of settings that are associated 
with particular ICC profiles that are some how presented to users as a 
"preset" that can be selected in the end user UI.  PhotoPrint does this 
although I think the UI for this in PhotoPrint could be improved.  This is 
something that can not be done as part of the default PPD based configuration 
since much of this is installation specific and needs to be configured by the 
local admin or an advanced user to meet local requirements.  After all only 
the local admin/users know what papers are going to be used and what settings 
were used to create the profiles for those papers and so on.  With GutenPrint 
at some point this would also include things like custom linearization data.   
These presets should be presented to users in a way that makes it easy for 
them to understand what the preset means (IE. what specific printer this is 
for, what paper to load into the printer and what profile to use for 
proofing...).  I do not think this belongs in the PPD structure although it 
might be possible to use the PPD file to divide these driver features into 
those that are intended for end users and those that are supported in the 
administrative interface.  The thing to consider is that ICC profile support 
is implemented in the *toraster CUPS filters and it is not a feature of the 
print driver.

I also agree with Peter to some extent although I don't think supporting both 
advanced and basic end users is contradictory it is just more difficult.  The 
UI needs to be easy for less advanced end users and presenting too much 
complexity in the end user UI is contrary to this goal.  At the same time I 
think that with a correctly designed administrative interface it should be 
possible for local admins and/or advanced users to configure local settings 
that hide this complexity from less advanced users who don't need or want to 
understand the underlying complexity.  In other words this has the possibility 
to make things even simpler for end users if the local admin has the where 
with all to set things up correctly.   I would go so far as to say that it 
should be possible for the local admin to hide UI settings and features that 
would normally be exposed to users by default so that there was total control 
over what was presented to local users.   The problem is that we are trying to 
do everything in one UI when in reality we have what is end user functionality 
and administrative/advanced functionality and these need to some how be 
separated but still interrelated (IE. administrative changes can/should affect 
what is seen in the end user UI).   

Hal 

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Alastair M. Robinson]

Hi :)

Michael R Sweet wrote:

> Moreover, a fully data-driven
> Gutenprint has the built-in capability to regenerate a PPD with the
> current data,

Does that include PPDs already assigned to an existing queue? (i.e. 
those in /etc/cups/ppd/)

> The APPrinterPreset PPD keyword can already be used for this and has
> been adopted by OpenPrinting...

So assuming the answer to my previous question is "yes", our 
hypothetical admin tool could be used not only to tune or linearize 
existing Quick Presets from the Common Printing Dialog, but to directly 
create new ones.  That is very cool.

Is the value of APPrinterPreset available to the driver, BTW, or is it 
merely something that is used to set other variables automatically?  If 
we're hoping to fetch tunings or linearization curves based on the 
preset, we would of course need to know which preset was selected!

All the best,
--
Alastair M. Robinson

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Alastair M. Robinson]

Hi :)

Robert Krawitz wrote:

> When you get right down to it, Gutenprint at its core really is a
> hardware driver (or a package of hardware drivers).  It's not an
> application the way GIMP is -- it's a piece of infrastructure.

True - however it doesn't have the luxury enjoyed by other pieces of 
infrastructure of being isolated from end-users.  If I go to 
localhost:631, click on my printer and hit Set Printer Options, I see a 
user-interface.  CUPS *presents* this user-interface, but which controls 
I see and how they're grouped is determined by Gutenprint.  It may not 
be an application, but there are user-facing aspects.

Incidentally, Peter, if an option exists in the PPD but isn't tagged, 
what happens?  Will it appear in the Common Printing Dialog?
And what happens if an APPrinterPreset specifies a value for an untagged 
option?  Will it still be set?

I'm just wondering whether we can tag options which "fit" with the 
Common Printing Dialog, and leave the others in the PPD but untagged?

> I don't mind if there are multiple applications or dialogs using
> Gutenprint.  However, I *do* mind if pressure for "one size fits all"
> results in advanced users not having controls they need.  At the same
> time, it is essential to me that users with basic needs have a simple
> print path.

I can't argue with any of that.

> One issue I do have is with the idea that modifying curves or presets
> should be thought of as an administrative role. Certainly it's
> something administrators might well do, to achieve common printing
> results across a user base, but ordinary users may also need to
> do things like this.

Well, my original phrase was "Administrators and domain experts", so 
yes, I agree that admin rights shouldn't be a neccessity for accessing 
these facilities - though it should probably be a requirement for 
actually applying changes which impact all users.  So ideally we need 
some way to store and transmit these settings on a per-user basis.


Also note that as far as I know all the software which allows 
finest-grained control of Gutenprint's options currently uses Gutenprint 
directly, and thus RIPs the page client-side. (As would our hypothetical 
calibration / linearization / tuning tool).

Robert, would the following state of affairs be acceptable in your view:

* Software which prints via the Common Printing Dialog has user-access 
to a limited subset of options, much as PPD-based software does now if 
the Simplified PPDs are used.  Additionally, if new presets, or 
modifications to existing presets (i.e. the PrintQuality / Media Type 
options) have been installed systemwide, they become available from the CPD.

* Presets can be adjusted/created and tested (via client-side ripping) 
by a regular user, but admin rights would be needed to install the 
modified data systemwide, before the updated preset would be usable from 
the CPD.

* Software which does client-side ripping (i.e. the Gutenprint GIMP 
plugin, PhotoPrint, etc.) continues to have access to the full raft of 
controls available to regular users.  Additionally, local presets 
created in the tuning tool can be used, without them having to be 
installed systemwide.

That much I think could be achieved relatively easily.  Somewhat harder 
would be making modified presets available for use within the CPD 
without needing admin rights to install them.  That, I think, would 
require a way of sending side-band information to CUPS/Gutenprint and 
having some way of storing it on the server on a per-user basis.  This 
is something that might be desirable anyway, mind you; the current 
situation with default printer settings in CUPS (a choice between 
needing root access to set them, or allowing users to change the 
defaults systemwide) isn't ideal.

All the best,
--
Alastair M. Robinson

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Alastair M. Robinson]

Hi :)

Robert Krawitz wrote:

> Right, but that's not efficient for printing large documents at high
> resolution over a network.

Agreed.

> I don't think that that's quite good enough.  I'm OK with having the
> CPD itself provide only a limited set of options, as long as it's
> possible for both users and administrators to create preset bundles
> that may reference options not provided in the PPD file.  Requiring
> use of a client side RIP in order to use custom linearization curves
> isn't acceptable to me.

Fair enough - and I tend to agree - I'm just trying to figure out what 
we can do within the bounds of the current infrastructure, and whether, 
or to what extent, we need new facilities!

> So someone might want to create a preset bundle that includes
> linearization curves and other settings for a particular paper type,
> resolution, and ink set (e. g. photo or matte inks).  I think a user
> should be able to do that just as well as an administrator.

In the scenario I outlined, a user is able to do that.  The sticking 
point is that actually *installing* it, so that the changes can be used 
via the CPD, would require admin rights.

> Note that the preset bundle may actually be a large amount of data.

Yes indeed.

All the best,
--
Alastair M. Robinson

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Alastair M. Robinson]

Hi :)

Robert Krawitz wrote:

> Right, but if the infrastructure's missing something, we need to know
> what it is and if necessary how to work around it.

What's missing, I think, is any way of storing persistent data 
server-side on a per-user basis.  The cups filters have access to the 
name of a job's "owner", yes?  So as far as I can see, fetching a user's 
overrides (for those parameters which are out-of-band as far as the 
Common Printing Dialog is concerned) would be easy enough if there were 
anywhere suitable to store them.

> And that's a very big problem -- the whole point of creating presets
> like this is to use them.

Yup, absolutely.

All the best,
--
Alastair M. Robinson

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Alastair M. Robinson]

Hi :)

Robert Krawitz wrote:

> Why does it have to be server-side?  The print dialog could implement
> it.

Well, this whole discussion started with the question of how gutenprint 
will work with the Common Printing Dialog.

You said: "There are a lot of low level ink controls that I would be 
happy to move elsewhere, but it's not clear to me where that "elsewhere" 
is provided."

I'm brainstorming here - simply exploring the idea that it may fall to 
Gutenprint to create that "elsewhere" for itself, out-of-band as far as 
the main printing dialog goes.  Making out-of-band data available to the 
print filters without requiring admin permissions is not an easy problem 
to solve, but it's one that we need to solve at some point anyway, I 
think, in order to support the easy creation and sharing of 
linearization curves.

All the best,
--
Alastair M. Robinson

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Till Kamppeter]

Johannes Meixner wrote:
> Hello,
> 
> On Oct 27 06:54 Robert Krawitz wrote (shortened):
>>   Date: Sun, 26 Oct 2008 20:08:44 -0700
>>   From: Michael R Sweet <msweet@apple.com>
>>
>>   Robert Krawitz wrote:
>>   >    Date: Sun, 26 Oct 2008 09:41:39 -0700
>>   >    From: Michael R Sweet <msweet@apple.com>
>>   >
>>   >    Unless we want the print dialog to pass the XML data needed by the
>>   >    driver (not a good idea IMHO), that data will need to be on the
>>   >    "server" (I use quotes because most of the printing done to
>>   >    consumer/ prosumer inkjets is done from a single system) and then
>>   >    referenced by the print dialog, probably via an option choice
>>   >    and/or preset that is passed instead.
>>   >
>>   > Why would it be a bad idea to pass it in from the client?
>>
>>   Oh, I don't know, maybe just that passing a shitload of real numbers
>>   with every print job is incredibly inefficient and totally non-user-
>>   friendly?
>>
>>   For example, you'd be looking at 1MB of data for 16-bit LUTs for an 8
>>   color printer.  I hope you've been working on your typing!
>>
>> That's why I think the dialog should be able to grab per-user presets
>> out of a client-side .cups_presets or whatever file.
> 
> The latter would introduce another new kind of file type
> (beside ~/cups/.lpoptions).
> 
> 
> What about having the possibility sending print job options
> which are actually bigger pieces of whatever data
> as print job files and have well known predefined MIME rules
> on the server so that only on the server there is the special
> knowledge that whatever special data type as print job file
> is actually a job option?
> 
> E.g. something like
> 
> lp -d queue-name file.optiondata file.postscript
> 
> I think a problem is how to avoid that file.optiondata
> is actually printed on an older CUPS version server.
> 
> Perhaps it could work to have its MIME type so that
> on an older version server it is recognized as
> application/octet-stream
> so that such data is not printed by default?
> 
> 
> Perhaps it would be better (i.e. cause less conflicts)
> when a normal user could upload a print job options file
> to the server e.g. via
> 
> lp -d queue-name -o job-options-upload file.optiondata
> 
> and use it later as often as he likes via
> 
> lp -d queue-name -o job-options-file=file.optiondata file.postscript
> 
> The server would store the uploaded job options files
> separated for each user name.
> 
> The server should have appropriate "MaxJobOptionsFiles" and
> "MaxJobOptionsFilesPerUser" settings with reasonable defaults
> in its cupsd.conf file.

CUPS has a concept for that and Gutenprint already supports it for head 
cleaning. The command file "printing" concept. You send a file with 
special commands and the mime.types system of CUPS recognizes it as 
command file, directing it into a "commandto..." filter supplied by the 
Gutenprint package. This "commandto..." filter could also save advanced 
options per-user and Gutenprint's "rastertogutenprint" filter could read 
them according to the user name of the sending user. A certain command 
in a command file could also send back the current configuration, so 
that the user can see his settings.

As CUPS filters are all run by the "lp" user, all settings are stored in 
a file (system) with read/write access by "lp".

The command files do not need to be hand-written, they can be created by 
the advanced settings GUI of Gutenprint and/or by the GIMP plug-in. They 
can also be of arbitrary length, for example with an embedded ICC profile.

Disadvantage of the concept is that users cannot configure while the 
printer is printing (if one does not create an extra queue only for 
configuring, but this would look ugly in the printing dialogs of 
applications).

    Till

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Till Kamppeter]

Till Kamppeter wrote:
> 
> CUPS has a concept for that and Gutenprint already supports it for head 
> cleaning. The command file "printing" concept. You send a file with 
> special commands and the mime.types system of CUPS recognizes it as 
> command file, directing it into a "commandto..." filter supplied by the 
> Gutenprint package. This "commandto..." filter could also save advanced 
> options per-user and Gutenprint's "rastertogutenprint" filter could read 
> them according to the user name of the sending user. A certain command 
> in a command file could also send back the current configuration, so 
> that the user can see his settings.
> 
> As CUPS filters are all run by the "lp" user, all settings are stored in 
> a file (system) with read/write access by "lp".
> 
> The command files do not need to be hand-written, they can be created by 
> the advanced settings GUI of Gutenprint and/or by the GIMP plug-in. They 
> can also be of arbitrary length, for example with an embedded ICC profile.
> 
> Disadvantage of the concept is that users cannot configure while the 
> printer is printing (if one does not create an extra queue only for 
> configuring, but this would look ugly in the printing dialogs of 
> applications).
> 
>    Till
> 

This approach would be a concept where user settings are saved on the 
print server, So one user (identified by his user name) can use the 
settings from several clients.

The options and quick preset buttons in the Common Printing Dialog 
cannot be influenced by the user's settings, They depend solely on the 
PPD file and each print queue has only one PPD which does not change 
depending on the requesting user.

To let one and the same user save several settings, he would need to 
have a fixed amount of "slots" on the server and the PPD should contain 
an options to select one of the "slots". There can be special quick 
preset buttons for that or it can simply be an option which appears 
somewhere in the dialog.


Another concept would be the following:

Let us assume that CUPS can take options with arbitrary string length 
(Mike, is this correct?). Then we could send an arbitrary file containg, 
option settings, ICC profiles, job ticket, ... as argument of an option. 
Only condition is that the expression is ASCII without spaces, but we 
can UU-encode binary files.

The Gutenprint driver (rastertogutenprint) could accept a string option 
named "FineTuning" which takes the configuration file which the user's 
fine adjustment GUI for Gutenprint generates as one long string. 
rastertogutenprint reads the option from the fifth command line argument.

So the user sets a lot of fine adjustments, and also selects an ICC 
profile with Gutenprint's advanced settings GUI. The GUI puts the 
settings into an ASCII representation and saves this representation in 
~/.cups/lpoptions as a huge line like:

Dest epson FineTuning=blablabla...

Then CUPS sends this string with every job to the server and 
rastertogutenprint parses these settings and uses them.

The FineTuning option will not be mentioned in the PPD files, so that it 
does not appear in the printing dialogs.

With this approach there does not need to be saved any user data on the 
server, the user can tune and save settings whenever he wants, also 
while the printer printer is printing. The user can also save any number 
of settings using CUPS' concept of printer instances.

Disadvantage is that all configuration info is in the user's home 
directory on the client. If he accesses with several clients, the 
clients do not provide necessarily the same settings. Also the length of 
the string which can be passed with one option can be limited, but here 
pne could perhaps let rastertogutenprint accept more than one "hidden" 
option.

WDYT? Which of the two approaches should we use? The server-centralized 
way controlled by the user's client GUI "printing" command files or the 
client-based solution where the GUI saves the options as personal 
settings and they get submitted with every print job?

    Till

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Alastair M. Robinson]

Hi :)

Robert Krawitz wrote:

> I've been reading all this, but not responding; partly I've been busy
> and partly I'm curious what other folks think.

Ditto - I've been following the posts but not taking part for the last 
few days, though I have fleshed out the Wiki a little since my last mail 
on the subject.

> I'm still not a fan of requiring administrative privileges to use
> particular driver options of this kind that don't affect persistent
> state within the printer (and hence might have security implications).

Security implications are something I've been thinking about, actually. 
  In theory, it's possible for a printer to be damaged by feeding it 
pathological input.  Colour laser printers respond badly, I believe, to 
being asked to print a solid page of 100% C+M+Y+K.  Malicious 
linearization curves could potentially result in flooding an inkjet, 
too, I'd imagine.

> If something doesn't affect the system configuration or integrity it
> shouldn't require administrative privilege.

Agreed.  Our difficulty is allowing users to set these options in a way 
that makes them accessible to the driver running on the server but 
doesn't affect other users' jobs.

(Note that the current CUPS configuration as shipped by Ubuntu - at 
least in 8.04 - fails on this point.  Any user with lp privileges can 
set printer options which affect all other users.)

Oh, one other thing I've been wondering - are there currently, or are 
there likely to be in future, any printer models which support 
head-alignment, but don't have built-in persistent storage for that 
alignment?

> But I suppose I'm on the
> extreme end of maximum configurability and exposing (appropriately --
> which I might define differently from others) every possible option to
> the user, even if it allows someone to do absolutely absurd things.

"UNIX was not designed to stop its users from doing stupid things, as 
that would also stop them from doing clever things."  --  Doug Gwyn

> But there is a free RIP around Gutenprint (PhotoPrint) that could be
> extended to allow people to do this,

True - when I eventually get round to supporting curves!

> So the question is, how do we move along to that point?

Earlier today I began "thinking aloud" on that subject on the Wiki, and 
took the first steps to adding "DeviceN" support to PhotoPrint's imaging 
stack, in preparation for printing out raw per-channel linearization 
targets.

Could you outline roughly how you currently go about tuning a new, 
unknown printer, step-by-step?  Understanding the steps and the order in 
which they occur may be helpful in figuring out where the colour 
instrument can help with the process, and how best to go about making 
the results shareable.

All the best,
--
Alastair M. Robinson

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Till Kamppeter]

Alastair M. Robinson wrote:
> Hi :)
> 
> Robert Krawitz wrote:
> 
>> When you get right down to it, Gutenprint at its core really is a
>> hardware driver (or a package of hardware drivers).  It's not an
>> application the way GIMP is -- it's a piece of infrastructure.
> 
> True - however it doesn't have the luxury enjoyed by other pieces of 
> infrastructure of being isolated from end-users.  If I go to 
> localhost:631, click on my printer and hit Set Printer Options, I see a 
> user-interface.  CUPS *presents* this user-interface, but which controls 
> I see and how they're grouped is determined by Gutenprint.  It may not 
> be an application, but there are user-facing aspects.
> 
> Incidentally, Peter, if an option exists in the PPD but isn't tagged, 
> what happens?  Will it appear in the Common Printing Dialog?
> And what happens if an APPrinterPreset specifies a value for an untagged 
> option?  Will it still be set?
>

See my specs of the PPD extensions for the Common Printing Dialog:

http://www.linuxfoundation.org/en/OpenPrinting/PPDExtensions

Untagged PPDs will use the PPD groups as tags as a fallback. So options 
will be shown in a reasonable order, But the advantage of one option 
baing able to have more than one tag is not made use of with this fallback.

Each APPrinterPreset will create a quick preset button in the left 
column of the dialog. And the button will always set all options which 
it is supposed to set, independent of tags and groups.

> I'm just wondering whether we can tag options which "fit" with the 
> Common Printing Dialog, and leave the others in the PPD but untagged?
> 

If we leave options untagged or if we have too many tags, all these 
options will fall under the last tag. So if we have many of them, the 
last tag will get very crowded. This is more intended as a legacy 
fallback, for example for manufacturer-supplied PPDs.

    Till

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Till Kamppeter]

Robert Krawitz wrote:
>    Date: Sun, 26 Oct 2008 00:38:58 +0200
>    From: Till Kamppeter <till.kamppeter@gmail.com>
>    MIME-Version: 1.0
>    CC: Robert Krawitz <rlk@alum.mit.edu>,
> 	   printing-architecture@lists.linux-foundation.org,
> 	   gimp-print-devel@lists.sourceforge.net, peter@mmiworks.net
>    Content-Type: text/plain; charset=UTF-8; format=flowed
> 
>    Alastair M. Robinson wrote:
>    > Hi :)
>    > 
>    > Robert Krawitz wrote:
>    > 
>    >> When you get right down to it, Gutenprint at its core really is a
>    >> hardware driver (or a package of hardware drivers).  It's not an
>    >> application the way GIMP is -- it's a piece of infrastructure.
>    > 
>    > True - however it doesn't have the luxury enjoyed by other pieces of 
>    > infrastructure of being isolated from end-users.  If I go to 
>    > localhost:631, click on my printer and hit Set Printer Options, I see a 
>    > user-interface.  CUPS *presents* this user-interface, but which controls 
>    > I see and how they're grouped is determined by Gutenprint.  It may not 
>    > be an application, but there are user-facing aspects.
>    > 
>    > Incidentally, Peter, if an option exists in the PPD but isn't tagged, 
>    > what happens?  Will it appear in the Common Printing Dialog?
>    > And what happens if an APPrinterPreset specifies a value for an untagged 
>    > option?  Will it still be set?
> 
>    See my specs of the PPD extensions for the Common Printing Dialog:
> 
>    http://www.linuxfoundation.org/en/OpenPrinting/PPDExtensions
> 
>    Untagged PPDs will use the PPD groups as tags as a fallback. So options 
>    will be shown in a reasonable order, But the advantage of one option 
>    baing able to have more than one tag is not made use of with this fallback.
> 
> What happens if there are more than 11 or what have you PPD groups?
> Same as what you describe below?
> 

Yes.

>    Each APPrinterPreset will create a quick preset button in the left
>    column of the dialog. And the button will always set all options
>    which it is supposed to set, independent of tags and groups.
> 
> What's the upper limit on the number of presets?
> 

There is no upper limit defined. Peter, what should happen if there are 
too many quick preset buttons to fit into the area on the left?

    Till

Re: [Printing-architecture] [Gimp-print-devel] [Openicc] Looking ahead to 5.3

[Hal V. Engel]

On Monday 20 October 2008 17:26:49 Robert Krawitz wrote:
>    From: "Hal V. Engel" <hvengel@astound.net>
>    Date: Mon, 20 Oct 2008 14:03:25 -0700
>
>    On Monday 20 October 2008 09:37:40 Michael R Sweet wrote:
>    > If we
>    > also want to profile the individual color channels and modify the
>    > RGB-to-DeviceN and CMYK-to-DeviceN mappings, I recommend having a
>    > printer command (using the same interface we add for status
>    > monitoring and head alignment) that prints the linearization target(s)
>    > instead, with enough parameters to satisfy Robert. :)
>
>    This would be ideal but would require some work by the driver suppliers.
>
> Right -- and that's what we (Gutenprint) need requirements for.

I wish I had more expertise in this specific area so that I could provide 
those requirements at some level of detail.  I think for the most part that 
the GutenPrint Epson drivers are now well positioned for this but I don't know 
that for sure.  I know that Graeme Gill started working on a set of utilities 
to create linearization corrections but I think he got side tracked with other 
work.  Graeme at one time worked for a RIP vendor and he is the open source 
subject matter expert in this area. 

>
> Actually, for printing linearization targets you really don't want any
> of the fancy options.  The elaborate options are more for unmanaged
> environments or for people who have funky inks or papers.  You'd use
> Raw or Density color correction mode, either with CMYK or DeviceN
> input (which is also confusingly enough called Raw, but in a different
> context).
>
> We currently have a test pattern generator that can do a lot of this
> stuff, but it could also be done through the CUPS interface.
>
>    > I'd then also suggest that we add support for user profiles and/or
>    > drivers, such that a user could "install" XML files that would be
>    > "merged" with the standard/base files included with Gutenprint to
>    > determine which drivers, media types, ink sets, etc. are available.
>
>    Clearly something like this is needed both to support the
>    calibration and profiling process and to expose this in the UI and
>    to allow admins to control printer setup for users.
>
> We do have STP_DATA_PATH.  It won't really let you merge data in quite
> this way; you'd have to copy the file from the system path into the
> user path.  Then there's the matter of getting the PPD files in sync
> with this (you might add new media types to the customized data file),
> and getting an arbitrary file through CUPS somehow.
>
>    > All that would be necessary after that would be an application
>    > that prints the targets, measures then, generates the profiles,
>
>    We already have much of this for the ICC profile part but we
>    currently do not have anything for handing the
>    calibration/linearization part.
>
> This seems to be one of the sticky areas.

Agreed but there is lots of other work to be done to get the printing work 
flow to use ICC profiles.  Since this should be the highest priority CM 
related printing project I think that we should not be too concerned about 
calibration/linearization issues until that is in place.

>
>    > and
>    > installs them so they can be used by Gutenprint.  (Yes, I am aware
>    > that this is probably the most difficult part of the
>    > implementation...)
>
>    Yes It is probably the most involved part of this and I think it
>    will be some time before we can tackle the
>    calibration/linearization part of this.  I think the focus should
>    be on making the printing work flow and UI function correctly with
>    RGB and CMYK ICC profiles since we already have software to handle
>    the creation of these profiles and to implement
>    calibration/linearization and device-N support after basic ICC
>    profile support is in place.  I think it should be possible to have
>    this all working correctly with ICC profiles, at least with
>    development versions of the various software systems involved, with
>    in the next 6 to 12 months.
>
> That sounds like you're taking a longer-term view about Gutenprint and
> aren't looking for any short-term changes.  Is that correct?

From a color management perspective that is correct.  I think the current 
focus should be on getting the rest of the printing work flow so that it uses 
ICC profiles in the *toraster filters (at least with PDF input files).  This 
would make basic CM ubiquitous and driver independent.   That would still 
leave lots of related work for those that support the drivers.  For example, 
as ICC profile support was being added to the printing work flow printer 
vendors and driver authors would need to think about things like what default 
ICC profiles would ship with the drivers and issues related to this with PPD 
files, for example incorrect paths for cupsICCProfile settings, would need to 
be fixed.   

On the other hand there is no reason that work on instrument driven 
calibration/linearization couldn't be going on in parallel since these are not 
dependent on each other and in the end we do want both capabilities.  But I 
think this is a lower priority. 

Calibration/linearization would involve work at the driver/GutenPrint level 
but it sounds to me like the work that was done on the Epson drivers to make 
things data driven rather than hard coded has positioned those drivers to make 
that work possible although there may be more things that need to be done.  
It also sounds like this same work needs to be done with other GutenPrint 
drivers like the Canon driver.  Perhaps getting all of the drivers into the 
same state should be the current focus of GutenPrint with respect to color 
management.  

From my point of view I want to avoid trying to take steps that are so big 
that it causes significant resistance (IE. I don't want to overwhelm the teams 
working on the printing related stuff) and I would like to see this broken 
down into a series of smaller easier to accomplish steps that each build on 
the previous steps. 

Hal

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Hal V. Engel]

On Sunday 26 October 2008 09:55:06 Michael R Sweet wrote:
> Robert Krawitz wrote:
> >    Date: Sun, 26 Oct 2008 01:18:30 +0000
> >    From: "Alastair M. Robinson" <blackfive@fakenhamweb.co.uk>
> >
> >    Robert Krawitz wrote:
> >    > Why does it have to be server-side?  The print dialog could
> >    > implement it.
> >
> >    Well, this whole discussion started with the question of how
> >    gutenprint will work with the Common Printing Dialog.
> >
> > Yeah, well, I'm not assuming that the implementation (at least) of the
> > CPD can't be changed.  Nor am I assuming that CUPS can't be changed
> > (which it would need to be anyway, in order to handle curves).  This
>
> Um, CUPS doesn't have to be changed to support curves aka LUTs - the
> existing 1setOf functionality handles arbitrarily long arrays of data.
>
> Whether it makes sense to pass all that data as part of the job is
> another matter - I personally don't believe it does since it is
> highly driver-specific and something the user is likely to generate
> once and reference multiple times.

I agree with this.

>
> IOW, I don't see a user (or program) doing this:
>
>      lp -o gutenprint-cyan-curve=0,0.01,0.012,...,1.0 filename
>
> Instead, I would expect them to use:
>
>      lp -o stpUserProfile=AcmeLustreGray filename
>
> where "AcmeLustreGray" is a profile that the user created using a
> Gutenprint-specific profiling/admin application.  This profile would
> be "installed" on the system that is actually doing the printing.
> This would not necessarily require root privileges to do as user-
> specific profile directories are easy to do and CUPS does not require
> root access to update a printer as long as the distro/OS puts users in
> the system group (lpadmin or sys depending on the system).

I am a little confused (sorry).  I can't find any documentation on 
stpUserProfile anywhere.   Could you provide an explanation?

Hal
 

Re: [Printing-architecture] [Gimp-print-devel] Looking ahead to 5.3

[Hal V. Engel]

On Sunday 26 October 2008 12:04:02 Robert Krawitz wrote:
>    From: "Hal V. Engel" <hvengel@astound.net>
>    Date: Sun, 26 Oct 2008 11:40:26 -0700
>
>    On Sunday 26 October 2008 09:55:06 Michael R Sweet wrote:
>    > Robert Krawitz wrote:
>    > >    Date: Sun, 26 Oct 2008 01:18:30 +0000
>    > >    From: "Alastair M. Robinson" <blackfive@fakenhamweb.co.uk>
>    > >
>    > >    Robert Krawitz wrote:
>    > >    > Why does it have to be server-side?  The print dialog could
>    > >    > implement it.
>    > >
>    > >    Well, this whole discussion started with the question of how
>    > >    gutenprint will work with the Common Printing Dialog.
>    > >
>    > > Yeah, well, I'm not assuming that the implementation (at least) of
>    > > the CPD can't be changed.  Nor am I assuming that CUPS can't be
>    > > changed (which it would need to be anyway, in order to handle
>    > > curves).  This
>    >
>    > Um, CUPS doesn't have to be changed to support curves aka LUTs - the
>    > existing 1setOf functionality handles arbitrarily long arrays of data.
>    >
>    > Whether it makes sense to pass all that data as part of the job is
>    > another matter - I personally don't believe it does since it is
>    > highly driver-specific and something the user is likely to generate
>    > once and reference multiple times.
>
>    I agree with this.
>
> I don't disagree.  I just don't think that the fact that something's
> not likely to be done all that often is a good reason to consider it
> an "administrative" task that requires administrator privilege.

I didn't read Michael's statement as saying that this would always require 
administrative privilege.  What I was agreeing with was that this was a create 
once (or at least only once in a while) and use often type of thing.  Because 
of that I think that it makes sense to avoid transmitting this data to the 
print server for every job if possible.  But I also agree with you that it 
should be possible for ordinarily users to create calibration data sets and 
use them without the need for administrative rights.  If that use case means 
that the calibration data needs to be passed to the back end with each job 
then that must be allowed but that also implies that there is a way to pass a 
file and other than the actual document to be printed I don't think this is 
allowed for files that are not installed in the /usr/cups/... directories.
  
>
>    > IOW, I don't see a user (or program) doing this:
>    >
>    >      lp -o gutenprint-cyan-curve=0,0.01,0.012,...,1.0 filename
>    >
>    > Instead, I would expect them to use:
>    >
>    >      lp -o stpUserProfile=AcmeLustreGray filename
>    >
>    > where "AcmeLustreGray" is a profile that the user created using a
>    > Gutenprint-specific profiling/admin application.  This profile would
>    > be "installed" on the system that is actually doing the printing.
>    > This would not necessarily require root privileges to do as user-
>    > specific profile directories are easy to do and CUPS does not require
>    > root access to update a printer as long as the distro/OS puts users in
>    > the system group (lpadmin or sys depending on the system).
>
>    I am a little confused (sorry).  I can't find any documentation on
>    stpUserProfile anywhere.   Could you provide an explanation?
>
> It doesn't exist, at least right now -- Mike was just using this as an
> example.

So something like this would be a new driver option that would be added to the 
GutenPrint driver that could be set to point to a calibration file that would 
be used by the driver?  Of course this implies that users can somehow setup a 
"AcmeLustreGray" calibration data set so that a driver like GutenPrint could 
use it.  Another source of confusion for me is that I though that the 
/usr/share/cups/profiles directory was for ICC profiles but I guess that could 
also contain calibration data sets.  

The other issue is how would this work in the general case?  I could see this 
being OK, but perhaps not ideal,  when the print server is located on the same 
machine as the users.  But what happens if the print server is located on the 
network or what if the printer is shared (which is the same as being on the 
network)?  How would users "install" their own ICC Profiles and calibration 
data sets?  In addition for network printers with administratively installed 
ICC profiles and calibration data sets how can these be discovered by 
ordinarily users so that these can be used?  For calibration data this is a 
smaller issue since users do not need to have direct access to the calibration 
data since these could be encapsulated and hidden in presets that were created 
by the administrator that would show up in the CPD.  But users do need to be 
able to discover and get copies of ICC profiles to be able to do soft proofing 
and this would not be possible on a networked printer at least not without 
some new features in the print system.   

For the new PDF printing work flow the ICC Profile issues could become moot if 
things are properly designed.  The PDF format allows for there to be an 
embedded output profile as well as profiles for individual objects in the 
document and the PDF specification calls for PDF rasterization software to use 
that output profile if it finds one in the file.  In other words the PDF 
document file could be used to transmit the output profile information to the 
print server and then the requirement that output profiles be located in a 
certain location goes away.  Of course this functionality would have to be 
implemented in the CPD and the rest of the printing work flow since it is 
currently unsupported.  

Hal