[Printing-architecture] Next OP SC - Mon/Tue - 1/2 December 2008 - please join us

[Printing-architecture] Next OP SC - Mon/Tue - 1/2 December 2008 - please join us

[Ira McDonald]

Hi,

Till - thanks very much for getting us a new stable phone number!

The next Open Printing Steering Committee meeting will be on:

   - Monday 1 December 2008, Evening
      - US
        3pm in San Francisco - US PST (Pacific Standard Time)
        4pm in Colorado - US MST (Mountain Standard Time)
        5pm in Chicago - US CST (Central Standard Time)
        6pm in New York - US EST (Eastern Standard Time)

    - Tuesday 2 December 2008, Morning
      - Europe
        12am in Berlin - CET (Central European Time)
      - Japan
        8am in Tokyo - JST (Japan Standard Time)

    * Main Number (InstantConference.com)
      International: +1-218-936-7999
      Access Code:   491659#

Please call-in and join us.

Cheers,
- Ira

PS - I will be at Samsung in Irvine, CA this coming Monday,
so I will be calling in from there - it's *possible* that urgent
Samsung meetings will intervene - if so, please carry on
without me.

PPS - Till - would you send out an agenda?  I'll be travelling
for the next four days.


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic@gmail.com
winter:
  579 Park Place  Saline, MI  48176
  734-944-0094
summer:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

Re: [Printing-architecture] Next OP SC - Mon/Tue - 1/2 December 2008 - please join us

[Till Kamppeter]

Ira, thanks for posting another reminder.

Agenda:

- Year end and marketing report: Anything missing? To be changed?
   See the report below. It will be used by the LF marketing to be put
   into the web site and also presented to the printer manufacturers \
   which are LF members to inform them what is going on.

- News:
    o Foomatic 4.0 shortly before release
    o Subhankar Sett will soon continue to work on a web app for admin of
      the OP Server
    o Funding needed for Lars Uebernickel to do Common Printing Dialog

- Any news from Japan? From somewhere else? I saw Norm reporting a bug
   on CUPS. He seems to be back!

Hope to hear you all in one and a half hours.

    Till

Ira McDonald wrote:
> Hi,
> 
> Till - thanks very much for getting us a new stable phone number!
> 
> The next Open Printing Steering Committee meeting will be on:
> 
>    - Monday 1 December 2008, Evening
>       - US
>         3pm in San Francisco - US PST (Pacific Standard Time)
>         4pm in Colorado - US MST (Mountain Standard Time)
>         5pm in Chicago - US CST (Central Standard Time)
>         6pm in New York - US EST (Eastern Standard Time)
> 
>     - Tuesday 2 December 2008, Morning
>       - Europe
>         12am in Berlin - CET (Central European Time)
>       - Japan
>         8am in Tokyo - JST (Japan Standard Time)
> 
>     * Main Number (InstantConference.com)
>       International: +1-218-936-7999
>       Access Code:   491659#
> 
> Please call-in and join us.
> 
> Cheers,
> - Ira
> 
> PS - I will be at Samsung in Irvine, CA this coming Monday,
> so I will be calling in from there - it's *possible* that urgent
> Samsung meetings will intervene - if so, please carry on
> without me.
> 
> PPS - Till - would you send out an agenda?  I'll be travelling
> for the next four days.
> 
> 
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music/High North Inc
> email: blueroofmusic@gmail.com
> winter:
>   579 Park Place  Saline, MI  48176
>   734-944-0094
> summer:
>   PO Box 221  Grand Marais, MI 49839
>   906-494-2434
> 

Re: [Printing-architecture] Next OP SC - Mon/Tue - 1/2 December 2008 - please join us

[Till Kamppeter]

I forgot the report. Here we go.

    Till

----------------------------------------------------------------------


1. OpenPrinting Database
------------------------

http://www.openprinting.org/
http://openprinting.org/driver_list.cgi
http://openprinting.org/printer_list.cgi
http://www.linux-foundation.org/en/OpenPrinting/Database/DriverPackages

- Database of all printers for which is known whether they work or do
not work under Linux. Information collected by users and printer
manufacturers. Includes information about which drivers work, which ones
are recommended, which ones deprecated, ... Users can directly
contribute comments and new printer entries.

- Database generates PPD files for many free software drivers,
especially the built-in drivers of Ghostscript.

- Database hosts ready-made PPD files from printer manufacturers, mostly
for PostScript printers, but also for PCL printers using Ghostscript
drivers.

- Database hosts also LSB-based RPM and Debian packages of drivers.
These packages can get installed on all LSB-compliant Linux
distributions. This simplifies driver installation for users (no
compiling, one package for all distros) and driver packaging for driver
developers and printer manufacturers (One LSB RPM for all distros, less
packaging and testing work and cost). The package repositories are
indexed for automatic updates with the distro's package managers (apt,
yum, ...).

- Web query API for automatic look-up of driver packages and PPDs. This
allows printer setup tools and (like system-config-printer) and driver
managers (like Jockey) to automatically find suitable drivers for an
auto-detected printer, and to download and install them automatically.

http://www.linuxfoundation.org/en/OpenPrinting/Database/Query

- Foomatic software for use of local copies of the database and
integration of all printer drivers with the printing systems. This is a
core part of the printing infrastructure in all distributions.

- I am working together with the printer manufacturers to help them
packaging the drivers and with developers of configuration tools
(system-config-printer by Tim Waugh, used by default in Fedora/Red Hat,
Ubuntu, an Mandriva; Jockey by Martin Pitt, working for the LF's Driver
Backports group),

- 1 GSoC 2008 student has worked on a web application for administration 
of user contributions and uploads and he is still working on it. He will 
work on it full time in his project semester Dec 2008 - May 2009.

- I am also taking care of keeping the system running and adapting it to 
the increasing traffic.


2. Common Printing Dialog
-------------------------

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

- I have organized the development of a Common Printing Dialog for all
applications and desktops to make printing easier by having only one
dialog with access to all functionality without being overloaded.

- The design was done by OpenUsability people who met regularly on the
Printing Summits organized be me and on an additional meeting (2006-2008).

http://wiki.openusability.org/printing/index.php/Specification

- The implementation is mostly done by two GSoC 2008 students: Dialogs 
for KDE and GNOME and a D-Bus API to call the dialogs out of 
applications. Patches for Qt/KDE and GTK/GNOME libraries to make most 
applications using the new dialogs are planned. Big part of the 
mentoring of the students was done by me.

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

- During the implementation work period of the GSoC 2008 students I have 
designed specs for PPD extensions so that driver developers/printer 
manufacturers can make use of the dialog's functionality to present 
their driver's user-settable options.

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


3. PDF as standard print job format
-----------------------------------

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

I have coordinated the replacement of PostScript by PDF as the standard
print job format and created a reference implementation in the upcoming
Ubuntu 8.10 (Intrepid) distribution. Bug reports in the Ubuntu bug 
tracking system stabilized and matured the new filters.

Several CUPS filters for handling PDF were implemented by OpenPrinting 
Japan. I have evaluated and tested them and checked their ability to be 
packageable for Linux distribution. I told the people of OP Japan what 
needed to get changed and where there are bugs and they fixed it.

Other CUPS filters where done by a Google Summer of Code student. I have 
done part of the mentoring here.

foomatic-rip was made capable to take PDF input by a student who worked 
on an internship at the Linux Foundation. He worked under my supervision.

I have also reported several bugs and feature requests to Ghostscript, 
CUPS, OpenOffice, ... to make the PDF workflow work and to move it 
forward. I have also fixed several bugs in Ghostscript and the filters 
by myself.


4. Printing Summits and other meetings
--------------------------------------

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

Organization of yearly Printing Summits (on the Linux Foundation
Collaboration Summit from 2009 on) where all important people having to 
do with printing under Linux will meet: Printer manufacturers, Linux 
distribution developers, desktop, application, driver, core printing 
system developers. Here the future development is planned and important 
decisions are made.

Organization of additional meetings if needed, for example meetings with 
the Japanese OpenPrinting workgroup and printer manufacturers in Tokyo 
(Nov 2007, July 2008).


5. Coordination/Integration of printing-related free software projects
----------------------------------------------------------------------

General: Reporting bugs to CUPS, Ghostscript, and driver projects, also
fixing smaller bugs. Participation in development discussion.
Cooordination between the projects. Bug and incompatibility workarounds
via Foomatic.

Ghostscript: Merge of ESP Ghostscript with GPL Ghostscript so that
distros can use the newest GPL Ghostscript with all drivers (beginning 
of 2007).

In 2008 several bug fixes, like Duplex, Resolution, and InputSlot for 
PCL-XL drivers (pxlmono/pxlcolor), discussion with GS developers about 
further development, driver integration, PDF capabilities, ...

CUPS: Bug reports feature requests, development discussion, also some
bug fixes.

HPLIP: Testing on real printers (supplied by HP through USD 10000 PO 
July 2007-June 2008, new USD 10000 PO 2008/2009 in place), bug fixes, 
development discussion.


6. Development and creation of printing APIs for Linux/Unix
-----------------------------------------------------------

http://www.linuxfoundation.org/en/OpenPrinting/PAPI
http://www.linuxfoundation.org/en/OpenPrinting/JTAPI
http://www.linuxfoundation.org/en/OpenPrinting/APAC

Printing API (PAPI), Job Ticket API (JTAPI), Printer Driver API (PDAPI, 
OpenPrinting Vector), ...

1 Google Summer of Code 2008 student has done the CUPS implementation of 
PAPI.


7. Organization of the GSoC 2008 participation of the Linux Foundation
----------------------------------------------------------------------

http://www.linuxfoundation.org/en/OpenPrinting
http://code.google.com/soc/
http://code.google.com/soc/2008/linux/about.html
http://www.linuxfoundation.org/en/Google_Summer_of_Code

Application for the Linux Foundation as mentoring organization, setup of 
project ideas, evaluation of student applications and assigning them to 
projects and mentors, reminding mentors and students to deadlines, 
mentoring work on the Common Printing Dialog, the OpenPrinting Database 
Admin web app, the PDF filters, ...


8. OpenPrinting Steering Committee
----------------------------------

Monthly phone meetings to plan the actions of OpenPrinting, report about 
what got done, organize meetings, ...


9. Printing Requirements in the LSB
-----------------------------------

I have made important printing-related requirements going into the LSB, 
which is very important to make distribution-independent printer driver 
packages possible.

http://www.linuxfoundation.org/en/Specifications
http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Printing/LSB-Printing/book1.html


Future plans
------------

In addition to the continuation on the topics mentioned above, we plan 
to do the follwing:

1. Printer (hardware) testing and self-verification program with branding

We need to create a procedure for that, so that hardware vendors can 
tell potential customers that there devices work with Linux

2. Integrating color management as standard part into the printing 
workflow. In Mac OS X this is already standard. In Linux this is really 
missing. The PDF printing workflow is already the first step towards it.

3. Having more eyes on desktops and applications, about which printing 
dialogs they use the quality of their PostScript or PDF output, whether 
they switched already to PDF, ...., rgreesions,...

4. Organize the next OpenPrinting Summit as part of the Linux Foundation 
Collaboration Summit in April (?) 2009.




Till Kamppeter wrote:
> Ira, thanks for posting another reminder.
> 
> Agenda:
> 
> - Year end and marketing report: Anything missing? To be changed?
>   See the report below. It will be used by the LF marketing to be put
>   into the web site and also presented to the printer manufacturers \
>   which are LF members to inform them what is going on.
> 
> - News:
>    o Foomatic 4.0 shortly before release
>    o Subhankar Sett will soon continue to work on a web app for admin of
>      the OP Server
>    o Funding needed for Lars Uebernickel to do Common Printing Dialog
> 
> - Any news from Japan? From somewhere else? I saw Norm reporting a bug
>   on CUPS. He seems to be back!
> 
> Hope to hear you all in one and a half hours.
> 
>    Till
> 

Re: [Printing-architecture] Next OP SC - Mon/Tue - 1/2 December 2008 - please join us

[Norm Jacobs]

Till Kamppeter wrote:
> Ira, thanks for posting another reminder.
>
> Agenda:
>
> - Year end and marketing report: Anything missing? To be changed?
>    See the report below. It will be used by the LF marketing to be put
>    into the web site and also presented to the printer manufacturers \
>    which are LF members to inform them what is going on.
>
> - News:
>     o Foomatic 4.0 shortly before release
>     o Subhankar Sett will soon continue to work on a web app for admin of
>       the OP Server
>     o Funding needed for Lars Uebernickel to do Common Printing Dialog
>
> - Any news from Japan? From somewhere else? I saw Norm reporting a bug
>    on CUPS. He seems to be back!
>   
I'm around, well, sort of.  I am still involved in printing and have 
many things that I would like to get done, but I also have another role 
at Sun that is eating up a very large chunk of my time.  I should be on 
in an hour.

       -Norm
> Hope to hear you all in one and a half hours.
>
>     Till
>
> Ira McDonald wrote:
>   
>> Hi,
>>
>> Till - thanks very much for getting us a new stable phone number!
>>
>> The next Open Printing Steering Committee meeting will be on:
>>
>>    - Monday 1 December 2008, Evening
>>       - US
>>         3pm in San Francisco - US PST (Pacific Standard Time)
>>         4pm in Colorado - US MST (Mountain Standard Time)
>>         5pm in Chicago - US CST (Central Standard Time)
>>         6pm in New York - US EST (Eastern Standard Time)
>>
>>     - Tuesday 2 December 2008, Morning
>>       - Europe
>>         12am in Berlin - CET (Central European Time)
>>       - Japan
>>         8am in Tokyo - JST (Japan Standard Time)
>>
>>     * Main Number (InstantConference.com)
>>       International: +1-218-936-7999
>>       Access Code:   491659#
>>
>> Please call-in and join us.
>>
>> Cheers,
>> - Ira
>>
>> PS - I will be at Samsung in Irvine, CA this coming Monday,
>> so I will be calling in from there - it's *possible* that urgent
>> Samsung meetings will intervene - if so, please carry on
>> without me.
>>
>> PPS - Till - would you send out an agenda?  I'll be travelling
>> for the next four days.
>>
>>
>> Ira McDonald (Musician / Software Architect)
>> Chair - Linux Foundation Open Printing WG
>> Blue Roof Music/High North Inc
>> email: blueroofmusic@gmail.com
>> winter:
>>   579 Park Place  Saline, MI  48176
>>   734-944-0094
>> summer:
>>   PO Box 221  Grand Marais, MI 49839
>>   906-494-2434
>>
>>     
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture
>   

[Printing-architecture] Last OP SC - Mon/Tue - 1/2 December 2008 - The Recording

[Till Kamppeter]

Hi,

InstantConference has an easy recording facility for phone meetings. If 
activated, one gets a download link for an MP3 file with the recording. 
I have transferred the file for the last OP Steering Committee meeting 
to the OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-steering-committee/OP-SC-Meeting-20081201.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

This SC Meeting was small. Only George Liu, Norm Jacobs, and me 
participated. Also not very important stuff was discussed. I reported 
some stuff of my activity, and Norm told about the development of the 
printing part of Solaris. They take more and more of the Linux printing 
stack: CUPS (should get standard with CUPS 1.4), system-config-printer 
(printer setup tool), hal-cups-utils (Plug'n'Print script), ... 
Foomatic, Ghostscript, HPIJS, and Gutenprint they used already. Norm 
showed also interest in printer driver download from OpenPrinting for 
Solaris.

I asked Norm also to tell about how successful he was with the work of 
his GSoC student to implement PAPI for CUPS. Norm told that they were 
not so successful and he also did not have enough time for the 
mentoring. We also concluded that PAPI will most probably not adopted, 
as we end up with CUPS everywhere. So we should better work more on 
existing de-facto standards than creating new things with the intention 
that they should get a standard in the future.

    Till

P. S.: The MP3 is 23 MB long, 73 minutes of talking.


Ira McDonald wrote:
> Hi,
> 
> Till - thanks very much for getting us a new stable phone number!
> 
> The next Open Printing Steering Committee meeting will be on:
> 
>    - Monday 1 December 2008, Evening
>       - US
>         3pm in San Francisco - US PST (Pacific Standard Time)
>         4pm in Colorado - US MST (Mountain Standard Time)
>         5pm in Chicago - US CST (Central Standard Time)
>         6pm in New York - US EST (Eastern Standard Time)
> 
>     - Tuesday 2 December 2008, Morning
>       - Europe
>         12am in Berlin - CET (Central European Time)
>       - Japan
>         8am in Tokyo - JST (Japan Standard Time)
> 
>     * Main Number (InstantConference.com)
>       International: +1-218-936-7999
>       Access Code:   491659#
> 
> Please call-in and join us.
> 
> Cheers,
> - Ira
> 
> PS - I will be at Samsung in Irvine, CA this coming Monday,
> so I will be calling in from there - it's *possible* that urgent
> Samsung meetings will intervene - if so, please carry on
> without me.
> 
> PPS - Till - would you send out an agenda?  I'll be travelling
> for the next four days.
> 
> 
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music/High North Inc
> email: blueroofmusic@gmail.com
> winter:
>   579 Park Place  Saline, MI  48176
>   734-944-0094
> summer:
>   PO Box 221  Grand Marais, MI 49839
>   906-494-2434
> 

[Printing-architecture] Last OP SC - Mon/Tue - 5/6 January 2009 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OP Steering Committee meeting
to the OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-steering-committee/OP-SC-Meeting-20090105.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 21 MB long, 65 minutes of talking.

[Printing-architecture] Last OP SC - Mon/Tue - 2/3 February 2009 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OP Steering Committee meeting
to the OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-steering-committee/OP-SC-Meeting-20090202.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 30 MB long, 1 hour, 26 minutes of talking.

Re: [Printing-architecture] Last OP SC - Mon/Tue - 2/3 February 2009 - The Recording

[Hal V. Engel]

