[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