[Openicc] The system administrator's PoV

Craig Ringer craig at postnewspapers.com.au
Fri Apr 22 16:11:57 EST 2005


Hi all

I've been reading this list for a little while now at Peter Linnell's
suggestion, but this is my first post here so here's a brief intro. I'm
the system administrator of a small-ish weekly newspaper in Perth,
Western Australia. Most of my limited experience with colour work so far
has been with MacOS 9 and largely per-application configuration, in a
workflow that outputs untagged pre-corrected CMYK PDF.

I'm very interested in seeing something better on *NIX, and follow the
discussion here with some interest.

It might be worth outlining what a system administrator might want from
a colour management setup, as I see it. These are ideas and "wouldn't it
be cool if..." thoughts. Maybe some of these are worth pondering or
leaving room for in any designs that emerge here.

I'd really like to see:
    - Some way to associate the monitor profile info with the X
      server / DISPLAY or have the X server help with colour management.
      When I forward an application from my terminal server to a thin
      client, I'd expect it to use the profile from that display, not
      the server's display.  A simple X extension (for the "send the
      profile" approach) may be useful here. X11 is a network
      transparent graphics protocol, let's not tie colour managed apps
      down to the workstation model or require clumsy configuration.
      With a config library like mentioned below, this could be made
      somewhat platform independent too - grab a ColourSync profile on
      MacOS/X or ask the X server on *NIX, for example.
    - Sysadmin-friendly colour configuration. A central place to set
      system-wide defaults in /etc, then per-user preferences to
      override those unless locked by the admin.  Something like how
      KDE's `Kiosk' mode works would be awesome, or the fontconfig model
      with the addition of admin locks in the global config. This would
      work best with ....
    - A configuration library for apps to use, akin to fontconfig in
      function but for colour settings and profiles.  That'd improve
      the management side and help eliminate the nightmare of hand-
      configuring lots of apps.
    - A mechanism, via the configuration library or via CUPS, to
      get the ICC profile(s) for the target device(s) that does *not*
      involve installing them on every workstation or worse in every
      user account.
    - A way for an application to pass a custom target profile
      and/or colour management settings through to the spooler with 
      a job, so it can provide a tweaked profile when required. Ideally
      this wouldn't require the profile to be present on the spooler
      host, it'd want to be passed through with the print job if
      possible.
    - The option of avoiding library-supplied GUI while retaining
      full configurability. A command-line tool won't want to call
      out to a gtk printing dialog to get full colour management
      features, and neither will a Qt/Aqua application on MacOS/X.

I think there are several parallels to font handling involved here. Like
colour configuration, fonts are things that we want all apps to have
fairly transparent access to, not have to do anything complicated with
to get basic results, but have the flexibility to do more advanced
things with when they need to. Like colour, we want fonts to be easy to
configure globally, per user, or where necessary per application. Like
colour, it's desirable to have fonts handled correctly in distributed /
networked environments.

I think the fontconfig/freetype model of how fonts are handled on *NIX
is a rather good one in this respect. It's portable, not tightly tied to
a given toolkit/API, and reasonably simple for basic things without
making more advanced things impossible.

Maybe a similar model, in the broadest sense, might be worth aiming for
with colour management - at least for the side that applications are
responsible for.

Anyway, I realise this was a bit of a ramble at a fairly generic and
broad level, but I hope I've thrown some useful ideas out there.

-- 
Craig Ringer




More information about the openicc mailing list