On Tuesday 03 February 2009 02:46:16 pm you wrote:
> Hal V. Engel wrote:
> > Till,
> >
> > Just listened to the recording.  Thank you for making it available. There
> > are apparently some misconceptions about how color management works.   So
> > here is some feedback.
> >
> > It is not acceptable to use sRGB or any single color space as the only
> > acceptable or required document color space.  It appears that this is
> > something that comes up every time a new application starts looking at
> > color management.  For example, this same thing was discussed at length
> > when the GIMP developers started looking at CM and in the end they did
> > not use the "required color space" approach since the CM experts told
> > them not to (in very strong terms) and when they actually got into coding
> > it they discovered that is was actually counter productive and not
> > needed.
> >
> > User land applications should be able to send documents to the output
> > device (printer, monitor...) in any color space(s) it wants to use.  In
> > fact it is common for those doing color critical work to avoid sRGB since
> > it has a very limited gamut and it is common for devices like scanners
> > and cameras to have much larger gamuts (in many cases almost twice as
> > big).   So friends do not let friends use sRGB.  Keep in mind that this
> > is the document color space and it needs to have enough gamut for the
> > device that created the document and it's gamut has nothing to do with
> > the printers characteristics.
> >
> > The correct approach is allow the user land app to specify any document
> > color space (actually compound documents like pdf can have more than one
> > color space since pdf allows for each individual object in the document
> > to have it's own color space).  In fact there is no other reasonable
> > approach.  In addition it is typical for documents to have the document
> > color space(s) embedded in the document and since the document is passed
> > to the printing subsystem the document color space(s) are discoverable by
> > the *toraster filter.
> >
> > The consensus from discussions on the OpenICC list is that the only time
> > sRGB is used by default is when the user land application does not
> > explicitly pass a document color space(s) and any document or, for
> > compound documents, any object in the document that has an embedded ICC
> > profile has passed an explicit color space that must be used.  In fact if
> > the printing work flow is correctly designed there is no need to limit
> > what document color space(s) are used as this will be handled by the
> > color management engine when the *toraster filter sets up the color
> > transforms that it needs for the document it is handling.
> >
> > On the "OS level" you do NOT need agreement on what color space will be
> > used but rather what needs to be agreed to is how the transformations
> > from the document color space(s) to the output device color spaces will
> > be handled. There is work underway on this end of things by the OpenICC
> > folks. Specifically Oyranos which is a system wide CM configuration
> > management back end that is being worked on my Kai-Uwe Behrmann and for
> > KDE the Kolor Manager System Setting applet which is a KDE4 specific
> > Oyranos front end that is now in the playground area of the KDE svn
> > repository.  We hope to have Kolor Manager included in KDE 4.3. 
> > Currently Oyranos has no support for CM configuration of printers (the
> > only devices that currently have full support are monitors) and this is
> > an area that needs to be addressed along with scanners and cameras.  The
> > KDE front end was written as part of GSoC 2008 and there were lengthly
> > discussions during that effort about how all these other devices should
> > be supported.  In particular printers generated lots of interest and
> > there is some preliminary code in Kolor Manager related to printer CM
> > configuration along with similar code for scanners.  Our hope is to
> > introduce printer support into Oyranos and Kolor Manager as the CM parts
> > of the printing work flow are being developed.
> >
> > Rendering intent in the color management context has a limited number of
> > options most of these are defined by the ICC and are to some extent
> > standardized.  These are absolute colorimetric (no white point
> > transformation), relative colorimetric (this causes a white point
> > transformation), perceptual and saturation intent.  For relative
> > colormetric intent users can also select black point compensation to help
> > reduce the loss of shadow details when the transform is going to a device
> > with reduced gamut compared to the document color space.  So there are
> > actually 5 rendering intents and all of these are supported by LCMS.  So
> > all that actually needs to happen is that users can select the intent and
> > this gets passed through to the *toraster filter so the the transform
> > uses the correct intent when it creates the raster that is passed to the
> > printer.   At present most document formats do not have a standardized
> > way of embedding this information.
> >
> > There is a need for user land applications to be able to discover the
> > printer color space(s) (IE. profiles) so that applications can do soft
> > proofing.
> >
> > RAW is NOT a color space as that term is used in the color management
> > world.
> >
> > Hal
>
> Thank you for your mail. You have sent it to me in private, but I prefer
> to discuss it on the printing-architecture mailing list, could we post
> your mail there to start the discussion?

Yes I can do that.  I was not too sure where I should send it so I kept it 
private.

>
> So good to hear that the color correction 

Color Management types would say "color space transform" rather than "color 
correction" because this could also be doing things like taking an RGB (or XYZ 
or Lab) document and converting it into CMYK or even deviceN output for the 
printer.

> can be done completely on the
> server side. 

Doing the transform on the server would be the preferred way to handle this.  
Right now we are limited to doing this client side in the user land apps that 
are sending output to the print server.  This means we only have color managed 
printing in those apps that know how to do color managed printing which right 
now is a very limited set of apps (probably less then a dozen total but I can 
only think of three off hand and one of those is a specialized front end for 
gutenprint).  Having this functionality on the server side means that even CM 
dumb apps benefit once things are properly configured.

> A color-managed driver will then use an ICC profile in a
> standardized directory on the server and functions of a CM library to
> execute the color correction.  The PPD will have a "Rendering Intent"
> option with the choices mentioned in your mail, option and choices with
> standardized names for all printers. Option settings are passed to CUPS
> as IPP attributes and this way also the rendering intent gets to the
> driver. The driver will get all option settings by its command line.
> Perhaps color correction has too be better done by the renderer
> (Ghostscript or Poppler, Ghostscript preferred), as a raster image can
> have only one color space where as vector graphics, especially in PDF
> format, can have a separate color space for each object.

I think this assessment is correct.  In fact having this happen in the 
*toraster rendering filter makes things much simpler for everyone since doing 
this would eliminate the need to do any color management specific 
modifications to the individual drivers and it would also centralize this 
functionality in one place.  For example once GhostScript has been updated to 
have an up to date CM implementation (I think we should have at least 
development versions with this capability soon) and the new pdftoraster filter 
is setup to handle CM the new pdf based printing work flow will have 
functional CM for all apps using it, including apps that are not CM aware, no 
matter what printer/driver is being used.

As a side note Poppler has now been patched with preliminary CM functionality 
and the testing I did with it seemed to work OK.  So it might make sense to 
continue to use Poppler for the common printing dialog since it's CM support 
might be "good enough" for this use.  

>
> The ICC profile of each print queue also needs to be downloadable by the
> clients via CUPS' http server facility, so that apps (or the Common
> Printing Dialog) can get them for soft proofing.

Currently the CUPS API allows client side apps to get a list of profiles that 
are in cupsICCProfile lines in the PPD.  But there were several open issues 
with the CUPS implementation the last time I checked.  

1. If the CUPS server is not local there is no way to get the profile for soft 
proofing.

2. CUPS only allows passing a user specified printer profile on the command 
line if the profile is installed in a specific directory on the CUPS server 
and there is no way in the general case for a client app to get a list of 
these profiles or to get a copy of any of these profiles.

>
>     Till
>
>
> P. S.: Thank you for registering for the OpenPrinting Summit. You are
> welcome to attend and I am looking forward for the Color Management
> session. 

That is why I registered.  I live with in commuting distance of the conference 
which makes it fairly easy for me to attend.  So I guess that I will be the 
OpenICC representative there and perhaps there will be others as well.
 
> From the CM side not only you but also Michael	Vrhel
> (Ghostscript) is attending.

[Printing-architecture] Last OP SC - Mon/Tue - 9/10 March 2009 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OP Steering Committee meeting
to the OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-steering-committee/OP-SC-Meeting-20090309.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 15 MB long, 42 minutes of talking.

[Printing-architecture] Last OP Meeting - Mon/Tue - 4/5 May 2009 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the 
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20090504.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 22 MB long, 1 hour, 4 minutes of talking.

[Printing-architecture] Last OP Meeting - Mon/Tue - 1/2 June 2009 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20090601.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 18 MB long, 53 minutes of talking.

Re: [Printing-architecture] Last OP Meeting - Mon/Tue - 1/2 June 2009 - The Recording

[Hal V. Engel]

On Tuesday 02 June 2009 07:17:51 am Till Kamppeter wrote:
> Hi,
>
> I have uploaded the recording of the last OpenPrinting meeting to the
> OpenPrinting server:
>
> http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20
>090601.mp3
>
> In general, recorded meetings I will upload to
>
> http://www.openprinting.org/download/meetingnotes/
>
>     Till
>
> P. S.: The MP3 is 18 MB long, 53 minutes of talking.

ICC profile location/directory structure was talked about at the meeting. 

OpenICC recommends basing the location of ICC profiles on the XDG Base 
Directory Specification.   This is what is currently implemented in Oyranos.  

The current OpenICC specification for this can be found here: 

http://www.oyranos.org/wiki/index.php?title=OpenIccDirectoryProposal

also see:

http://bugs.freestandards.org/show_bug.cgi?id=77

This specification was initially promulgated in 2005 and has been through a 
number of revisions since then and is subject to additional changes going 
forward.   It should be possible to extend this to include printer specific 
requirements if this is needed.  For example one system wide location from 
this specification is

/usr/share/color

and all profiles there must be located in

/usr/share/color/icc

But the specification allows for things like:

/usr/share/color/icc/printer

and it is possible to do something like:

/usr/share/color/icc/printer/Epson

For printer profiles for Epson printers.  

or

/usr/share/color/icc/printer/Epson/R2400

or

/usr/share/color/icc/printer/GutenPrint-5.2/Epson_R2400

or even

/usr/share/color/icc/printer/GutenPrint-5.2/Epson/R2400

But presently no one is using anything beyond:

/usr/share/color/icc

That is everyone is currently using a fairly flat directory structure since 
most systems have a very limited number of profiles (at most a few dozen) and 
there does not appear to be any reason to go farther.  However on a system 
that is used as a print server with a large number of connected printers with 
dozens or hundreds of printer profiles an extended directory structure may 
make sense.  The specification allows for this but does not require it nor 
does it contain any details for what this extended directory structure would 
look like beyond the base <prefix>/share/color/icc/printer directory.

It might make sense to look at this in connection with the GSoC OpenICC 
Oyranos printer project.  This is also probably something that should be 
settled before CM is added to the pdf2raster CUPS filter so that CUPS can be 
updated to handle this correctly.

Hal

[Printing-architecture] Last OP Meeting - Tue - 7 July 2009 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20090707.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 19 MB long, 54 minutes of talking.

[Printing-architecture] Last OP Meeting - Mon - 17 Aug 2009 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20090817.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 19 MB long, 56 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 8 Sep 2009 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20090908.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 12 MB long, 36 minutes of talking.

[Printing-architecture] Last OP Meeting - Mon/Tue - 14/15 Sep 2009 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20090914.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 18 MB long, 51 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 3 Nov 2009 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20091103.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 15 MB long, 43 minutes of talking.

[Printing-architecture] Colour

[kate price]

I am working on the UI design of the CPD and  looking at the controls  
and parameters for colour, both as presets/profiles and as more  
detailed controls. Therefore, I'll need to get a good understanding of  
how this all works.

Including:
the workflow from application to printer
colour profiles
color management; in applications, and printer colour management.   
what happens where?
detailed user interaction: what controls need to be there?


Can someone point me in the right direction? Provide some useful  
information or sources of information?

Thanks in anticipation,


Kate

     man + machine interface works

Re: [Printing-architecture] Colour

[Hal V. Engel]

On Monday 09 November 2009 03:14:42 am kate price wrote:
> I am working on the UI design of the CPD and  looking at the controls
> and parameters for colour, both as presets/profiles and as more
> detailed controls. Therefore, I'll need to get a good understanding of
> how this all works.
> 
> Including:
> the workflow from application to printer
> colour profiles
> color management; in applications, and printer colour management.
> what happens where?
> detailed user interaction: what controls need to be there?
> 
> 
> Can someone point me in the right direction? Provide some useful
> information or sources of information?
> 
> Thanks in anticipation,
> 
> 
> Kate

I might be able to help at least with respect to color management.  This is a 
complex area with lots of unresolved issues.  Here is some high level info 
about the current state of things.

Applications:

Currently there are two general types of applications with respect to color 
managed printing.

1. Printing color management dumb applications.  This is the most common type 
of application.  These applications either are completely color management 
dumb (IE. don't know anything about color management and do not use it 
anywhere) or are lacking color management in the printing work flow.  GIMP is 
an example of an app that knows about color management but has no CM support 
in the printing work flow.

2. Apps that are fully color management aware.  This includes apps like 
PhotoPrint, CinePaint and Scribus.  These applications allow users to 
transform the document to the printers color space before it is spooled to the 
printing back end.

CUPS:

Currently CUPS is architected to allow for color management in the server IF 
the *toraster filter being used supports color management.  At present none of 
the open source filters do (unless recent versions of the pdftoraster filter 
have this support now - what is the status of this?).

CUPS server side CM is setup in the PPD file for the printer in the 
*cupsICCProfile settings.   Currently in the PPD files that come with GutenPrint 
these settings are completely wrong and point to profiles that do not exist in 
directories that do not exist on most *nix machines (these appear to be OS/X 
specific IE. "/System/Library/ColorSync/Profiles/sRGB Profile.icc").   In 
addition when I change these and later install a newer version of the driver 
these settings get stomped on (not good - we should be able to do better).

Only admins can change the CUPS settings for the profiles that will be used by 
the server and this can only be done by editing the PPD file.  The only 
application that I am aware of that will display a list of these profiles for 
end users is Kolor Manager which is in the playground area of KDE SVN.  The 
current CUPS web admin app does not display these nor does it have facilities 
for making changes to these settings.

CUPS will only use profiles (logically) installed in the correct location on 
the server.  Typically /usr/share/cups/profiles on linux machines.  This 
location is not compliant with other standards (XDG & OpenICC) regarding where 
files like this should be located.

For more detail see the CUPS PPD documentation.

In an ideal world:

1.  CUPS would have *toraster filters that are CM aware (I think this work is 
underway at least with the pdftoraster filter).

2. Server side CM settings for printers would be persistent across upgrades.

3. The CUPS web admin app would display these settings and allow users with 
the correct privileges to make changes to them.

4. Default printer CM settings in the PPD files would be nominally correct for 
each platform.

5. Applications that are CM dumb would have color management handled in a 
transparent way by CUPS.  This should be the case once #1 and #4 are 
corrected.

6. Applications that are CM aware would be able to disable CUPS server side CM 
and handle CM locally.  This is also needed for printing color management 
targets for creating custom profiles.

7. The CPD has the potential to make all applications printer CM aware.

8. CPD would integrate with system level CM configuration tools like Kolor 
Manager/Oyranos.

The above is mostly high level and may not have been particularly useful.  
There is a lot of complexity and many unresolved issues that may make it 
difficult to implement CM in the CPD at this time.  For example the server side 
CUPS CM facilities are currently not working so that means that the best we 
can hope for at this time is for the CPD to somehow handle doing this before 
spooling the print job.  Later when the CUPS server side CM becomes functional 
changes will need to be made in the CPD to allow users to select either server 
side or local CM.

Does the CPD still use poppler for pdf rendering?  If so recent versions of 
poppler now support CM although this support is limited (you can't set 
rendering intents for example).  If that is the case then it might be possible 
to leverage poppler to make user space printer CM possible.   If you have 
switched to GhostScript then you will need to wait for them to complete their 
CM work that they have underway.

You might also consider asking on the OpenICC email list since I am sure that 
you will get lots of feedback there about how this should work.   Many of 
those that work on printer stuff are also members of the OpenICC list (Till and 
Robert Krawitz for example).  In addition the developers of Oyranos and Kolor 
Manager are members along with most of the other CM people who are doing open 
source work.

Hal

Re: [Printing-architecture] Colour

[Till Kamppeter]

Cross-posting to the OpenICC and Gutenprint mailing list, to get more 
input from the color experts.

Anyone of the color printing/management experts can help Kate?

    Till

P. S.: OpenICC mailing list info page:
http://lists.freedesktop.org/mailman/listinfo/openicc

Gutenprint mailing list info page:
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

kate price wrote:
> 
> I am working on the UI design of the CPD and  looking at the controls  
> and parameters for colour, both as presets/profiles and as more  
> detailed controls. Therefore, I'll need to get a good understanding of  
> how this all works.
> 
> Including:
> the workflow from application to printer
> colour profiles
> color management; in applications, and printer colour management.   
> what happens where?
> detailed user interaction: what controls need to be there?
> 
> 
> Can someone point me in the right direction? Provide some useful  
> information or sources of information?
> 
> Thanks in anticipation,
> 
> 
> Kate
> 
>      man + machine interface works
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture
> 

Re: [Printing-architecture] [Openicc] Colour

[Kai-Uwe Behrmann]

The following text will merely describe what I would like to see as a 
user. Some comments are added to explain what is meant colour management 
wise. Please do not wonder when not even print device selection is 
mentioned in my text. I assume such all to be covered elsewhere.
As Scribus and other projects have focus and a long experience with 
printing, it would shureley be great to read their thoughts or comments, 
what they would think are useful CM options for CPD.


Starting the print button I would like to see in a colour management tab, 
offering following basic controls:

Colourmanage by System      (*)
Colourmanage in Application ( )
No Colourmanagement         ( )
The first would be part of the CUPS *toraster system once its 
implemented.


Colourmanage in Application (early colour binding):
A print device profile is needed. So with this option enabled a
selection for a "Separation profile" should appear showing the 
system installed profiles. The one ICC profile matching the actual print 
conditions the most should be preselected. The other matching and non 
matching profiles should follow in a descending order in the selection 
list. Once Oyranos is distribution ready and availabel it can help in 
preselection and device to profile association.
The set of useful profiles is dependent to the print process. E.g. for a 
"Rgb" printer I would not like to select a Cmyk or nColour profile, for 
"Cmyk" not a Rgb one.

