PDFassociation conference in Basel/Switzerland

PDF Association - The future of PDF

The PDF Technical Conference was organised by the independent PDFassociation and held this week March 27-28, 2012 in Basel, Switzerland in the rooms of Adobe. PDF experts from around the world meet there to talk about hot new stuff and to discuss technical details in a friendly atmosphere. In the following text I will highlight some of the talks.

Andreas Kraushaar from Fogra gave a talk about spectral imaging and why it is a good thing to support that inside PDF spot colours for packaging. Most of the time the number and kind of inks used for packaging is rapidly changing. So colour profiling the ICC way means a waste of too many time and material as it is not flexible enough for that. Embedded spectral data based recipes for rendering spot colours in supporting applications can improve speed and handling considerably.

Two talks elaborated on transparency in PDF. I found it amusing that the concept of a blending colour space is as well in the PDF community still a hot topic. But of course rendering to offscreen bitmaps instead of traditionally one final output buffer is quite different and developers agreed to find implementation sometimes not easy. And yes, there are many PDF viewers around, which blend Cmyk and RgbA together in one go ignoring any blending space requirement.

Florian Süßl from zipcon presented the well known ECI Altona Test Suite 2 now covering PDF/X-4 including transparencies. He elaborated on the work involved on how to create all the tests following the PDF-1.7 spec. He gave some examples where the various PDF renderers failed certain test. This is again a very valuable tool for developers of PDF software. It would be cool if such a test suite becomes part of the specification itself as is usual with other standards to help verifying implementations.

Following the topic of quality testing, David van Driessche explained the GWG test suite. I would find it really cool to embed GWG tests into a dedicated PDF document page for checking reproduction capabilities by layout applications like Scribus. That feature would be helpful for critical viewing and to easily test proofing software.

Bill McCoy from idpf presented a comparison of PDF and the HTML5/ePUB publication format. The later one is based on W3C standards like SVG and TTS with few modifications and has together with these a great potential depending on the involved people and organisations to further develop these technologies. ePUB was created to provide a independent platform for electronic publishers. And as the ePUB format comes out of open source technologies, it can as well be supported in the open source world by e.g. Mozilla and
Calibre logo.png.

The conference was beside sometimes very full rooms a well organised and interesting event.

KDE End to End Colour Management

The last blog posts about KDE and colour management might have been irritating about what actual happens on colour managed desktops. Here come some clarifications and thoughts from the Oyranos CMS maintainer. The project name starts with Oy (Oyranos like sky), hence my nick oy on IRC ;-)

Colour Management Systems (CMS) are a precondition to do colour correction of input and output devices. But this is not sufficient for having a colour corrected desktop. The claim was made, that Gnome is the first colour managed desktop on Linux. But Gnomes window manger mutter has no means to use ICC profiles. The same is true for all other window managers with an exception of old Compiz. A CMS selects only the needed ICC profile and does the configuration in that field. But the background, applications like the dock and most others are not colour corrected by standard ICC profiles mechanisms in Linux. The only thing users can do since many years on Linux is to do monitor calibration setup per single channel. This helps for better grayscale, but not for compensating of colour gamuts. Calibration is only a first step, but not sufficient for ICC colour correction. So Gnome users have today no colour corrected desktop like all other Linux users.

What is needed to get to a End to End colour corrected desktop in KDE? A more general Overview can be found here.

  1. KWin needs ICC support, in order to colour correct the KDE desktop in a reasonable time frame. That will help with the output side in a fast way by using the GPU during compositing while using few resources. If you feel it is time to do something, here is a  Google Summer of Code CM project idea for KWin. With my experience from the CompICC project, I would be glad to help any such project.
  2. An other project I would find really helpful is to provide colour correction to KDE’s primary image viewer gwenview. If people could help with a hackfest, that would be cool. We have such thing in mind and some ideas about, maybe you like to join us.
  3. Qt/KDE needs to explore how to do own fast colour correction of a complete window to be prepared for the future. Here are two project ideas.
  4. OpenICC did investigate to get print colour management right. There are currently two approaches who are promising. OpenICC has one project idea to introduce colour managed printing into Krita and one for user profile setup for colour managed print queues with KolorManager. These are two complementing, maintainable and robust paths for getting printing CM right.