For application colour management the responsibility to match between 
options and ICC profile lays in the hand of the user with the help of a 
hopefully well designed application and its helpers.
It is important to note that any print profile is useful only 
within a defined set of variables associated with print device, medium, 
ink set, driver and driver settings. The Oyranos CUPS module tries to 
cover these relations as they are programatically reachable.

Two ways to get profile to print condition matching UI wise I may outline.
preserve - would mean the user selects a print queue.
            Then a profile selection system can detect a list of
            available and useful profile and they are presented to the
            user. All colour related options, except the above and below
            mentioned colour management options are not changeable. So e.g.
            a user can change positioning but not the ink set. This is a
            typical colour managed mode as many vendor drivers offer.
            A UI, offering expert level control, may allow to prominently
            breaking the profile to print settings relation as a special
            option. Typical a warning dialog could popup to say "Hey, do'nt
            change this setting or your profile does not match any more.
            Cancel[x] Break[]". You may have an alternative to popups.
sync     - a user can select whatever options are permitted by the other
            UI components. The ICC device profile selection is updated
            instantly (assuming its fast enough).

The rendering intent, blackpoint compensation would be needed as the 
minimum of options. Additionally a "Simulation profile" and further 
options of the selected CMM can be helpful to designers and prepress 
people. E.g. "Preserve Black" and the like for Cmyk2Cmyk conversions.

After that I would expect the document gets flattened and converted to the 
requested device colour space, which in turn is sent unaltered to the 
printer. The selected separation profile (must) be embedded and the whole 
thing marked as further not to be colourmanaged.
Some PDF variants allow for that. But I am no PDF expert. So someone with 
certain knowledge in this field could hopefully tell more precisely, which 
exact PDF versions and attributes are needed to do this in a standard way.


Colourmanage by System (late colour binding):
Here is not much to say. The document needs all colour spaces be assigned 
properly, that a remote print host can make colourful sense of the 
content. A option for "Flatten Document Colour Spaces" would help in 
disambiguating the compositing colour space. That is useful for mixed 
colour space documents only. The resulting colour space of a 
colour space flattened document would be the compositing colour space, 
which is typical the default editing Rgb colour space, but can differ in 
some situations. The responsibility to correctly render the document is by 
the print system. Such documents are most portable, as they do not need a 
retargetting, and should therefore be the default setting.
This approach is in colour terminology called late colour binding, because 
the colours get their final values in a rather later stage.


No Colourmanagement:
Omit all colour management related settings and enshure that the content 
is not altered during the spooling and printing. This option is important 
to print colour target, prematched files and for special applications, 
where altering of the content is undesireable. It preserves the state as 
is now.


A print preview with a check box to "Simulate on Monitor" would be great 
and many consider it a basic feature, as it will help users to predict the 
print results. To do the proofing, the selected print profile would work 
as the simulation or proofing profile. The target is the actual monitor 
profile for that screen region. Oyranos has code in the CUPS module to 
obtain certainly the locally stored user accessible ICC device profile. 
Any CUPS profiles, being them local or remote, need more details worked 
out to fit in seamless in a easy manageable workflow.

If you want to make a professional feature available the kind of on screen 
simulation can be selectable. This means to be able to alter the rendering 
intent for the proofing profile which is separate from the document to 
print rendering intent. The rendering intent for the proofing profile can 
be eigther relative colourimetric as a default and optional absolute 
colorimetric. The later would allow for a "Match to Light Booth", 
compensating for white point differences and do no compensation for the 
monitor white point. A further option would be to "Simulate Paper White" 
on screen, which is included in the previous option as well but without 
the absolute white point.


Vendor ICC colour profile can be included by device dedicated PPDs and 
therein configured ICC profiles.


A "Save to PDF" button with all settings applied would be welcome, but is 
shurely already covered by the requirement.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org


PS: I would have loved to refere to the linuxfoundation page on print
     related CM but could not find. I would like to update links to it. Did
     it move(?):
https://www.linuxfoundation.org/collaborate/workgroups/openprinting/color_management


Am 10.11.09, 14:32 +0100 schrieb Till Kamppeter:
> Cross-posting to the OpenICC and Gutenprint mailing list, to get more
> input from the color experts.
>
> Anyone of the color printing/management experts can help Kate?
>
>    Till
>
> P. S.: OpenICC mailing list info page:
> http://lists.freedesktop.org/mailman/listinfo/openicc
>
> Gutenprint mailing list info page:
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>
> kate price wrote:
>>
>> I am working on the UI design of the CPD and  looking at the controls
>> and parameters for colour, both as presets/profiles and as more
>> detailed controls. Therefore, I'll need to get a good understanding of
>> how this all works.
>>
>> Including:
>> the workflow from application to printer
>> colour profiles
>> color management; in applications, and printer colour management.
>> what happens where?
>> detailed user interaction: what controls need to be there?
>>
>>
>> Can someone point me in the right direction? Provide some useful
>> information or sources of information?
>>
>> Thanks in anticipation,
>>
>>
>> Kate
>>
>>      man + machine interface works

Re: [Printing-architecture] [Openicc] Colour

[Hal V. Engel]

On Wednesday 11 November 2009 01:28:24 am Kai-Uwe Behrmann wrote:
> The following text will merely describe what I would like to see as a
> user. Some comments are added to explain what is meant colour management
> wise. Please do not wonder when not even print device selection is
> mentioned in my text. I assume such all to be covered elsewhere.
> As Scribus and other projects have focus and a long experience with
> printing, it would shureley be great to read their thoughts or comments,
> what they would think are useful CM options for CPD.
> 
> 
> Starting the print button I would like to see in a colour management tab,
> offering following basic controls:
> 
> Colourmanage by System      (*)
> Colourmanage in Application ( )
> No Colourmanagement         ( )
> The first would be part of the CUPS *toraster system once its
> implemented.
> 
> 
> Colourmanage in Application (early colour binding):
> A print device profile is needed. So with this option enabled a
> selection for a "Separation profile" should appear showing the
> system installed profiles. The one ICC profile matching the actual print
> conditions the most should be preselected. The other matching and non
> matching profiles should follow in a descending order in the selection
> list. Once Oyranos is distribution ready and availabel it can help in
> preselection and device to profile association.
> The set of useful profiles is dependent to the print process. E.g. for a
> "Rgb" printer I would not like to select a Cmyk or nColour profile, for
> "Cmyk" not a Rgb one.
> 
> For application colour management the responsibility to match between
> options and ICC profile lays in the hand of the user with the help of a
> hopefully well designed application and its helpers.
> It is important to note that any print profile is useful only
> within a defined set of variables associated with print device, medium,
> ink set, driver and driver settings. The Oyranos CUPS module tries to
> cover these relations as they are programatically reachable.
> 
> Two ways to get profile to print condition matching UI wise I may outline.
> preserve - would mean the user selects a print queue.
>             Then a profile selection system can detect a list of
>             available and useful profile and they are presented to the
>             user. All colour related options, except the above and below
>             mentioned colour management options are not changeable. So e.g.
>             a user can change positioning but not the ink set. This is a
>             typical colour managed mode as many vendor drivers offer.
>             A UI, offering expert level control, may allow to prominently
>             breaking the profile to print settings relation as a special
>             option. Typical a warning dialog could popup to say "Hey, do'nt
>             change this setting or your profile does not match any more.
>             Cancel[x] Break[]". You may have an alternative to popups.
> sync     - a user can select whatever options are permitted by the other
>             UI components. The ICC device profile selection is updated
>             instantly (assuming its fast enough).
> 
> The rendering intent, blackpoint compensation would be needed as the
> minimum of options. Additionally a "Simulation profile" and further
> options of the selected CMM can be helpful to designers and prepress
> people. E.g. "Preserve Black" and the like for Cmyk2Cmyk conversions.
> 
> After that I would expect the document gets flattened and converted to the
> requested device colour space, which in turn is sent unaltered to the
> printer. The selected separation profile (must) be embedded and the whole
> thing marked as further not to be colourmanaged.
> Some PDF variants allow for that. But I am no PDF expert. So someone with
> certain knowledge in this field could hopefully tell more precisely, which
> exact PDF versions and attributes are needed to do this in a standard way.
> 

I am not sure that "Colourmanage in Application" is a good descriptive term 
for this option although "early binding" is somewhat descriptive.  What is 
being described is color management on the user machine (in user land) in the 
CPD (or perhaps a CPD color management add in of some sort).  The distinction 
is that some applications do their own CM (Scribus, CinePaint PhotoPrint...) 
and the print system has no way of knowing about this.  Doing color management 
in these apps the user would select the No Color Management option and calling 
this option color management in application could be confusing.

> 
> Colourmanage by System (late colour binding):
> Here is not much to say. The document needs all colour spaces be assigned
> properly, that a remote print host can make colourful sense of the
> content. A option for "Flatten Document Colour Spaces" would help in
> disambiguating the compositing colour space. That is useful for mixed
> colour space documents only. The resulting colour space of a
> colour space flattened document would be the compositing colour space,
> which is typical the default editing Rgb colour space, but can differ in
> some situations. The responsibility to correctly render the document is by
> the print system. Such documents are most portable, as they do not need a
> retargetting, and should therefore be the default setting.
> This approach is in colour terminology called late colour binding, because
> the colours get their final values in a rather later stage.

This should be the default once CUPS has CM aware *toraster filters (or at 
least a CM aware path).  Like the early binding setting it should have a way 
for users to select rendering intents, black point compensation and possibly 
preserve black.  Also these setting need to be passed to and used by the back 
end.

> 
> 
> No Colourmanagement:
> Omit all colour management related settings and enshure that the content
> is not altered during the spooling and printing. This option is important
> to print colour target, prematched files 

IE. output from apps that are CM aware.

> and for special applications,
> where altering of the content is undesireable. It preserves the state as
> is now.

That is all color values are assumed to be device values and should not be 
altered.

> 
> 
> A print preview with a check box to "Simulate on Monitor" would be great
> and many consider it a basic feature, as it will help users to predict the
> print results. To do the proofing, the selected print profile would work
> as the simulation or proofing profile. The target is the actual monitor
> profile for that screen region. 

Even without proofing the CPD should use any installed (IE. X11 _ICC_PROFILE 
atoms) profiles to color manage what is displayed on the screen.  This is a 
good starting point and adding proofing later will be much easier.

> Oyranos has code in the CUPS module to
> obtain certainly the locally stored user accessible ICC device profile.
> Any CUPS profiles, being them local or remote, need more details worked
> out to fit in seamless in a easy manageable workflow.
> 
> If you want to make a professional feature available the kind of on screen
> simulation can be selectable. This means to be able to alter the rendering
> intent for the proofing profile which is separate from the document to
> print rendering intent. The rendering intent for the proofing profile can
> be eigther relative colourimetric as a default and optional absolute
> colorimetric. The later would allow for a "Match to Light Booth",
> compensating for white point differences and do no compensation for the
> monitor white point. A further option would be to "Simulate Paper White"
> on screen, which is included in the previous option as well but without
> the absolute white point.

Currently the CPD only allows for a fairly small preview.  This limits it's 
usefulness for soft proofing.  Most users interested in having on screen soft 
proofs will be using applications that have the ability to do soft proofing and 
that allow these proofs to be displayed in a larger window.   GIMP, Scribus 
and I think CinePaint all support soft proofing. 

> 
> 
> Vendor ICC colour profile can be included by device dedicated PPDs and
> therein configured ICC profiles.
> 
> 
> A "Save to PDF" button with all settings applied would be welcome, but is
> shurely already covered by the requirement.
> 
> 
> kind regards
> Kai-Uwe Behrmann
> 
> > Cross-posting to the OpenICC and Gutenprint mailing list, to get more
> > input from the color experts.
> >
> > Anyone of the color printing/management experts can help Kate?
> >
> >    Till
> >
> > P. S.: OpenICC mailing list info page:
> > http://lists.freedesktop.org/mailman/listinfo/openicc
> >
> > Gutenprint mailing list info page:
> > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> >
> > kate price wrote:
> >> I am working on the UI design of the CPD and  looking at the controls
> >> and parameters for colour, both as presets/profiles and as more
> >> detailed controls. Therefore, I'll need to get a good understanding of
> >> how this all works.
> >>
> >> Including:
> >> the workflow from application to printer
> >> colour profiles
> >> color management; in applications, and printer colour management.
> >> what happens where?
> >> detailed user interaction: what controls need to be there?
> >>
> >>
> >> Can someone point me in the right direction? Provide some useful
> >> information or sources of information?
> >>
> >> Thanks in anticipation,
> >>
> >>
> >> Kate
> >>
> >>      man + machine interface works
> 
> _______________________________________________
> openicc mailing list
> openicc@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
> 

Re: [Printing-architecture] [Gimp-print-devel] [Openicc] Colour

[Chris Murphy]

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



On Nov 12, 2009, at 2:57 PM, Michael Sweet wrote:
> 
> One of the biggest problems we have with Mac OS X color management are the color controls. Too many users try to tweak every knob we have, and too many drivers provide extra knobs that interfere with managed color reproduction. The best advice we can give to our users is to turn off all of the vendor controls (if necessary) and leave our color controls set to the defaults.  If Linux wants to avoid the "mistakes" of the Mac and Windows world, eliminate vendor controls and minimize (or eliminate) the "standard" color controls. Let the "expert" applications provide controls for color profile and rendering intent, which is equally important to make out-of-gamut colors look reasonable, and leave those controls out of the standard/general print dialog.

I agree with most of this. Although I don't know if printer manufacturers would agree to relinquish their own color controls. I'm not a huge fan of their controls and I think they are a waste of space. But they do likely achieve a major goal for manufacturers, which is platform parity for their products.

> From the point of view of a color-managed workflow, the ideal color space for printer drivers is DeviceN, i.e. a 6-color printer gets 6 color channels, with the separation defined by the ICC profile for that printer, media, color mode, etc. However, the reality is that we don't have tools to create or the infrastructure (at least on Mac OS X) to handle profiles with more than 4 channels, and thus most drivers take RGB or CMYK and map it to DeviceN as needed. Because of this, custom printer profiles are of limited usefulness in a printing workflow - you can (and many people do) tweak the output for a particular set of printer, inks, and media, but the results are not ideal because you are not manipulating the color in the printer's native color space. Moreover, many high-end printers now provide so-called "closed loop" profiling on the printer to normalize the output for the current supplies and environment, making the "traditional" manual profiling workflow unnecessary.

I don't agree with most of this.

The quality of the RGB->DeviceN "black box" provided by a manufacturer for an e.g. 6-color printer, is what determines how effective profiling it can be. For example the Epson Stylus Photo 2200 had a really piss poor Off (No Color Adjustment) LUT. It was wider gamut than the Photo Realistic or Vivid LUTs, but it had nasty gray balance and seriously clipped detail in shadows. It was worth profiling over despite this, for certain classes of imagery. Other classes, it was best to profile over the Photo Realistic mode.

Newer printers, Epson Stylus Pro 3800 or 3880, for example, the Off (No Color Adjustment) LUT is quite well behaved, even compared to the sRGB or Adobe RGB LUTs offered by the driver. Professional, fine-art photographers have been building custom RGB ICC output device profiles over these LUTs for such professional printers for years, using the manufacturer supplied driver, and have achieved superior results compared to either the sRGB or Adobe RGB LUTs.

There are a couple of products on the market that can build 5+ channel ICC output device profiles. They are old, and expensive, and it's unclear exactly how well they work compared to an RGB ICC output device profile over a good (or decent) RGB->deviceN black box LUT provided by the manufacturer. What is clear is that it's non-trivial making such deviceN ICC output device profiles even if you have the software to build them, or an OS that could support them. The profile target you use is a challenge to figure out how you're even going to print it correctly. And then you have a healthy amount of testing to manually determine what the ink limit should be, since ink limiting is the responsibility of the profile, in this  paradigm, if there is no black box in the middle of the process. And channel cross over behavior, ink limiting and GCR is really non-trivial.

Looking and high-end proofing products, even that is rarely done with DeviceN ICC profiles for inkjet proofers. If it's an Epson inkjet, most products on the market today depend on Epson's HTM (halftoning module), which is the guts of their black box which can accept either RGB or CMYK input. So the inkjet is still profiled as either an RGB or CMYK device, and the HTM is responsible for further separating that out to deviceN. (For dot proofing on inkjet, other considerations are needed.)

So I disagree that "custom printer profiles are of limited usefulness" or that the "results are not ideal." I have much bigger complaints than not being able to peak inside the Epson/Canon/HP black box. I'm annoyed that it's so f'n difficult to reliably print profile targets on Mac OS X without ColorSync sticking its nose into the wrong business. When that happens, the resulting profile is completely FUBARd and that is truly of limited usefulness and results that are not ideal.

Chris Murphy

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

Re: [Printing-architecture] [Gimp-print-devel] [Openicc] Colour

[Chris Murphy]

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


On Nov 13, 2009, at 4:35 PM, Michael Sweet wrote:
> 
> While you are quick to blame ColorSync, the issue of providing colors in the device color space to avoid transforms is well-known and every profiling tool I know of for the Mac already does the right thing to print a target.

Well they don't. None of them do this correctly. All try to submit a target and then the driver defaults to vendor color matching, typically expecting sRGB as the source space. The user must manually set a "no color management" color setting, because none of the profiling tools use the APIs to inform the OS which then informs the driver to change to the proper mode for building an ICC profile. If we get the driver configured correctly, then yes we get a valid profile target, without ColorSync involving itself.

However, none of the high end profiling tools print targets directly through the OS. Those targets are TIFF, and need to be printed from an application that can correctly print and not color manage the target, and then also inform the OS (the pdftoraster filter, and also ColorSync) to not convert the target. Presently on Mac OS the application of choice is Photoshop, with which we are presently having problems because the No Color Management based PDF spool file has different profiles set for the profile target object, and OutputIntent, causing ColorSync to color manage. It autoconfigures newer print driver settings correctly, but the PDF spool file is malformed, so we get a converted profile target.

I have looked quite long and hard on Apple's developer web site for documentation explaining the architecture and how to avoid transforms and was not successful. The API to get the print driver to set itself to the proper mode for use with an ICC profile using application color matching isn't locatable either.

> 
> The most common problem is drivers - vendors incorrectly choose defaults or ignore color settings (applying *both* the colorsync profile *and* their own "enhancements") which leads to strange results.

We can certainly blame such problems on drivers, and be correct.

Yet an off mode for ColorSync doesn't exist. It depends on null transforms. That's the bigger flaw, in my view, because achieving null transforms is complicated. An off switch is much easier, and thus more reliable.

An explicit off switch is allowed in PDF/X-3, while still implicitly tagging the data. DeviceRGB being persona non grata, by Apple, in the PDF spool file is a big source, in my opinion, of the problems we've been having on Mac OS. DeviceRGB could have (and should have) acted as a fail safe for calibration/characterization/prematching workflows. While a small percent of the market, these workflows are the #2 workflow behind simply leaving the driver set to defaults.


> A very common problem with the Epson drivers is that the Epson color controls are not actually disabled in ColorSync mode! However, bugs like those are propagated to avoid "breaking" existing users' workflows (!?!)

I have two current drivers for two different Epson printers and neither of them behave the way you're describing. When I set ColorSync mode, the Color Settings pop-up menu changes to "Off (No Color Adjustment)" and all of its color controls found in Advanced Color Settings vanish. Instead, they are replaced by text explaining the profile that will be used when printing. It appears to be the correct behavior. I know older drivers, for way too long, did behave the way you describe. And yes that's all on Epson, but the documentation is weak, and documentation search on the dev site simply sucks.

So, presently we're unable to reliably print profile targets from Photoshop, using No Color Management (in Photoshop) and Off (No Color Adjustement) in a wide assortment of newer Epson drivers. What happens is, I get a completely borked profile target in printed form. Inspection of the PDF spool file indicates source≠destination, and thus ColorSync is going to come riding in to convert the job.

DeviceRGB being set as the color space would avoid this. Content that is calibration/characterization/prematch from an application, has no business being ICCBased in the PDF spool file.


Chris Murphy

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

Re: [Printing-architecture] [Gimp-print-devel] [Openicc] Colour

[Chris Murphy]

On Nov 14, 2009, at 12:13 AM, Michael Sweet wrote:
> That's the kicker - most inkjet drivers use vendor color matching by default, and usually with vendor-specific "enhancements" that don't get turned off when you tell the driver to go into ColorSync mode.  We file bugs with the vendors all the time for this... :(

I understand, vendors regularly get things wrong.

> The API for setting up an identity transform isn't public but *is* available through developer technical support. Basically this hasn't been included in public documentation because even the "experts" writing profiling software have used the API incorrectly (for various reasons the API is semi-complicated), and we don't want to encourage the use of device color on Mac OS X except when it is actually needed (which is basically only when printing a target or doing application color management...)

a.) Sounds like it's too complicated.
b.) Sounds like it's too complicated for the documentation Apple is willing to provide.
c.) Vendors are still getting things wrong.


> ... and thus more likely to be used.  It is hard to turn off ColorSync on purpose - there are very few scenarios that actually require it.

Sure. Any scenario involving calibration, characterization, or application prematching, requires it. That would be a few scenarios. But they are rather mission critical scenarios for those who depend on it.

It doesn't seem like making ColorSync so hard to turn off has really achieved anything, but lots of problems over the past 5 or so years, for professionals who depend on printing, especially to inkjet printers.


> The problem is that DeviceRGB was being used for everything, not just for those cases that needed it, so it was basically impossible to know what the intent was and get consistent output from applications.

That was an opt in system of color management. The default was DeviceRGB. I am not proposing that model. I'm proposing simplifying the opt out mechanism, and making it robust. Right now it's the year 2009 and this is as bad and inconsistent as it has ever been.

> Epson (and all of the other printer vendors) work closely with Apple engineering, but there are still problems that slip through our combined testing.  The problem I described has come and gone for specific drivers many times, and often re-appears in new drivers the first time we get an update from them - we reject any that we catch, but as you can imagine we can't test every driver and printer so problems *do* slip through.

Well if Apple didn't operate like the KGB, as though everything is such a huge fricking secret, and clearly and thoroughly documented how things are supposed to work, it would at least make it easier to identify what is incorrect behavior, and whose bugs these are. 

> 
>> So, presently we're unable to reliably print profile targets from Photoshop, using No Color Management (in Photoshop) and Off (No Color Adjustement) in a wide assortment of newer Epson drivers. What happens is, I get a completely borked profile target in printed form. Inspection of the PDF spool file indicates source≠destination, and thus ColorSync is going to come riding in to convert the job.
> 
> We are working with both Adobe and Epson on this issue...

Michael, yes, I have no doubt about that. The problem is that these sorts of color problems with printing are recurring themes. Epson is not the only one who has had problems, although they very well may be the worst offender. But we don't have these kinds of problems on Windows. That should be a WTF moment for Apple. Sane people have started to wonder, rationally, if there is something wrong with the architecture when there are so many recurring problems of this sort, through multiple major revisions of the operating system. We've experienced color related problems with Tioga drivers too.

> DeviceRGB (like what we went through in 10.4 and earlier) only led to more problems since all output was uncalibrated.

There is a very rational, workable medium between totally uncalibrated, which is not what I'm advocating, and forcing everything to be ICCBased. It is fundamentally inappropriate for calibration/characterization/prematch data to be ICCBased. That is a serious systemic problem, and a cause for many of the problems we've been having.

DeviceRGB + an OutputIntent is not the same thing as what you had with 10.3 and earlier. It is not uncalibrated. And I'm not suggesting most applications would have such PDF spool files. Just the ones that explicitly call a particular "calibration API".

Presently, it is possible for PDF spool files to appear with an OutputIntent of None, which I find equally baffling to the lack of DeviceRGB. In my view the PDF spool file is formed exactly backwards. OutputIntent should be required, as it is in all PDF/X. That is the implicit source for device data, enabling the soft proofing of even application prematched data - or even retargeting to a different output device, if necessary.


Chris Murphy

Re: [Printing-architecture] [Gimp-print-devel] [Openicc] Colour

[Chris Murphy]

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

On Nov 14, 2009, at 3:59 PM, Michael Sweet wrote:
> On Nov 14, 2009, at 2:10 AM, Chris Murphy wrote:
>> Michael, yes, I have no doubt about that. The problem is that these sorts of color problems with printing are recurring themes. Epson is not the only one who has had problems, although they very well may be the worst offender. But we don't have these kinds of problems on Windows. That should be a WTF moment for Apple. Sane people have started to wonder, rationally, if there is something fwrong with the architecture when there are so many recurring problems of this sort, through multiple major revisions of the operating system. We've experienced color related problems with Tioga drivers too.
> 
> Windows doesn't provide the same level of support for color as Mac OS X, and to say that Windows doesn't have these problems is a lie - they are just hidden from most users since there isn't a "use this profile" option staring you in the face every time you print.
> 
> In any case, venting here won't fix things in Mac OS X.  Please file bugs with Apple so that any issues get escalated and dealt with:
> 
>     http://bugreport.apple.com


A lie? As in, an intentionally false statement? That's an interesting assertion. I know for a fact it's possible to print profile targets reliably on Windows. There are other problems on Windows, but reliably printing profile targets and prematching color without ICM becoming involved is not one of them, because it is not aggressively invasive like ColorSync. Those are the problems I'm referring to.

My entrance to the thread was to lend my perspective to Linux dvelopers on avoiding what I consider to be major flaws with printing and color on OS X. Subsequent posts have been responses. These are not new complaints. Multiple forums including Apple's ColorSync User's list and support forums are littered with such complaints.

There isn't a mechanism for relaying perceived (or real) architectural flaws with Apple. Doing so on bug reporter consistently yields "works as intended" responses from engineering. I know because I've been down that road already.


Chris Murphy

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

Re: [Printing-architecture] [Gimp-print-devel] [Openicc] Colour

[Chris Murphy]

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



On Nov 15, 2009, at 4:33 PM, Michael Sweet wrote:
> Well, last time *I* tried to print a target on Windows I had the same Epson driver problems that you'll find on Mac OS X - the Epson color controls were still used, making the target print useless.

It is true that on Windows the user should choose a different LUT than the default which on current drivers is Epson Standard (sRGB). But the printed target isn't useless. You'll actually make a profile that works correctly, although it is restricted in gamut. However, in-gamut colors reproduce correctly.

The problem I'm referring to that does not happen on Windows is ICM getting involved when it's not asked to. That's been a regular problem on OS X, even if it's manifested itself in different ways.

Chris Murphy

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

Re: [Printing-architecture] [Gimp-print-devel] [Openicc] Colour

[Chris Murphy]

I agree with Michael on all points.

The existing user experience is broken. A different user experience should be employed. But I think we need to be very conscientious about both the next user experience and developer experience, if things are going to be changed yet again. A huge, huge, huge problem on OS X is that things keep changing. Such change + very limited documentation has been a huge pain point for developers, and is a contributing factor to their inconsistency.

And I agree with Michael, in particular, on his first two paragraphs. Duplicative selection of media/color mode/resolution, then having to do this yet again with the profile selection, makes errors possible where otherwise there would be none (at least not UI induced). For some time it has been possible to include such device condition information into the profile as metadata, so there should be room for an application to specify a printer profile, and for the system to figure out what the driver settings should be to replicate the print condition needed for that profile to be valid.

Two things that emphasize a continuing need for application prematching capability:

a.) Black point compensation in ColorSync has functioned incorrectly since it was implemented. In an ICC v2 context, BPC is required. Perceptual rendering is inadequate. So is it working on 10.6? I don't know.

b.) Only the Apple CMM is supported in the print architecture. It's not possible for an application to ask for another CMM be used by CoreGraphics for printing purposes. This means application prematching is a required workflow.



Chris Murphy

On Nov 15, 2009, at 12:08 AM, Michael Sweet wrote:

> On Nov 14, 2009, at 5:15 PM, Roy Harrington wrote:
>>> I humbly suggest that what you want is a utility that allows the user to print targets and generate/install ICC profiles for a > > particular combination of printer, media, and other settings. If you have to select a profile at print time, then the printing > > workflow is broken.
>>> 
>>> ___________________________________________________
>>> Michael Sweet, Senior Printing System Engineer
>> 
>> While a separate utility might be a useful thing, I think you are
>> missing the point of view of the higher
>> end people printing.  Most have Photoshop and print from Photoshop.
>> Most use various different papers,
>> not just printer manufacturer supplied papers.
> 
> I think you are missing my point - if you are profiling for your own media and ink, then those profiles and corresponding media settings should be savable so that the *only* thing you do in the print dialog is choose that custom media/ink combination and *not* choose the media, ink, and profile separately.  Why complicate the user interface with profile controls that are only useful when you have created a custom profile, something that will require a separate program and UI in order to print the target, read it, and generate the profile in the first place?!?
> 
> In short, why make the user select everything every time and clutter the UI with unnecessary information?
> 
>>  So if you want to use
>> various papers and the Epson
>> driver you need to download ICC profiles from somewhere or create your
>> own custom ones.
>> When you print you've got to be able to select which profile will be
>> used -- during the printing process.
>> From a user point of view the natural thing is to do this in Photoshop
>> -- its right there in the Print Preview
>> screen.  If you are doing soft-proofing you must do it in Photoshop.
>> Creating custom ICC profiles
>> is the other major difficulty -- this used to work just perfectly.
>> Why break the existing workflows?
> 
> Why not when they are already broken?
> 
>> The OS centric point of view that the OS will handle it means you have
>> to go into ColorSync Utility
>> and try to find out how to associate a custom ICC profile with a
>> device.   There's no straightforward
>> way to do this.
> 
> I'm not arguing that Linux duplicate Apple's current ColorSync user experience - that much is clearly broken since users and vendors regularly have so many problems.
> 
> I'm similarly not advocating a continuation of the current "application color management" experience because that is similarly broken for anyone but a professional, and even then individual driver and application issues make it problematic.
> 
> Instead, I'm suggesting that a different user experience be employed: when printing, the user sees no color controls. Color profiles are auto-selected based on the print settings - users can install new profiles, media types, and ink sets separately as needed. These profiles can be "canned" profiles the user downloads from somewhere or custom profiles the user creates using profiling software.
> 
> Applications that need to do their own color management (hopefully few and far between) can specify so using an API, which disables color management and profile selection so that the color data the application provides is treated as device color all the way through to the printer.
> 
>> ...
>> I've asked quite explicitly via ADC what is the protocol to print with No Color
>> Management and Application Color Management but haven't gotten answers.
>> I was able to crawl through header files and find the AP_ColorMatchingMode
>> flag but there is no documentation.
> 
> Whom did you talk to at ADC?
> 
>> ...
>> I've used the bug report system.  See bug 6503221 that I submitted in Jan 2009.
>> After quite a few emails back and forth, all seemed to agree that there was a
>> problem.  "Apple and Adobe are working on it" is all since then.  It just
>> sits as an open issue.
> 
> Keep in mind that when there is a problem that requires coordination between multiple vendors, a solution inevitably takes longer.
> 
>> Simple question:  As an "Apple Senior Printing System Engineer" can you find out
>> how the No Color Management should work?
> 
> Within Mac OS X, the only way to disable color management is to associate the device profile with the colors you draw with - this doesn't actually disable color management but *does* short-circuit it.
> 
> However, that is only 1/2 of the equation - you also need to tell the driver to go into "application color matching mode", and pray that the driver actually implements it properly.  This is the kPMColorMatchingModeKey (AP_ColorMatchingMode) setting, which is described in the PMPrintSettingsKeys.h header along with the supported values: kPMVendorColorMatching or kPMApplicationColorMatching. If not set, ColorSync is used.
> 
>> Thanks,
>> Roy Harrington
>> 
>> ps:  I do a third party print driver for Epson printers and various
>> ICC profiling for this.
>> I'm familiar with the printing system from the driver point of view as
>> well as from
>> application point of view.
> 
> 
> Prior to joining Apple, I wrote and sold commercial printer drivers and RIPs for 13 years, and did printer software for 6 years before that "just for fun".  My company was a member of the ICC...
> 
> ___________________________________________________
> Michael Sweet, Senior Printing System Engineer
> 
> 
> 

Re: [Printing-architecture] [Gimp-print-devel] [Openicc] Colour

[Hal V. Engel]

On Saturday 14 November 2009 09:08:17 pm Michael Sweet wrote:
> I'm not arguing that Linux duplicate Apple's current ColorSync user
>  experience - that much is clearly broken since users and vendors regularly
>  have so many problems.
> 
> I'm similarly not advocating a continuation of the current "application
>  color management" experience because that is similarly broken for anyone
>  but a professional, and even then individual driver and application issues
>  make it problematic.
> 
> Instead, I'm suggesting that a different user experience be employed: when
>  printing, the user sees no color controls. Color profiles are
>  auto-selected based on the print settings - users can install new
>  profiles, media types, and ink sets separately as needed. These profiles
>  can be "canned" profiles the user downloads from somewhere or custom
>  profiles the user creates using profiling software.
> 
> Applications that need to do their own color management (hopefully few and
>  far between) can specify so using an API, which disables color management
>  and profile selection so that the color data the application provides is
>  treated as device color all the way through to the printer.
> 

This is something that I can generally agree with.  One of the goals of the 
Oyranos project is to facilitate exactly this kind of user experience.  I also 
think this is what the CPD is intended to support in the long run.  The key 
points are:

1. A very simple printing UI that hides most things color related. 

2. In general all (non-target, non-prematched) CM is handled on the back end 
and color is managed using ICC profiles.

3. The driver vendors will specify (and supply if needed) the default profiles 
used by their device.

4. Users/admins have complete control over things like which profiles are 
installed and related settings so that the back end and how it selects and 
uses profiles can be configured by the user/admin.

5. Apps that need to do prematching or that are used to print targets will 
have a simple API available to disable back end CM for their print jobs.

Of course at present almost none of this is in place in the non-OS/X world 
(the following is FOSS specific).  

#1. The CPD with proper PPD files will do this right now but none of the 
existing PPD files are setup for this type of work flow.

#2. CUPS has the ability with proper *toraster filters to do #2.  But the 
needed open source *toraster filters still need work.

#3. This is in place on OS/X but the cupsICCProfile settings in the PPD files 
are not correct for other platforms and I am not sure if this is the best way 
to handle this requirement.

#4. At present is missing.  Trying to configure this by using/modifying the PPD 
files is at best clumsy and has lots of issues that have been touched on in 
other notes in this thread and in other threads.  The cupsICCProfile settings 
in the PPD file is simply not designed to meet this requirement. This could 
conceivably be handled by some type of interface between CUPS, Oyranos and 
user land but lots of work still needs to be done in all three areas.  Having 
a clear vision of what the pieces are and how they fit together will make it 
easier to get Oyranos, CUPS and user land tools (like Kolor Manager in KDE and 
the CPD) up to speed and should allow for creating any needed APIs in the 
various systems involved.  I think Oyranos already has most of the APIs needed 
to support user land and CUPS.  CUPS, of course, has no working interface to 
Oyranos in part because the Oyranos printer support is so new (GSoC 2009).

#5. This does not currently exist as far as I can tell either on the back end 
(IE. CUPS and friends) or in any of the existing apps that are CM aware.  On 
the other hand in the open source world there are only a handful of apps that 
are CM aware at all and only a subset of those know anything about ICC profiles 
in the printing work flow (IE. most color manage to the display only - GIMP is 
an example of a limited CM aware app).  I think if there were a simple to use 
well documented API for this that those apps that need it would be modified to 
use it fairly quickly.  Particularly since the developers of most of those 
apps are members of at least one of the email lists that are part of this 
thread.   But the issue is that there needs to be a way to do this either 
through specialized applications like PhotoPrint or by having a switch on the 
CPD if no apps with this ability are available.  That is I would consider 
having a CPD switch for this to be a transition issue that would be removed 
once we had applications available that could use the no-back end CM API call.