Now some clarifications about Oyranos itself, as in the kde-planet where many wrong statements transported intermixed with half true claims.

  • Core is a toolkit independent library
  • KDE, Qt and FLTK front ends exist like KolorManager. Other native ones are possible.
  • The Elektra API and library is used for format independent configuration DB access.
  • Oyranos is planed to switch to a OpenICC JSON DB format to converge with ArgyllCMS and other interested CMS’es
  • Oyranos is a cross platform project
  • A DBus API would be welcome on top of the basic library but not in its core
  • Oyranos forces no one to use the CPU or prohibit to use the GPU :-D
  • The CMS provides means to do optional multi monitor colour correction and other conversions.
  • CompICC uses Oyranos and does colour correction on the GPU
  • Oyranos developers belief in collaboration :-)
  • Self containment in Oyranos results from adhering to and work on interoperable standards.
  • User configurations belong to users in Oyranos, so it needs no special root rights, which exposes security and privacy risks.
  • Oyranos provides optional policies for grouping single settings. That is a additional feature not a limitation.
  • Oyranos uses many advanced automatism’s to do it’s work successful
  • The CMS is designed to work with default settings.
  • Advanced manual configurations are supported and part of Oyranos’ user centrism.
  • Oyranos cares about quality and requires a careful selected and peer reviewed profile set that comes with no Fakes and no wrong colorimetry.
  • Licensing fits most open source and commercial projects with a newBSD style license.

Choice is a good thing for users. As a CMS author I have no problems, that an other CMS comes to KDE too on Linux. Many Linux CM standards I initiated or helped with allow for such interoperability, which is in the spirit of the ICC standard.

Oyranos @ rwx³

rwx³ alias openSUSE Conference (oSC) will be from 11.09. – 14.09.2011 in Nuremberg / Germany. Im going the to openSUSE Conference! The conference for openSUSE - and Free Software enthusiasts, September in Nuremberg, Germany. Are you? We will meet there and can discuss ICC colour management for the openSUSE distribution, KDE and Qt.

Sebastian Oliva will be there too. I hope we can hack together a Oyranos connection to his newly created ICC DB. The ICC DB project, done during GSoC 2011, shall be used to search for ICC profiles by terms of colour device configurations. This means a printer can obtain a fitting ICC profile for a special driver without the need to have all the canned profiles packaged. Independent vendors can easily upload their ICC data and get their optimised profile selected automatically – if all works. Sebastian and Joseph Simon have done fair bits to get there in a clean way, without hacking the whole system.

I will have colour measurement equipment with me and we can create new profiles for actual used gear, like laptop monitors. Of course these shall walk into the ICC DB.

It would be cool to meet with Compiz and KWin maintainers/packagers to get the GPU colour managed desktop project further. The net-color-spec appears pretty robust. But we need a critical mass to support the concept of colour correcting all windows on the desktop in compositing window managers.

Will be great to meet you all.

Cross Platform Toolkits and CM

Some readers might wonder, why ICC Examin has not yet a new osX package. There are several issues with FLTK. The most annoying is FLTK has no real colour management policy. But stop. Which cross platform toolkit has? Right – none. Qt has non, Gtk – don’t know? The situation dates from times where RGB was just native display values. But that is changing completely. osX has with SL colour server functionality on top of Quartz integrated. On Linux early prototypes date back to 2008 and start to be integrated as CompIcc project.

Application developers be warned. FLTK and Qt defaults to “Generic RGB” on osX SL. This means no sRGB primaries, alias a different Gamut, and a Gamma of 1.8.

Do not assume sRGB on all platforms. And worse, a application can not assume anything about the colour space of the toolkit. Trolltech and FLTK, and Gnomes Gtk too, can change the underlaying colour space at good will. So colour managed applications using these cross platform toolkits are merciless exposed to this situation.