Hal

Re: [Printing-architecture] [Openicc] [Gimp-print-devel] Colour

[Kai-Uwe Behrmann]

Am 15.11.09, 12:26 -0800 schrieb Hal V. Engel:
> This is something that I can generally agree with.  One of the goals of the
> Oyranos project is to facilitate exactly this kind of user experience.  I also
> think this is what the CPD is intended to support in the long run.  The key
> points are:
>
> 1. A very simple printing UI that hides most things color related.
>
> 2. In general all (non-target, non-prematched) CM is handled on the back end
> and color is managed using ICC profiles.

Ah, that would be equal with the Colourmanage by System mode.

Well, as I wrote my initial response, my take was to let CPD implement and 
present a UI for full colour management control. With the additional 
requirements to softproofing and other stuff let me throw the question,
will CPD have a architecture to allow custom application side tabs and 
windows in a style of plug-ins? Can these plug-ins be shared between 
applications? It would allow for additional features like a bigger print 
preview including soft proofing out of gamut marking and att that.

On the opposite, please correct me, Hal seems to favourise a API which 
allowes for that advanced colour management (CM) stuff. That includes 
changing of rendering intent, BPC, obtaining the printer profile for soft 
proofing. How shall that UI wise integrate with CPD? In CinePaint I never 
touched the Gutenprint panel. It was sub ideal (a hack) to have the colour 
management dialog in advance to the print dialog. The print profile is not 
known during soft proofing. The proofing profile can be different from the 
print profile. I found printing dialogs much more useful, which allowed 
a scalable preview. Some came even with a pager. Shall CPD show a print 
preview button. Sorry if that is already discussed on the Linuxprinting
mailing list.

IMO, the current way to present toppic clouds in CPD is useable to hide CM 
controls for most users, but still they are always reachable for those who 
want them. Breaking consitency of print settings related to the selected 
ICC profile should, if at all allowed, be indicated by a big warning.

There are situations where people try to improve their results with canned 
ICC profiles by tweaking the print settings. This is something, I 
regulary did in times, where I had no ICC workflow available. A way to 
include custom corrections and effect profiles would be nice to have 
anyway.

Effect profiles can then be used for the preferenced artistic look of a 
print out. 
This would more egalise the selection of a special printer just for the 
style of interpreting colours and favoure individual user selectable 
effects and styles. Vivid and natural is than available for all users not 
just on single products. (Still media, inks and print hardware will make a 
differencs for handling, eveness, gamut, UV stability and so on.)

The abstract class of ICC profiles, combined with a profile manipulator or 
a traditional colour correction curves panel with additional sliders for 
HSV manipilations which saves abstract ICC profiles, can then be used 
to do colour tweakings.
Abstract profiles are almost not a path for colour professionals to get 
1:1 output or relyable TAC reduction and so on. Thats something for the 
device link class of profiles or special and thus selectable CMMs. Beside 
that custom CMMs might help in the future on the artistic side too, e.g. 
per image gamut mappings.

Effect profiles are part of the print dialog on osX. I do not know about 
Windows' native dialog.

Now we get back to early versus remote colour binding.
This all requires early colour binding and thus CPD has to locally
render final values. In a more complicated workflow, CPD could tag the 
content with appropriately manipulated profiles for remote applyance. With 
more resources I could imagine to get effect profiles reproduceable 
working in a remote and late colour binding scenario. But that would 
certainly require much support and man power. This later path is unlikely 
to get implemented in the forseeable future.


To summarise:
a) Effect profiles are cool and very flexible.
b) Device link profiles and selectable CMMs allow for advanced
    professional and artistic stuff.
c) The above is all difficult to get remotely working, so colour
    conversions should typical apply already in CPD.
d) Average users expect to select print effects at time of printing and
    thus in the print UI.
e) If CPD does not care, vendors will take their chance and fill that
    niche to provide better than average results.
d) Vendor intervention in the CM workflow is undesireable as it will
    invent lots of different solutions and potentially break things.


Given with all the above I want to reiterate about the three basic CM 
modes in CPD (Hal suggested to have only two):
* Colourmanage in Application (early colour binding).
   CPD is considered as part of the application infrastructure and not
   stand allone. The name CPD, Common Printing Dialog, implies this to me.
   So early colour binding has typical to happen in CPD. For applying of
   effect profiles and other advanced CM technices, which we do not (yet)
   know how to simply transport over PDF to a remote host, this early
   binding mode is the preference.
* Colourmanage by System (late colour binding), or colour process remotely
   is the right default with vendor supplied ICC profiles. In the
   perceptual tables can a pleasing rendering be expected.
* No Colourmanagement, print raw values. A exception for printing colour
   targets, special cases, e.g. dot by dot printing, and when the above
   does not suffice.

That written I do not at all want to fix the modes names, but they should 
be transparent to the user as they are very fundamental not only for 
developers. The names and how they are exposed to CPD users have to be 
discussed with the UI experts in detail.

Further the strong suggestion of Mike Sweet to hide the selection of the 
final print profile can be reached with deploying technices like effect 
profiles and others. This means as well that the above three basic CM 
modes would loose their prominence. Perhaps the No Colourmanagement 
mode resides in a expert tab of CPD. Perhaps that mode is intermediate 
and switches back automatically after printing the colour chart.

> 3. The driver vendors will specify (and supply if needed) the default profiles
> used by their device.

agreed

> 4. Users/admins have complete control over things like which profiles are
> installed and related settings so that the back end and how it selects and
> uses profiles can be configured by the user/admin.
>
> 5. Apps that need to do prematching or that are used to print targets will
> have a simple API available to disable back end CM for their print jobs.

Good that would omit the No Colourmanagement mode from the CPD UI. But 
then a simple application, which is always available to prints to all 
queues is a reuirement to point colour experts to. The application should 
be able to work with all drivers. Could Photoprint take this over?


> Of course at present almost none of this is in place in the non-OS/X world
> (the following is FOSS specific).
>
> #1. The CPD with proper PPD files will do this right now but none of the
> existing PPD files are setup for this type of work flow.
>
> #2. CUPS has the ability with proper *toraster filters to do #2.  But the
> needed open source *toraster filters still need work.
>
> #3. This is in place on OS/X but the cupsICCProfile settings in the PPD files
> are not correct for other platforms and I am not sure if this is the best way
> to handle this requirement.
>
> #4. At present is missing.  Trying to configure this by using/modifying the PPD
> files is at best clumsy and has lots of issues that have been touched on in
> other notes in this thread and in other threads.  The cupsICCProfile settings
> in the PPD file is simply not designed to meet this requirement. This could
> conceivably be handled by some type of interface between CUPS, Oyranos and
> user land but lots of work still needs to be done in all three areas.  Having
> a clear vision of what the pieces are and how they fit together will make it
> easier to get Oyranos, CUPS and user land tools (like Kolor Manager in KDE and
> the CPD) up to speed and should allow for creating any needed APIs in the
> various systems involved.  I think Oyranos already has most of the APIs needed
> to support user land and CUPS.  CUPS, of course, has no working interface to
> Oyranos in part because the Oyranos printer support is so new (GSoC 2009).
>
> #5. This does not currently exist as far as I can tell either on the back end
> (IE. CUPS and friends) or in any of the existing apps that are CM aware.  On
> the other hand in the open source world there are only a handful of apps that
> are CM aware at all and only a subset of those know anything about ICC profiles
> in the printing work flow (IE. most color manage to the display only - GIMP is
> an example of a limited CM aware app).  I think if there were a simple to use
> well documented API for this that those apps that need it would be modified to
> use it fairly quickly.  Particularly since the developers of most of those
> apps are members of at least one of the email lists that are part of this
> thread.   But the issue is that there needs to be a way to do this either
> through specialized applications like PhotoPrint or by having a switch on the
> CPD if no apps with this ability are available.  That is I would consider
> having a CPD switch for this to be a transition issue that would be removed
> once we had applications available that could use the no-back end CM API call.

Regarding a No Colourmanagement mode I fully agree.

> Hal

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

Re: [Printing-architecture] [Gimp-print-devel] [Openicc] Colour

[kate price]

Hi all

I've been reading all posts with varying levels of comprehension, but  
always with great interest.
To get back to my own concern, design of the UI for the CPD I'm going  
to boil this down to a quite high level statement which expresses the  
direction we believe the CPD should take. This is not only in response  
to the information gleaned here, but also very much in the context of  
our own convictions about the design of a print dialogue for all users.

So:

*If printing doesn't exist, colour printing also doesn't exist. Terms  
and concepts like colour management and ICC profiles have no meaning  
to a vast majority of users. Most users  want their colour printing to  
just work with no intervention required.

*Successful colour printing is as much about media as it is about the  
ink which goes on it. This means that for successful colour printing  
from the CPD a holistic picture of the print is required.

*Detailed controls of colour settings, detailed proofing of colour  
fidelity etc. is far better suited to and achievable within the print  
preview of a suitable application (GIMP, photoshop etc etc).

*Professionals and power users and enthusiasts  need to be able to use  
profiles and presets they have made or downloaded.  Therefore there is  
a clear need to use colour presets directly from the CPD, even if it  
is accepted that they cannot be made within the CPD.


Practically this means that:

*Color controls are not in the CPD or at the very most, barely there.

*Let the API take the strain: i.e automatic colour control override is  
desirable and achievable.

*Focus on at the practical process of getting presets into our CPD  
interface to work for enthusiasts and professionals alike.

It seems to me that a good focus from here would be to really get the  
presets working for the most sophisticated users (as well as others).  
This would be an area where further imput from interested parties  
would be welcomed because I believe that there is a great opportunity  
already here within the current design of the CPD. Surely integrating  
the making, saving and using of these presets into a  smooth and  
comprehensible part of a print workflow would be a great -and  
importantly- achievable step forward that we can provide?

Kate

Kate Price
man + machine interface works

Re: [Printing-architecture] [Gimp-print-devel] [Openicc] Colour

[Kai-Uwe Behrmann]

Am 16.11.09, 13:09 +0100 schrieb kate price:
> Hi all
> 
> I've been reading all posts with varying levels of comprehension, but  
> always with great interest.
> To get back to my own concern, design of the UI for the CPD I'm going  
> to boil this down to a quite high level statement which expresses the  
> direction we believe the CPD should take. This is not only in response  
> to the information gleaned here, but also very much in the context of  
> our own convictions about the design of a print dialogue for all users.
> 
> So:
> 
> *If printing doesn't exist, colour printing also doesn't exist. Terms  
> and concepts like colour management and ICC profiles have no meaning  
> to a vast majority of users. Most users  want their colour printing to  
> just work with no intervention required.

Agreed, most users do not need to know about techical details.
As soon as they want colour to just work, ICC colour management is the 
right choice to get this done. So at least the results of colour 
management are understood, and meeting of expectations regarding colour is 
part of how they are satisfied with the print system.

> *Successful colour printing is as much about media as it is about the  
> ink which goes on it. This means that for successful colour printing  
> from the CPD a holistic picture of the print is required.

Colour experts will largely agree.

> *Detailed controls of colour settings, detailed proofing of colour  
> fidelity etc. is far better suited to and achievable within the print  
> preview of a suitable application (GIMP, photoshop etc etc).

Is it planed to omit a detailed print preview? I have seen this kind of 
windows and modes in office applications,  mainly to walk through multi 
page documents before printing. They are very useful there.

How is the print preview integrated with CPD? Shall it work like a 
button inside CPD, which calls into the main application with some 
parameters to render the preview on application side? Or is it a tab? 
A link to according documentation would be great.

> *Professionals and power users and enthusiasts  need to be able to use  
> profiles and presets they have made or downloaded.  Therefore there is  
> a clear need to use colour presets directly from the CPD, even if it  
> is accepted that they cannot be made within the CPD.

How can we learn details about CPD presets? What makes it difficult to 
dump out a CPD preset?
 
> Practically this means that:
> 
> *Color controls are not in the CPD or at the very most, barely there.

While the idea was provided to hide low level ICC options, I would 
see it as an disadvantage to have the ICC related controls not 
available and would favour to make the outlined CM controls available in 
CPD through a experts only panel, which has a reset button for getting 
easily to the defaults.
But if not, how can applications plug-in a own CM panel into CPD?


As well looking at Windows and osX print dialogs, there are a lot of 
colour controls. These are not the expert controls you wrote about. 
Nevertheless they are a big selling point for photo printers.
Delivering vivid, natural, sepia and other effects on button click 
including a canned ICC profile mode is typical integrated into driver 
panels of photo capable printers. Why would print manufacturers wast that 
space if it would be of no need?
As well I expect most home users have a photo mode in their printing 
device. They print mostly letters but from time to time as well images 
and flyers. So this kind of ICC colour controls matters.

> *Let the API take the strain: i.e automatic colour control override is  
> desirable and achievable.

You mean setting and freezing colour related controls as soon as a ICC 
profile is selected(?) This would be the correct mode for the use of ICC 
profiles. Somehow CPD has to know, which settings are colour related for 
the particular driver. This can eigther be transported through Oyranos or 
the profile itself, which again can be translated by Oyranos.

There will be people who complain about the missed capability to hand 
tweak their colours. This is quite natural. A way to satisfy those 
demand is to support effect profiles, which fits well with the point 
above.

> *Focus on at the practical process of getting presets into our CPD  
> interface to work for enthusiasts and professionals alike.
> 
> It seems to me that a good focus from here would be to really get the  
> presets working for the most sophisticated users (as well as others).  
> This would be an area where further imput from interested parties  
> would be welcomed because I believe that there is a great opportunity  
> already here within the current design of the CPD. Surely integrating  
> the making, saving and using of these presets into a  smooth and  
> comprehensible part of a print workflow would be a great -and  
> importantly- achievable step forward that we can provide?

A big advantage of dumping out a preset is better supportability. With 
dumped files, it is possible to send such a preset to a knowledgeable 
person for remote analysis.
Cloning presets is for administrators and for sharing among people equally 
useful.

Regarding ICC profiles, a preset package would need to include the ICC 
profile.

> Kate
> 
> Kate Price
> man + machine interface works

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

Re: [Printing-architecture] [Openicc] [Gimp-print-devel] Colour

[Chris Murphy]

On Nov 16, 2009, at 12:36 PM, Kai-Uwe Behrmann wrote:

> There will be people who complain about the missed capability to hand 
> tweak their colours. This is quite natural. A way to satisfy those 
> demand is to support effect profiles, which fits well with the point 
> above.


Abstract profiles could do these kinds of edits in the PCS. Either as an advanced  panel of sliders that institute edits in the PCS - a sort of on-the-fly abstract class  profile. Or a separate means of creating them and just allow a pop-up menu of selections. I like the slider approach.

I think it's important to not have effects baked into output device profiles.

Chris Murphy

Re: [Printing-architecture] [Openicc] [Gimp-print-devel] Colour

[Kai-Uwe Behrmann]

Am 16.11.09, 15:16 -0500 schrieb Chris Murphy:
> On Nov 16, 2009, at 12:36 PM, Kai-Uwe Behrmann wrote:
> 
> > There will be people who complain about the missed capability to hand 
> > tweak their colours. This is quite natural. A way to satisfy those 
> > demand is to support effect profiles, which fits well with the point 
> > above.
> 
> 
> Abstract profiles could do these kinds of edits in the PCS. Either as an advanced  panel of sliders that institute edits in the PCS - a sort of on-the-fly abstract class  profile. Or a separate means of creating them and just allow a pop-up menu of selections. I like the slider approach.
> 
> I think it's important to not have effects baked into output device profiles.

Can the effect profiles be applied in a late binding style - remotely 
after spooling?


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

Re: [Printing-architecture] [Openicc] [Gimp-print-devel] Colour

[Chris Murphy]

On Nov 16, 2009, at 8:08 PM, Gerhard Fuernkranz wrote:
>> 
>> Can the effect profiles be applied in a late binding style - remotely after spooling?
> 
> Well, where and when in the pipeline is the rasterizing is done? Once
> the document has been half-toned, it's rather impossible to apply color
> transformations any more (i.e. in case the final raster data were spooled).

I agree it's a bit of a challenge to make this happen with screened data, but I'd wonder why it's screened if it's not meant for immediate output?

If it's normalized to output space but NOT screened, an "effects profile" or "abstract" profile is relatively easy:

devicespace >PCS > abstract profile > PCS > devicespace

If the supported precision is at least 16bpc I'd consider it pretty much a non-issue. (ACE is 32bpc float precision.)

If it is screened, well, it's still absolutely doable but it's basically a 1-bit TIFF style workflow. I think there are probably other priorities, but I'm open to discussing this.


> 
> And applying an additional device -> PCS -> abstract -> PCS -> device
> transformation in a *separate* post-processing step (after converting
> the object colors to the color space associated with the printer's
> process color model, but before half-toning) will certainly not help to
> improve the overall accuracy of the color transformations,

I think if the precision level of the conversion is high enough, quantization is a non-issue. But there might be gamut issues...including abstract profile induced posterization.

> and some
> colors may already have been clipped, which cannot be undone any more
> afterwards by a de-saturation effect (though this clipping would have
> been avoided if the de-saturation would have been applied before
> applying the output profile). So I think the effects should be rather
> incorporated into the color transformation chain from object colors to
> the printer's process color model. Or alternatively, the intermediate
> color space before applying the effects would need to be rather PCS.

A soft proof that incorporates the abstract profile effect in the chain, as well as the output device profile, has clear benefits in avoiding undesirable gamut mapping problems.

> 
> Applying effects without integrating them into the profile seems also
> difficult to me, if one intends to use pre-computed device link profiles
> for the conversion from object colors to the printer's process color model.

Devicelink workflows are inherently extremely fragile, as presented by the ICC spec. Only a creative solution, that is not obviously prescribed by the ICC spec, can work around such problems. This may very well include *mandatory* PSID support (although I have yet to see explicitly documentation for this tag), or some mechanism for referencing at least the destination profile for the purpose of tagging the resulting data correctly once converted. The effect of an abstract profile would occur before this, but interestingly enough the aggressiveness of the abstract profile in terms of a saturation boost very possibly will affect the rendering intent.

i.e. with a null abstract profile, and use selects RelCol+BPC, but then decides that an abstract profile boosting saturation is preferred, might necessitate the perceptual intent in order to better manager the larger percentage of out of gamut colors as a result of applying the abstract profile that boosts chroma.

*shrug* It's an interesting challenge. The more advanced and imaginative the workflow gets, the more we run into problems with the ICC spec.


Chris Murphy

Re: [Printing-architecture] [Openicc] [Gimp-print-devel] Colour

[Kai-Uwe Behrmann]

Am 16.11.09, 20:23 -0500 schrieb Robert Krawitz:
>   Date: Tue, 17 Nov 2009 02:08:14 +0100
>   From: Gerhard Fuernkranz <nospam456@gmx.de>

>   And applying an additional device -> PCS -> abstract -> PCS ->
>   device transformation in a *separate* post-processing step (after
>   converting the object colors to the color space associated with the
>   printer's process color model, but before half-toning) will
>   certainly not help to improve the overall accuracy of the color
>   transformations, and some colors may already have been clipped,
>   which cannot be undone any more afterwards by a de-saturation
>   effect (though this clipping would have been avoided if the
>   de-saturation would have been applied before applying the output

It is really good to mention that for the record.

>   profile). So I think the effects should be rather incorporated into
>   the color transformation chain from object colors to the printer's
>   process color model. Or alternatively, the intermediate color space
>   before applying the effects would need to be rather PCS.
>
> That's why I think the intermediate color space should be high
> precision with extremely wide gamut.  I know memory and CPU isn't
> free, but I think arguing over 8 vs. 16 bits of precision is
> distinctly penny-wise and pound-foolish.

A)
One alternative would be to replace the object ICCbased profiles with ones 
which contain the abstract effect(s):
object space (sRGB) -> abstract effect(s) (CIE*Lab)
    ==> new profile (replacing sRGB)
If the input (object) profile has several tables, the unused ones can be 
omitted using only the wanted rendering intent. Its like a device link 
with a output colour space of CIE*Lab. Some refere to it as backing in a
profile. It would need to iterate over all PDF objects and replace their 
ICC profiles. The intermediate replacement ICC profile can be considered a 
additional conversion even if it does not alter any colour values. This is 
due to the interpolations during the profile table creation.

B)
An other alternative is to put the effect profile(s) into the job ticket 
for later usage during object colour conversion:
object space (sRGB) -> abstract effect(s) -> device space (printer)
But that largely depends on the spoolers capabilities. From a CM point of 
view that would be ideal, as it allows to follow a   as few as possible 
conversions strategy.

The colour binding can be moved from a early to a late stage with both 
alternatives. As well the output intent remains untouched as Chris Murphy 
suggested.  ... feature complete


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

Re: [Printing-architecture] [Openicc] [Gimp-print-devel] Colour

[Chris Murphy]

On Nov 16, 2009, at 8:23 PM, Robert Krawitz wrote:

> That's why I think the intermediate color space should be high
> precision with extremely wide gamut.  I know memory and CPU isn't
> free, but I think arguing over 8 vs. 16 bits of precision is
> distinctly penny-wise and pound-foolish.

It's fairly well established that printers do not need more than 8bpc. The challenge is getting the correct 8bpc. And this is most easily achieved by an intermediate space with 16bpc or higher. (e.g. ACE is 32bpc float for some time now, previously it was 20bpc integer regardless of source bit depth). So yeah, any conversions shouldn't be considering 8bpc at all. 16bpc works in most instances, and 32bpc float is just going to totally clobber the issue altogether so I'd work toward a 32bpc float model. And just totally eliminate any question about whatever serious torquing of color spaces may be instituted (by the pipeline or the user or the driver or LUTs or profiles, or whatever).

So *if* there is a debate it's between 16bpc integer and 32bpc float, not 8bpc or 16bpc.


Chris Murphy

Re: [Printing-architecture] [Openicc] [Gimp-print-devel] Colour

[Kai-Uwe Behrmann]

Am 16.11.09, 20:23 -0500 schrieb Robert Krawitz:
> precision with extremely wide gamut.  I know memory and CPU isn't
> free, but I think arguing over 8 vs. 16 bits of precision is
> distinctly penny-wise and pound-foolish.

I completely agree 16-bit can be a essential quality improovement. Its 
like looking through glass or no glass. If someone has no problems while 
looking on a surfaces through glass then be it.

If you want the best output in regards of fine shades, be warned of 8-bit 
source and 8-bit print files.
Printers capable of showing very smooth transitions of shades, are able to 
expose stepping coming from 8-bit source material since years. This is 
visible in smooth sourfaces like water, blurred image regions, sky and 
other gradient alike image regions. Dithering is a poore cirumvention and 
possibly sand for your eyes. Others may be trained and see the artificial 
habit of the banding artifacts coming from the 8-bit source material.
Keep in mind that most advertising material, arts prints, arts 
paintings behind thick glass and of course monitors have easily 
conditioned many peoples eyes to be very tollerant.

That said, for office paper, news paper and smaller than post card size 
prints 8-bit might be enough. This maps to the majority of printed 
imagery, but not to all printing demands.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

Re: [Printing-architecture] [Gimp-print-devel] [Openicc] Colour

[Hal V. Engel]

On Monday 16 November 2009 09:36:26 am Kai-Uwe Behrmann wrote:
> Am 16.11.09, 13:09 +0100 schrieb kate price:
> > Hi all
> >
> > I've been reading all posts with varying levels of comprehension, but
> > always with great interest.
> > To get back to my own concern, design of the UI for the CPD I'm going
> > to boil this down to a quite high level statement which expresses the
> > direction we believe the CPD should take. This is not only in response
> > to the information gleaned here, but also very much in the context of
> > our own convictions about the design of a print dialogue for all users.
> >
> > So:
> >
> > *If printing doesn't exist, colour printing also doesn't exist. Terms
> > and concepts like colour management and ICC profiles have no meaning
> > to a vast majority of users. Most users  want their colour printing to
> > just work with no intervention required.
> 
> Agreed, most users do not need to know about techical details.
> As soon as they want colour to just work, ICC colour management is the
> right choice to get this done. So at least the results of colour
> management are understood, and meeting of expectations regarding colour is
> part of how they are satisfied with the print system.
> 
> > *Successful colour printing is as much about media as it is about the
> > ink which goes on it. This means that for successful colour printing
> > from the CPD a holistic picture of the print is required.
> 
> Colour experts will largely agree.
> 
> > *Detailed controls of colour settings, detailed proofing of colour
> > fidelity etc. is far better suited to and achievable within the print
> > preview of a suitable application (GIMP, photoshop etc etc).
> 
> Is it planed to omit a detailed print preview? I have seen this kind of
> windows and modes in office applications,  mainly to walk through multi
> page documents before printing. They are very useful there.

I think the CPD design probably needs to be clarified for those who have not 
had a chance to review the current design.  The CPD has a print preview that:

1. Is always displayed unless the user says "just print" which bypasses the 
UI.

2. Has a fixed size and is fairly small.

3. The preview is NOT intended for proofing since it's small size makes it of 
limited usefulness for this and the apps that are used by users who need/want 
soft proofing generally already have this built in or available as a plug-in 
(GIMP, Scribus...).

While I am not sure that I totally agree with these design choices they are 
reasonable and are a good starting point for moving forward.

For more details on the UI design see

http://www.mmiworks.net/eng/publications/labels/openPrinting.html

> 
> How is the print preview integrated with CPD? Shall it work like a
> button inside CPD, which calls into the main application with some
> parameters to render the preview on application side? Or is it a tab?

The CPD does not use tabs.  See the above link for details on why this is the 
case.  Keep in mind that the CPD is designed for the new PDF based printing 
work flow so it expects that the app will pass it a PDF file and this is used to 
render the preview.  The same PDF is passed to the back end when the users 
commits the print job.

> A link to according documentation would be great.

See the above link.

> 
> > *Professionals and power users and enthusiasts  need to be able to use
> > profiles and presets they have made or downloaded.  Therefore there is
> > a clear need to use colour presets directly from the CPD, even if it
> > is accepted that they cannot be made within the CPD.
> 
> How can we learn details about CPD presets? What makes it difficult to
> dump out a CPD preset?

Users can create CPD presets and these are persistent.  A static set of 
presets are also configured in the PPD file by the driver vendor so that certain 
presets are vendor/device specific and always present.  IE. there are a set of 
presets that are specified by the vendor in the PPD file that are always present 
unless a local admin has modified the printer PPD file.

I don't know anything about extracting and sharing user created presets.  

> 
> > Practically this means that:
> >
> > *Color controls are not in the CPD or at the very most, barely there.
> 
> While the idea was provided to hide low level ICC options, I would
> see it as an disadvantage to have the ICC related controls not
> available and would favour to make the outlined CM controls available in
> CPD through a experts only panel, 

The CPD is for the most part controlled by the contents of the printer PPD 
file.  Controls are grouped and those groups are presented to users who can add 
or remove these groups from the controls that are displayed.  Controls can be 
in more than one group but are only displayed once.  In the CPD these groups 
are called tags.   By enabling or disabling these tags the user can make the 
CPD as simple or complex as they want within the limits of what is exposed in 
the PPD file.  In its simplest form the CPD only has controls to select 
presets, to select the queue, to enable the selection of tags and to select 
the number of copies printed along with the preview.

I believe that it is possible to have tags and controls that are not specified 
in the devices PPD file for doing things that are not printer specific.  This 
could be used to have a Color Management tag for those controls related to 
this functionality.  For users who choose one of the vendor created presets CM 
will likely be set to use the system default profiles and CM processing path.  

Advanced users should be able to create presets for printing targets that 
completely disable all color processing and other presets for certain types of 
prematched printing if the back end can not be configured to correctly handle 
profile selection.  I think we should be able to make the need for prematching 
a very rare occurrence if we can get Oyranos/CUPS and friends to work 
correctly.  But I think it could take some time to get all of this working the 
way we want.

Currently there are no CM controls available on the CPD unless those are in 
the devices PPD file (and none have this that I know of).
 
> which has a reset button for getting
> easily to the defaults.
> But if not, how can applications plug-in a own CM panel into CPD?
> 
> 
> As well looking at Windows and osX print dialogs, there are a lot of
> colour controls. These are not the expert controls you wrote about.
> Nevertheless they are a big selling point for photo printers.
> Delivering vivid, natural, sepia and other effects on button click
> including a canned ICC profile mode is typical integrated into driver
> panels of photo capable printers. Why would print manufacturers wast that
> space if it would be of no need?
> As well I expect most home users have a photo mode in their printing
> device. They print mostly letters but from time to time as well images
> and flyers. So this kind of ICC colour controls matters.
> 
> > *Let the API take the strain: i.e automatic colour control override is
> > desirable and achievable.
> 
> You mean setting and freezing colour related controls as soon as a ICC
> profile is selected(?) This would be the correct mode for the use of ICC
> profiles. Somehow CPD has to know, which settings are colour related for
> the particular driver. This can eigther be transported through Oyranos or
> the profile itself, which again can be translated by Oyranos.
> 
> There will be people who complain about the missed capability to hand
> tweak their colours. This is quite natural. A way to satisfy those
> demand is to support effect profiles, which fits well with the point
> above.
> 
> > *Focus on at the practical process of getting presets into our CPD
> > interface to work for enthusiasts and professionals alike.
> >
> > It seems to me that a good focus from here would be to really get the
> > presets working for the most sophisticated users (as well as others).
> > This would be an area where further imput from interested parties
> > would be welcomed because I believe that there is a great opportunity
> > already here within the current design of the CPD. Surely integrating
> > the making, saving and using of these presets into a  smooth and
> > comprehensible part of a print workflow would be a great -and
> > importantly- achievable step forward that we can provide?

I agree with this.  When I saw how the CPD was designed to work at the 
OpenPrinting Summit in April I was impressed by how flexible and user centric 
the UI design for the CPD is.  IMO it is the most advance printing UI in 
existence and it shows a lot of promise for moving things forward.  About the 
only things missing at this point are how CM should be presented and almost 
none of the vendor PPD files are setup to take full advantage of the CPD (PPD 
extensions were created to support these advanced CPD features and most PPD 
files do not use these yet). 

> 
> A big advantage of dumping out a preset is better supportability. With
> dumped files, it is possible to send such a preset to a knowledgeable
> person for remote analysis.
> Cloning presets is for administrators and for sharing among people equally
> useful.

Admins need a way to create presets that are available for all users of a 
given queue/printer.   Doing this by modifying the PPD file on the server is 
only acceptable as an interim measure. This is very important for the CM 
related presets for shared printers in organizations that need to have 
professionally configured color managed print queues.  For example color 
consultants/experts should be able to calibrate and profile a 
printer/media/drivers settings combination and then create a preset that will 
always set the printer up correctly (IE. select the correct paper tray, set 
the right driver settings, use the correct profile, lock down any controls that 
affect color...) and that preset should be available to any user who uses that 
printer/queue.  Then all users have to do to get a hand configured color 
managed print is to select that preset.

This would be useful even for local print queues.  For example my wife likes 
to print photos and complains about how complex it is to get the same quality 
of results that I do.  Her complaints are justified IMO since it requires 
jumping through hoops that are difficult for non-color experts to understand.  
If I could configure a preset that did everything to insure that the correct 
things would happen I could label that preset something like "Print Photos on 
XXX Paper" and all she would have to do is load the correct paper into the 
printer and select the custom preset.  I am sure that this would make my wife 
happy and it would also mean that I would not have to assist her every time 
she wanted to print some photos (which I think would also make her happy).

> 
> Regarding ICC profiles, a preset package would need to include the ICC
> profile.
> 
> > Kate
> >
> > Kate Price
> > man + machine interface works
> 
> kind regards
> Kai-Uwe Behrmann
> 

Re: [Printing-architecture] [Openicc] [Gimp-print-devel] Colour

[Chris Murphy]

At least on OS X, the API is the means to set two flags: object source and OutputIntent (destination profile and implicit source profile for device color). The application doesn't directly set these. It has to ask for it to be set via an API. And then only later if the two flags (color spaces) are correctly set, is color management disabled at the raster stage.

Putting objects into DeviceRGB/CMYK/Gray/N, instead of ICCBased color space, with a required OutputIntent could be a way to inform the system to not perform color management. But as Graeme points out it could be a different flag entirely. Also, I don't know what the print spool file format is in on Linux, so perhaps that language is more easily extended than PDF.

PDF/X-3 is just one possible model. It doesn't have to be followed exactly. But it's a good model. (I'm calling it a model because we can follow its workflow prescriptions without using the actual file format.)

PDF/X-4 which adds transparency support to PDF/X-3. As I've implemented Ghostscript based proofing for high end clients, I'm confident its transparency support works well.

PDF/X-5 implements externally referenced images and ICC profiles, which could come in handy.

PDF 2.0 spec will add explicit BPC (black point compensation) support in the file format, which means the ability to set a per object flag for BPC on or off. And that should be considered since perceptual and relcol transforms aren't ideal for most images, in an ICC v2 context. (In v4, perceptual would be the default intent. In v2, relcol + bpc should be the default.)

You may want multiple OutputIntents. Currently all of these specs use just one, following a "one PDF, one output device condition" sort of philosophy. But it's imaginable having a single print job for a small book and cover, where there are different intents for the cover, and the interior stock. Or a book that's mostly black and white but with some color image inserts in the middle of the book.

Anyway, I think in the near term PDF/X-4 along with BPC support make the most sense to me.

Chris Murphy

On Nov 16, 2009, at 12:10 AM, Kai-Uwe Behrmann wrote:

> Am 14.11.09, 17:11 +1100 schrieb Graeme Gill:
>> Chris Murphy wrote:
>>> filter, and also ColorSync) to not convert the target. Presently on Mac OS the
>>> application of choice is Photoshop, with which we are presently having problems because
>>> the No Color Management based PDF spool file has different profiles set for the profile
>>> target object, and OutputIntent, causing ColorSync to color manage. It autoconfigures
>>> newer print driver settings correctly, but the PDF spool file is malformed, so we get a
>>> converted profile target.
>> 
>> Yes, basically this is a really dumb API for turning color management off.
>> The right way to do it is to have a flag that turns color management off,
>> rather than relying on the software to figure out what profile is being
>> used for the end device, and labeling the file as already being in that
>> space. It's easy to demonstrate that this is sematically incorrect -
>> if you were to spool the file and then replay it after the device
>> profile has been changed, it will print incorrectly.
> 
> I am not familiar with such a flag. So I may ask, where does this apply to 
> which API? The print API while sending data which gets converted to PDF?
> The CMS, which is responsible to do the colour conversion or has in that 
> special case to omit a conversion? ... or the spooling system? ...
> 
> 
> Following  Chris' explanation, a print system "correctly" supporting 
> Device(RGB/CMYK/GRAY/N) in PDF/X-3 will have a path to pass all colour 
> management conversions unaltered. Could this become a simple means of 
> implementing Mike Sweets less is more scheme of hiding CM controls? 
> It would mean generate according targets and send them through CPD as file 
> to the selected printer.
> 
> 
> Still unresolved is the per paper ICC profile selection. To solve that 
> point CPD would be in need to add custom entries to non traceable 
> variables. These are mainly media and ink types which a driver has 
> currently no way to know of in a programatic manner.
> 
> 
> kind regards
> Kai-Uwe Behrmann
> -- 
> developing for colour management 
> www.behrmann.name + www.oyranos.org
> 
> _______________________________________________
> openicc mailing list
> openicc@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc

Re: [Printing-architecture] [Gimp-print-devel] [Openicc] Colour

[Alastair M. Robinson]

Hi :)

Michael Sweet wrote:

> I humbly suggest that what you want is a utility that allows the user to 
> print targets and generate/install ICC profiles for a particular 
> combination of printer, media, and other settings. If you have to select 
> a profile at print time, then the printing workflow is broken.

I have to disagree here.  I have three different "grades" of glossy 
photo paper here, from different manufacturers.  In terms of the amount 
of ink they'll take, and thus the correct print settings, they're pretty 
much identical, but prints do look different on each, and they have a 
very different "feel".  Which of the three I use depends on how 
"prestigious" I want a print to look, traded off against whether I want 
to use the most expensive paper.

Each paper type has (and needs) its own profile, yet the printer driver 
has no way of telling which of the three I'm using since the print 
settings are identical.  Thus, in my opinion, a printing workflow which 
doesn't allow me to set a profile at print time is broken.

At best the print dialog can select a sane *default* profile, but it's 
imperative that if the user "knows better" it can be overridden.

All the best
--
Alastair M. Robinson

Re: [Printing-architecture] [Gimp-print-devel] [Openicc] Colour

[Hal V. Engel]

On Saturday 14 November 2009 03:05:55 am edmund ronald wrote:
> Hi to you too :)
> 
>  Yes, being able to override any built-in or vendor supplied profile
> is obviously a necessity for power-users, and one which might be
> hidden somewhere in an "Options..." dialog which then allows saving
> named presets.
> 
>  On the other hand, printer vendors will resist easily accessible
> customisation -just as they resist user-profiling- because convincing
> Jane User that she will only get good color by using the vendor's
> listed media is their main tool to sell their branded expensive media.
> 
>  Everybody in this cluster :) has conflicting interests; but I wish
> that sane behavior would be *speedily restored * for us color
> consultants and photographers to get on with our life, while the
> solution to the world's printing problems gets debated. Please,
> someone write an utility to patch the driver -it's open source, right?
> - to enable deviceRGB and put us out of our misery.
> 
> Edmund

I see that this thread has been expanded to some additional lists and these 
folks may not know what this is really about since they are coming into this 
in the middle of the thread and just to make sure that they understand where 
this is coming from here is a little back ground.  This started on the email 
list for the OpenPrinting group which is part of the Linux Foundation to 
discuss how color management should be handled in the new Common Print Dialog 
(CPD).  This was quickly expanded to the OpenICC and GutenPrint email lists 
since these three lists are the primary communications points for those 
working on open source printing and color management. The reason that we are 
hashing out these OS/X, ColorSync issues in this thread is that we don't want 
to repeat the same mistakes on our open systems as we add color management.  

The issues Edmund brings up involve ColorSync, various vendor supplied OS/X 
printer drivers and perhaps certain applications (Photoshop has been 
mentioned).  None of these are open source so the open source community can't 
be of much help other than making sure that we don't make the same mistakes on 
our systems.

However I think we got a little side tracked and I think we need to refocus on 
the original purpose of this thread (IE. how to handle color management in the 
CPD).  The main thing we should get out of this thread is that there needs to 
be a print path that allows for convenient printing of profiling and 
calibration targets as well as prematched output so that photographers and 
color experts/consultants can do their work without having to jump through all 
kinds of (perhaps hard to find) hoops.  At the same time end users should not 
even see these CM related settings unless they pull up a special part of the 
UI that is intended for advanced color management savvy users.  

There are clearly two use cases here:

1. Your average user - the vast majority of all printing - KISS principle 
applies.

2.  Photographers, color experts... 

These are very different use cases and they fundamentally conflict with each 
other.  #1 requires that the UI and work flow be as simple as possible - it has 
to work for even the most naive user - where as #2 requires a high degree of 
control and a high level of user expertise.   I think the tension we are 
seeing in this thread is about the conflict between these two use cases.

I also agree with Edmund that it should be possible to allow saving named 
presets.  The current design of the CPD does this so at this point I think 
this is a non-issue for our open systems design since it is already included. 

Edmund also mentioned vendor branded media and the fact that much of what we 
see in the vendor supplied drivers is designed to force users to purchase that 
branded media.  This is spot on since in many cases the printer vendors make 
almost no money on the sale of the printer (at least on consumer level 
devices) but make up for that in spades when they sell their expensive high 
profit margin media for the printer.  A user might spend only $100 to buy a 
consumer level printer but over it's life they might spend 10 or 20 times that 
much on paper and ink.  That is where these vendors really make their money.  
We should not let this get in the way of making sound design choices like it 
appears to have on closed systems.

Hal

> 
> 
> 
> 
> On Sat, Nov 14, 2009 at 11:16 AM, Alastair M. Robinson
> 
> <blackfive@fakenhamweb.co.uk> wrote:
> > Hi :)
> >
> > Michael Sweet wrote:
> >> I humbly suggest that what you want is a utility that allows the user to
> >> print targets and generate/install ICC profiles for a particular
> >> combination of printer, media, and other settings. If you have to select
> >> a profile at print time, then the printing workflow is broken.
> >
> > I have to disagree here.  I have three different "grades" of glossy photo
> > paper here, from different manufacturers.  In terms of the amount of ink
> > they'll take, and thus the correct print settings, they're pretty much
> > identical, but prints do look different on each, and they have a very
> > different "feel".  Which of the three I use depends on how "prestigious"
> > I want a print to look, traded off against whether I want to use the most
> > expensive paper.
> >
> > Each paper type has (and needs) its own profile, yet the printer driver
> > has no way of telling which of the three I'm using since the print
> > settings are identical.  Thus, in my opinion, a printing workflow which
> > doesn't allow me to set a profile at print time is broken.
> >
> > At best the print dialog can select a sane *default* profile, but it's
> > imperative that if the user "knows better" it can be overridden.
> >
> > All the best
> > --
> > Alastair M. Robinson
> 
> ---------------------------------------------------------------------------
> --- Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>  30-Day trial. Simplify your report design, integration and deployment -
>  and focus on what you do best, core application coding. Discover what's
>  new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Gimp-print-devel mailing list
> Gimp-print-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> 

Re: [Printing-architecture] [Openicc] [Gimp-print-devel] Colour

[Hal V. Engel]

On Friday 13 November 2009 08:56:12 am Chris Murphy wrote:
> It depends entirely on how it's implemented.
> 
> All driver dialogs on Windows and Mac OS (not sure about Linux, but I
>  suspect it's the same) are not the actual driver itself, merely the OS
>  drawing those features on-screen. The user makes the settings, including a
>  "No Color Management" option. But that selection does NOT directly
>  communicate with the driver. It's capture metadata that the operating
>  system includes into a print spool file (and/or corresponding job ticket
>  file). Later, that print spool file and included metadata with the
>  captured driver settings, is passed onto the manufacturer's print driver
>  and interpreted - i.e. you get the "Off" LUT instead of an sRGB LUT or
>  Adobe RGB LUT.
> 
> So that's already a "smart" or "automatic" mechanism, because there is no
>  direct mechanism anyway.

On most *nix (non-OS/X) systems where users are trying to do color critical 
work the users will be using the GutenPrint drivers if there is a GutenPrint 
driver for their printer(s).   Not those from the device vendor.  In many 
cases the device vendor does not even have a *nix driver for the device. 

When using the GutenPrint driver the user is interacting directly or nearly 
directly with the driver and has a degree of control that is far beyond what 
OS/X or Windows users have over these devices.  That interaction is generally 
controlled by the printer driver PPD file.  This includes the ability to do 
RGB, CMYK and DeviceN (if the printer has more than 4 channels) printing as 
well as to change things like ink limits, GCR, sub-channel transitions and 
LUTS.  The UI for doing some of these things is a little on the primitive side 
however.

In addition work is underway on a tool that will create calibration 
(linearization) curves for GutenPrint driven printers using various 
measurement instruments (actually using ArgyllCMS to do the measurements).   
This tool is called GPLin and is still an alpha level tool but it is getting 
closer to being a useful tool as it goes through regular updates by it's 
author (Alastair M. Robinson).

But to Chris' main point.  For RGB and CMYK printing paths there is indeed a 
black box built into the driver that is doing some "color management" but with 
our open source drivers we also have true DeviceN available.  I have done 
extensive measurements of the response curves of my GutenPrint driven Epson 
R2400 printer and for the most part it's CMYK channels have fairly smooth 
response curves with minimal anomalies in the dark to light ink transitions 
although the magenta channel could be improved in this regard.  In other words 
the GutenPrint driver presents this printer as fairly well behaved CMYK device 
and CMYK profiles I have created for it using ArgyllCMS give very good results.  
I suspect that the same thing is true for those who are using this 
driver/printer combination but are using it's RGB mode and it is likely true 
for most of the Epson printers supported by the GutenPrint drivers.  

> 
> Further, on Mac OS X for some time now, there is no explicit off switch for
>  ColorSync. Apple requires multiple square dances with a dog, a pig, and a
>  pony, under a full moon, in order to get ColorSync to piss off. ColorSync
>  is only turned off through null transforms. Only when the source profile
>  for content is identical to the destination profile, is ColorSync
>  disabled.
> 
> In order to make this work, Apple has a rather convoluted mechanism for
>  certain applications to request, NOT the disabling of ColorSync, but to
>  get the current canned manufacturer profile registered for a particular
>  print mode. The application must then bogusly tag objects with that
>  profile, in order to achieve this null transform.

And this is critical for those folks who are doing color critical work.  If we 
don't have a straight forward way to print profiling/calibration targets then 
there is a problem.  

Robert Krawitz quotes Eric Crampton in the footer of all of his emails thusly.

"Linux doesn't dictate how I work, I dictate how Linux works."

I think it is fitting to use that quote to help make the point that many Linux 
users expect to be in total control of their machines.  Anything that reduces 
their control will at best be viewed with suspicion.  For example I have been 
running patched and hand modified kernels for a long time and I have other 
software on my system that I have modified so that it works the way I want.  No 
Windows or OS/X user would even think about running a customized kernel yet it 
is fairly common for Linux users. 

On the other hand since we are dealing with open source code the problems 
listed below should not happen.  For example if the drivers don't work the way 
they should and if the vendor will not fix the issues then we can fork the code 
and get things fixed.  We are NOT dependent on hardware vendors to get things 
fixed.

> 
> And as we are seeing with the clusterf8ck.com situation we've got going on
>  with Mac OS X, newer Epson drivers, and Photoshop, we've got ColorSync
>  converting ICC profile targets. And if we recall history, we've had all
>  kinds of problems with Mac OS X and printing color reliably.
> 
> In my view, Apple made a colossal mistake by attempting to follow a PDF/X-3
>  like format for their print spool file format, but then deciding to go on
>  a vendetta against DeviceRGB which is a rather important color space in 
>  PDF/X-3 to explicitly indicate such content should not be color managed if
>  the content is sent to the device it was intended for. Instead, Apple is
>  double tagging the PDF spool file: first the individual objects are aways
>  being tagged, instead of say prematched data and profile targets being set
>  to DeviceRGB, and then yet again with an OutputIntent profile.
> 
> Now, the OutputIntent tag should always be set to something. That indicates
>  the intended output space, and for prematched data can be used to soft
>  proof the print job before it goes to the printer. But in the case of
>  calibration/characterization/prematching, the color space for those
>  objects should be DeviceRGB (I am referring to desktop inkjet printers,
>  treated as RGB output devices). 

I think the same things should be true for DeviceCMYK since this is simply a 
variation on the same use case.

>  But Apple has banished DeviceRGB and
>  disallows any specialized applications from using it. Instead, they
>  require the object to be tagged with a profile, and for the OutputIntent
>  to also be set with the same profile. If an application does not submit a
>  source profile for its content, the OS will assume a color space and tag
>  that data when the PDF spool file is written to disk. So there is no way
>  around this. (Generic RGB is what's used on 10.5 and older, sRGB on 10.6
>  and newer).
> 
> Apple has argued that untagged data is evil. Yet the great thing about
>  PDF/X-3 (or X-4 or X-5) is that DeviceRGB is special because it is an
>  explicit indication that content to the intended device is not to be color
>  managed, but it still has an implicit source profile. And that's the
>  OutputIntent. So DeviceRGB isn't untagged.

The problem of course is that in the larger world many PDF documents use 
DeviceRGB as a way of doing untagged RGB.  In fact I don't think the PDF 
specification allows for untagged objects so the only option people have for 
creating PDF documents where they don't have to tag the objects in very 
specific ways is to use DeviceRGB.  Apple appears to be trying to "fix" this 
problem and their fix has the unintended consequence that it makes 
calibration/characterization/prematching very difficult.  My gut tells me that 
they are trying to fix this problem in the wrong place and this is why we are 
having these issues.

> 
> The problem is, driver vendors who don't get their print modes and
>  associate profiles, and default profiles, registered correctly with the OS
>  for some reason. It's been an on-going problem. Canon had the problem and
>  seems to have fixed it. HP had the problem, and seems to have fixed it.
>  Epson had the problem, and sometimes gets it fixed, and them sometimes
>  (like now) regresses back to broken behavior. 

This whole area is very difficult because of it's complexity.  There was lots of 
work this summer on Oyranos in this area and I think it is worth while to 
follow up on that work to see if we can't iron out any remaining issues so 
that a linux (or other FOSS OS)/Oyranos/CUPS/... system really works the way 
it should.  But lets be clear that this will not be easy to solve.

>  When they don't work
>  correctly, it can mean ColorSync will become invited to the party when it
>  wasn't asked to, but more importantly when we don't want it to:
>  calibration/characterization/prematching.
> 
> So, a user selectable off switch we do not have. And we don't even really
>  have a developer off switch either, but rather an indirect means of doing
>  this through a convoluted, and unreliable, null transform dependency.
> 
> If the architecture is designed correctly to fail safe, instead of fail
>  chaos,we would not need a driver option for Off (No Color Management).
>  That option, is a big fat lie anyway. Obviously color management of some
>  sort is required because inkjet printers do not have merely three inks
>  comprised of red, green and blue.

This is back to the RGB only assumption of Windows and OS/X.  Many of our open 
source printer drivers support RGB as well as CMYK and true DeviceN.  Since we 
have more flexible drivers available I think it changes how we should approach 
this problem to some extent.

Hal

Re: [Printing-architecture] [Openicc] [Gimp-print-devel] Colour

[Chris Murphy]

On Nov 13, 2009, at 8:32 PM, Hal V. Engel wrote:

> On Friday 13 November 2009 08:56:12 am Chris Murphy wrote:
>> But in the case of
>> calibration/characterization/prematching, the color space for those
>> objects should be DeviceRGB (I am referring to desktop inkjet printers,
>> treated as RGB output devices). 
> 
> I think the same things should be true for DeviceCMYK since this is simply a 
> variation on the same use case.

It is. Same for DeviceGray. Same for DeviceN.


>> Apple has argued that untagged data is evil. Yet the great thing about
>> PDF/X-3 (or X-4 or X-5) is that DeviceRGB is special because it is an
>> explicit indication that content to the intended device is not to be color
>> managed, but it still has an implicit source profile. And that's the
>> OutputIntent. So DeviceRGB isn't untagged.
> 
> The problem of course is that in the larger world many PDF documents use 
> DeviceRGB as a way of doing untagged RGB.  In fact I don't think the PDF 
> specification allows for untagged objects so the only option people have for 
> creating PDF documents where they don't have to tag the objects in very 
> specific ways is to use DeviceRGB.  Apple appears to be trying to "fix" this 
> problem and their fix has the unintended consequence that it makes 
> calibration/characterization/prematching very difficult.  My gut tells me that 
> they are trying to fix this problem in the wrong place and this is why we are 
> having these issues.

The PDF spec certainly allows for untagged objects. And so do the flavors of PDF/X. 

In PDF/X-1a objects can be only DeviceGray and DeviceCMYK. DeviceRGB is disallowed. OutputIntent must be CMYK, and is simultaneously the implied source and destination profile for all content in the document (i.e. no further conversions for output, unless diverted, e.g., for proofing).

In PDF/X-3 the OutputIntent can be RGB as well. If it's RGB, then DeviceRGB is allowed, but DeviceCMYK is not. If the OutputIntent is CMYK, then DeviceCMYK is allowed, but DeviceRGB is not. Additionally, ICCBased is allowed which means multiple objects in a PDF using multiple color spaces each defined by an ICC profile - which makes them all ICCBased (an RGB object tagged with Adobe RGB 1998 is considered to be ICCBased; a CMYK object tagged with GRACoL2006_Coated1 is also considered to be ICCBased - these are all considered to be in a color space OTHER than the OutputIntent color space and will be color managed prior to output).

There is a good reason why device spaces exist in these specifications. It was simply unworkable otherwise, to require everything in PDF destined for print, to be ICCBased. While on the other hand, requiring an OutputIntent makes sense for a PDF that's intended for output on a particular device.

> This is back to the RGB only assumption of Windows and OS/X.  Many of our open 
> source printer drivers support RGB as well as CMYK and true DeviceN.  Since we 
> have more flexible drivers available I think it changes how we should approach 
> this problem to some extent.

Sure.

What is not allowed in a PDF/X-3 framework is DeviceRGB and DeviceCMYK at the same time. For one it usually doesn't make sense. For another there isn't yet a mechanism in the spec for multiple instances of OutputIntent, on a page by page basis, for example (implying a single print job, containing pages with more than one possible print destination). This is being worked on, however. What you are talking about is a case where there aren't multiple physical destinations, but multiple virtual ones by virtue of the entry color space into the black box. And so I can see how this newer model might be applicable on Linux.


Chris Murphy

Re: [Printing-architecture] [Openicc] [Gimp-print-devel] Colour

[Hal V. Engel]

On Friday 13 November 2009 08:51:17 pm Michael Sweet wrote:
> On Nov 13, 2009, at 4:04 PM, Robert Krawitz wrote:
> > ...
> > Gutenprint absolutely provides a true DeviceN color path (for Epson
> > printers, at any rate).  We just don't have a reasonable vehicle for
> > exposing it to end users.
> 
> Right, as a "halftone module" Gutenprint actually offers much more than
>  most vendor solutions, however as a CUPS driver it has no way to expose
>  this since no RIP filter supports more than 4 channels.

Of course right now we don't have any open source *toraster filters that are 
color management aware and the only reasonable way to drive a DeviceN, where N 
> 4, device is to use ICC profile driven separations.  Since work is underway 
on the new pdftoraster filter to add CM support shouldn't it be capable of 
doing DeviceN separations if it is supplied a DeviceN output ptofile?  After 
all we have CMMs (LCMS) that support DeviceN profiles so it should be fairly 
simple for the new pdftoraster filter to generate the correct separations if 
the device profile is a DeviceN profile or if the PDF spool file has been 
prematched using a DeviceN profile.  What happens now if CUPS gets a PDF spool 
file that has been prematched to DeviceN?  Does it fail even if the device 
supports DeviceN and the separations are correct for that device?  Or does it 
convert it to some other format like CMYK?

I thought that GPLin was driving Epson printers as DeviceN devices.  But I may 
not have that correct.  Alastair care to comment?

> 
> > I'm dubious of sRGB-only command sets for inkjet printers.  It
> > artificially restricts the available gamut, and doesn't work if you
> > use a medium other than that specified by the manufacturer.
> 
> Like it or not, you're going to see more sRGB/AdobeRGB-only devices in the
>  future, even from Epson. Only the high-end printers will support a DeviceN
>  mode that can be used by third-parties...

Again almost no one here is using the hardware vendor supplied drivers.  So I 
don't think it matters much what they do.  Our GutenPrint driven printers will 
continue to support DeviceN and CMYK print modes (even on low end devices) 
regardless of what the hardware vendors choose to do other than refusing to 
supply documentation for the printers communications protocol.  Some vendors 
have been refusing to supply this documentation for a long time but these 
vendors end up not having much penetration into the FOSS market so they are 
seeding this market segment to those vendors that supply the documentation 
needed to write open source drivers.

Hal 

Re: [Printing-architecture] [Gimp-print-devel] [Openicc] Colour

[Alastair M. Robinson]

Hi :)

Hal V. Engel wrote:

> I thought that GPLin was driving Epson printers as DeviceN devices.  But I may 
> not have that correct.  Alastair care to comment?

You have that correct - GPLin does indeed do DeviceN for Epson printers, 
and includes a "printdevicen" utility to print a multi-channel TIFF in 
raw mode.  You still need some way to get your data into DeviceN raster 
format in the first place, of course - so far I've used it just with 
multi-channel Argyll targets for experimenting with linearization.  In 
CUPS terminology, it's analogous to rastertogutenprint, and you'd still 
need a DeviceN-capable pdftoraster.

Which brings me to one difficulty we have with DeviceN profiling - 
there's currently no way as far as I know, to create DeviceN profiles 
without using commercial software on Windows or Mac.  Don't get me 
wrong, I'm not a particularly staunch FOSS purist - but the cost of such 
specialist software is a significant barrier-to-entry.

All the best,
--
Alastair M. Robinson

Re: [Printing-architecture] [Gimp-print-devel] [Openicc] Colour

[Alastair M. Robinson]

Hi :)

Robert Krawitz wrote:

> When I say "DeviceCMYK*", I mean CMYK variants (additional light
> inks).  Last I played with it, it didn't support inks with
> non-traditional hue values.

It attempted to support them - it just didn't *work*, thanks to a few 
typos and bugs!

All the best,
--
Alastair M. Robinson

[Printing-architecture] Last OP Meeting - Mon/Tue - 23/24 Nov 2009 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20091123.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 14 MB long, 42 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 26 Jan 2010 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20100126.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 28 MB long, 1 hour and 21 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 16 Feb 2010 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20100216.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 14 MB long, 42 minutes of talking.

[Printing-architecture] Last OP Summit Planning Meeting - Wed - 17 Feb 2010 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting Summit planning 
meeting to the OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-summit-2010/OP-Summit-2010-Prep1-20100217.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 25 MB long, 1 hour and 13 minutes of talking.

[Printing-architecture] Last OP Meeting - Mon/Tue - 1/2 Mar 2010 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecon/OP-Meeting-20100301.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 14 MB long, 42 minutes of talking.

[Printing-architecture] Last OP Summit Planning Meeting - Wed - 17 Mar 2010 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting Summit planning 
meeting to the OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-summit-2010/OP-Summit-2010-Prep3-20100317.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 18 MB long, 52 minutes of talking.

[Printing-architecture] Last OP Summit Planning Meeting - Wed - 31 Mar 2010 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting Summit planning 
meeting to the OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-summit-2010/OP-Summit-2010-Prep4-20100331.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 11 MB long, 33 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 18 May 2010 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20100518.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 8 MB long, 26 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 8 June 2010 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20100608.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 14 MB long, 40 minutes of talking.

[Printing-architecture] Last OP Meeting - Mon/Tue - 14/15 Jun 2010 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20100614.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 13 MB long, 38 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 13 July 2010 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20100713.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 11 MB long, 32 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 10 August 2010 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20100810.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 4 MB long, 14 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 14 September 2010 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20100914.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 20 MB long, 59 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 12 October 2010 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20101012.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 21 MB long, 1 hour and 2 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 9 November 2010 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecon/OP-Meeting-20101109.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 26 MB long, 1 hour and 16 minutes of talking.

Re: [Printing-architecture] Last OP Meeting - Tue - 9 November 2010 - The Recording

[Warll Dressler]

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

I just remembered something, someone mentioned aproaching Nokia but getting
shut down. While the CPD might be a hard sell for nokia, which is primarly
interested in Meego as a phone os, one might be more successful with Intel
which is mostly interested in Meego for netbooks (and or Moorestone based
phones). The Meego stack is mostly standard Linux (X11, kernel.org kernel,
CUPS + foomatic) with QT for a widget framework. It shouldn't (easy for me
to say) be much harder to support Meego than say KDE. Since the stack is
young getting it in widespread use, at-least within Meego apps, should be as
simple as getting into the environment.

Daniel Dressler

PS: I'm simply a student programmer, please be gentle with me about any
errors. Or for the Japanese mailing list: よろしくおねがいします。

2010/11/9 Till Kamppeter <till.kamppeter@gmail.com>

> Hi,
>
> I have uploaded the recording of the last OpenPrinting meeting to the
> OpenPrinting server:
>
>
> http://www.openprinting.org/download/meetingnotes/op-telecon/OP-Meeting-20101109.mp3
>
> In general, recorded meetings I will upload to
>
> http://www.openprinting.org/download/meetingnotes/
>
>    Till
>
> P. S.: The MP3 is 26 MB long, 1 hour and 16 minutes of talking.
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture
>

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

Re: [Printing-architecture] Last OP Meeting - Tue - 9 November 2010 - The Recording

[Hal V. Engel]

On Friday, November 19, 2010 04:45:13 pm Warll Dressler wrote:
> I just remembered something, someone mentioned aproaching Nokia but getting
> shut down. While the CPD might be a hard sell for nokia, which is primarly
> interested in Meego as a phone os, one might be more successful with Intel
> which is mostly interested in Meego for netbooks (and or Moorestone based
> phones). The Meego stack is mostly standard Linux (X11, kernel.org kernel,
> CUPS + foomatic) with QT for a widget framework. It shouldn't (easy for me
> to say) be much harder to support Meego than say KDE. Since the stack is
> young getting it in widespread use, at-least within Meego apps, should be
> as simple as getting into the environment.
> 
> Daniel Dressler

I think that this assessment is basically correct.  Intel/Meego might be more 
likely to respond to this than Nokia.  Also the current CPD is tied to KDE and 
I think it would be better to decouple it from KDE and make it a 
generic/native Qt app.  This would in the long run make it more attractive to 
Nokia/Intel and other Meego vendors while at the same time supporting KDE.  If 
anything this should result in wider use of the CPD.

I have a contact at Intel who is part of the Meego team.  I am not sure if he 
can help but I will contact him to see if there is any interest.  Probably 
will not go anywhere but it can't hurt to try.

Hal 

Re: [Printing-architecture] Last OP Meeting - Tue - 9 November 2010 - The Recording

[peter sikking]

guys,

yes, I also have a contact on the meego platform.

however, we have to be careful here what we get into.

the cpd is designed for desktop computers, we did wake up to
the rise of netbooks and support those small screen sizes,
down to 800x600. but positively the design is made for
either a gnome or kde desktop environment with mouse/trackpad
input.

- anything handheld is not in scope;
- touch input is not in scope;
- environments where the distributor decided that the standard
  kde/gnome desktop environment is not suitable and build their own
  UI shell, are very much a grey-zone. case-by-case in/out of scope.

doing any (combination) of the above is simply another branch in
the design, which is work that then simply needs to be commissioned,
from design + usability to implementation + integration.

     --ps

         founder + principal interaction architect
             man + machine interface works

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

Re: [Printing-architecture] Last OP Meeting - Tue - 9 November 2010 - The Recording

[Till Kamppeter]

On 11/20/2010 09:24 AM, Hal V. Engel wrote:
> I think that this assessment is basically correct.  Intel/Meego might be more
> likely to respond to this than Nokia.  Also the current CPD is tied to KDE and
> I think it would be better to decouple it from KDE and make it a
> generic/native Qt app.  This would in the long run make it more attractive to
> Nokia/Intel and other Meego vendors while at the same time supporting KDE.  If
> anything this should result in wider use of the CPD.
>
> I have a contact at Intel who is part of the Meego team.  I am not sure if he
> can help but I will contact him to see if there is any interest.  Probably
> will not go anywhere but it can't hurt to try.

Hal, did you contact these people? Did you get any answer?

    Till

Re: [Printing-architecture] Last OP Meeting - Tue - 9 November 2010 - The Recording

[Hal V. Engel]

On Tuesday, November 30, 2010 01:58:42 pm Till Kamppeter wrote:
> On 11/20/2010 09:24 AM, Hal V. Engel wrote:
> > I think that this assessment is basically correct.  Intel/Meego might be
> > more likely to respond to this than Nokia.  Also the current CPD is tied
> > to KDE and I think it would be better to decouple it from KDE and make
> > it a generic/native Qt app.  This would in the long run make it more
> > attractive to Nokia/Intel and other Meego vendors while at the same time
> > supporting KDE.  If anything this should result in wider use of the CPD.
> > 
> > I have a contact at Intel who is part of the Meego team.  I am not sure
> > if he can help but I will contact him to see if there is any interest. 
> > Probably will not go anywhere but it can't hurt to try.
> 
> Hal, did you contact these people? Did you get any answer?
> 
>     Till


I just sent an email a few days ago.  Have not heard anything yet.

Hal

[Printing-architecture] Last OP Meeting - Tue - 14 December 2010 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecon/OP-Meeting-20101214.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 30 MB long, 1 hour and 27 minutes of talking.

[Printing-architecture] Last OP Meeting - Mon/Tue - 10/11 January 2011 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecon/OP-Meeting-20110110.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 12 MB long, 36 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 11 January 2011 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecon/OP-Meeting-20110111.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 29 MB long, 1 hour and 25 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 16 February 2011 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecon/OP-Meeting-20110216.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 23 MB long, 1 hour and 7 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 2 March 2011 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecon/OP-Meeting-20110302.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 20 MB long, 57 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 2 March 2011 - The Recording

[Till Kamppeter]

[ Resending due to broken link. ]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20110302.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 20 MB long, 57 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 4 May 2011 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20110504.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 18 MB long, 54 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 1 June 2011 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20110601.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 17 MB long, 50 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 13 July 2011 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20110713.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 20 MB long, 57 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 16 August 2011 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20110816.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 29 MB long, 1 hour and 25 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 14 September 2011 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20110914.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 10 MB long, 31 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 12 October 2011 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20111012.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 34 MB long, 1 hour and 38 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 9 November 2011 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20111109.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 24 MB long, 1 hour and 9 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 11 January 2012 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20120111.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 23 MB long, 1 hour and 8 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 1 February 2012 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20120201.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 25 MB long, 1 hour and 12 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 7 March 2012 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20120307.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 27 MB long, 1 hour and 19 minutes of talking.

[Printing-architecture] Last OP Summit Planning Meeting - Wed - 28 March 2012 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting Summit Planning 
Meeting to the OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-summit-2012/OP-Summit-2012-Prep3-20120328.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 21 MB long, 1 hour and 1 minute of talking.

[Printing-architecture] Last OP Meeting - Wed - 13 June 2012 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20120613.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 8 MB long, 24 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 5 September 2012 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20120905.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 21 MB long, 1 hour of talking.

[Printing-architecture] Last OP Meeting - Wed - 10 October 2012 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20121010.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 20 MB long, 59 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 10 October 2012 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20121114.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 9 MB long, 27 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 9 January 2013 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20130109.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 21 MB long, 1 hour and 1 minute of talking.

[Printing-architecture] Last OP Meeting - Wed - 13 February 2013 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20130213.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 18 MB long, 53 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 6 March 2013 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20130306.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 8 MB long, 24 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 17 April 2013 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20130417.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 8 MB long, 23 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 12 June 2013 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20130612.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 7 MB long, 21 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 10 July 2013 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20130710.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 9 MB long, 27 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 11 Sep 2013 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20130911.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 9 MB long, 28 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 2 Oct 2013 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20131002.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 5 MB long, 15 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 13 Nov 2013 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20131113.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 16 MB long, 46 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 7 Jan 2014 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20140107.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 14 MB long, 42 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 18 Feb 2014 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20140218.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 11 MB long, 32 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 4 Mar 2014 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20140304.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 9 MB long, 27 minutes of talking.

[Printing-architecture] Linux/MAC PostScript printing and embedded font

[Shane Lin]

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

All,
 
Does Linux/MAC printing via the PS driver still need to have embedded fonts at the printer side? or this is depend on the applications.
 
Thanks,
 
Shane
 
 



 
 		 	   		  

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

[Printing-architecture] Last OP Meeting - Tue - 1 Apr 2014 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20140401.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 9 MB long, 26 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 20 May 2014 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20140520.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 12 MB long, 35 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 10 Jun 2014 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20140610.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 15 MB long, 43 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 8 Jul 2014 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20140708.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 19 MB long, 55 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 19 Aug 2014 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20140819.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 19 MB long, 55 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 19 Aug 2014 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20140819.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 11 MB long, 32 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 15 Sep 2014 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20140915.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 15 MB long, 45 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 7 Oct 2014 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20141007.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 3 MB long, 11 minutes of talking.

[Printing-architecture] Last OP Meeting - Wed - 12 Nov 2014 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20141112.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 7 MB long, 22 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 9 Dec 2014 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20141209.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 14 MB long, 40 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 10 Mar 2015 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20150310.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

   Till

P. S.: The MP3 is 14 MB long, 42 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 12 May 2015 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20150512.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 11 MB long, 23 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 9 Jun 2015 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20150609.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 6 MB long, 12 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 7 Jul 2015 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20150707.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 18 MB long, 39 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 1 Sep 2015 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20150901.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 18 MB long, 38 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 10 Nov 2015 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20151110.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 20 MB long, 44 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 1 Dec 2015 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20151201.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 16 MB long, 34 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 5 Jan 2016 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20160105.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 13 MB long, 28 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 2 Feb 2016 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20160202.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 13 MB long, 27 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 8 Mar 2016 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20160308.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 12 MB long, 26 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 5 Apr 2016 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20160405.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 20 MB long, 42 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 14 Jun 2016 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20160614.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 22 MB long, 48 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 19 Jul 2016 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20160719.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 17 MB long, 37 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 9 Aug 2016 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20160809.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

     Till

P. S.: The MP3 is 20 MB long, 43 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 4 Oct 2016 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20161004.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

      Till

P. S.: The MP3 is 15 MB long, 33 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 8 Nov 2016 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20161108.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

      Till

P. S.: The MP3 is 22 MB long, 47 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 6 Dec 2016 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20161206.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

      Till

P. S.: The MP3 is 24 MB long, 51 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 10 Jan 2017 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20170110.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

      Till

P. S.: The MP3 is 22 MB long, 46 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 14 Mar 2017 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20170314.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

      Till

P. S.: The MP3 is 27 MB long, 59 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 11 Apr 2017 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20170411.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

      Till

P. S.: The MP3 is 19 MB long, 40 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 6 Jun 2017 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20170606.mp3
http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20170606a.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

      Till

P. S.: The MP3s are 16 MB long, 35 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 11 Jul 2017 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20170711.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 16 MB long, 33 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 1 Aug 2017 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20170801.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 20 MB long, 44 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 10 Oct 2017 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20171010.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 28 MB long, 59 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 5 Dec 2017 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20171205.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 30 MB long, 1 hour and 4 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 13 Feb 2018 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20180213.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 26 MB long, 56 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 13 Mar 2018 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20180313.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 38 MB long, 1 hour and 22 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 13 Feb 2018 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20180213.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 26 MB long, 56 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 3 Apr 2018 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20180403.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 22 MB long, 48 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 12 Jun 2018 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20180612.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 13 MB long, 27 minutes of talking.

[Printing-architecture] Last OP Meeting - Tue - 17 Jul 2018 - The Recording

[Till Kamppeter]

Hi,

I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:

http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20180717.mp3

In general, recorded meetings I will upload to

http://www.openprinting.org/download/meetingnotes/

    Till

P. S.: The MP3 is 23 MB long, 50 minutes of talking.