下来要做的事情就很明显了：拆分 GNOME Color Manager 的框架部分，使它变成一个简单的系统级别的部件，这样能被系统上下文中的其他部分所用；再将 g-c-m 精简为一个用来配置和应用 colord 策略的会话前端。这样也会简化在 KDE 或者 LXDE 环境下与 colord 交互前端的开发工作。
如果觉得这个听着耳熟，没错，这的确很像 PackageKit 和 UPower。不要惊讶，因为我也在维护这些上游项目。 在 GNOME 3.2 中， GNOME Color Manager 将第一次全面使用 colord 以及彻底修改后的打印堆栈。这对最终用户到底意味着什么？ 嗯，这意味着我们不仅完成所有的基础设计和构建，并且还实现了默认安装，这点非常重要。Colord 是 GNOME 3.2 的一个强制依赖，它是被包含在发行版的 LiveCD 里的。这是说它“Just Works”，不用再安装任何软件包，也无需做任何配置。显示设备会通过 gnome-settings-daemon 在 colord 中进行自动注册，打印设备则会通过 CUPS 注册到 colord 中去。 史上首次，用户可以简单的告诉系统 “在这个设备用这个特性文件”，工作就会魔术般自动完成。这意味着我们在针对一个打印机生成特性文件（或者下载供应商提供的特性文件）之后，就可以保证打印出来的东西没有色彩问题。为了达成这个目的，我们要修改很多底层的东西（CUPS，Ghostscript，foomatic 和 Gtk+），但这对用户而言这就是 "Just Works”。他们再也不用学习如何编写 XML 文件或者挑选策略文件。 在做 colord 的时候，您对第三方的工具打了很多补丁，所以我猜您对全局会有个了解。您对当前 Linux 上的数码图像和打印堆栈有什么看法？它们还跟得上时代吗？用在专业的环境里可靠吗？需要做些大的更改吗？ CUPS 和 Ghostscript 是两个存在了很长时间的项目，它们有稳定的 API。稳定意味着它们已经用了很长一段时间了，当然对我而言，若是有新的 GLib 和 DBus 绑定会让我的工作轻松许多。Linux 上的打印堆栈是非常错综复杂的，希望将来在流程中剔除 PS 而迁移到 PDF 之后事情会变得简单一些。对专业使用者来说，最重要的事情是稳定，有文档。 在处理和设备关系时与 SANE 项目打交道是个令人比较沮丧的过程。SANE 是个古老的程序库，您可以请求它做类似列出已连接的扫描仪，扫描图像之类的工作。主库 libsane 调用按设备制造商划分的 “后端”。后端的质量非常的参差不齐。有些后端，比如惠普的，没什么问题，但有一些却不时的崩溃。就算可以安装私有的后端也没什么改善，而且这些私有后端的质量甚至更令人担忧。因为 colord 的过程中需要使用到 libsane ，上面这些情况会造成守护程序的崩溃。我估计通过 Fedora 提交到 colord 的 bug 中，90% 将是 sane 后端引起的。这也是为何我们在 colord.conf 配置文件设了 EnableSane=false 选项的原因。长远考虑，我希望把大多数的设备探测的工作都移入 udev 中去，就像其他子系统做的那样，但是如果没有得到来自 SANE 社区的支持，这很难实现。
在设计 colord 时，我试着故意忽略了 flipping pixel values。Colord 是个非常高阶的守护进程，它可以对类似 Krita 或 GIMP 程序说 “这个设备用这个特性文件”，而不是为它们提供140MB 的内存缓冲和操作列表。这意味着对某些程序，我们可以在 CPU 上用 lcms2 做转换，而对其他使用了 3D 的就在 GPU 上用 Shader 做转换。选择不封装 lcms ，使得我们留给应用程序去决定在某个恰当的层用恰当的方法做像素转换。 这样的缺点是不得不给应用程序打补丁让它们做出正确的决定。我们可以很容易的对 Clutter 和 Cairo 做一些框架上的修改实现这个目的。但是迟早应用程序都必须要在某种程度上涉及色彩管理。上面这些是我准备在 GNOME 3.4 期间关注的主要方面；现在所有的框架都安装并运行着，我们可以对应用程序作者说 “已经默认安装好了，不用担心额外的依赖，接受我的补丁就可以了”。 说到打印，在打印全彩的图像时，得到正确输出的唯一途径是要针对打印机，油墨和纸张三者的特定组合创建特性文件。即使是在一个固定的流程中也会有多个 ICC 特性文件存在的情形。目前能支持吗？ 我想多数人的打印机都是只有一个特性文件的，但是我同意支持一个设备对应多个特性文件合乎逻辑的。实际上照相机也有同样的问题，您可能既要 “工作室里照明下的特性文件”， 有要 “户外阳光下的特性文件” Colord 事实上和 OSX 的 ColorSync 一样，当应用程序（本例中是 CUPS）为设备请求色彩描述文件时，它其实是依据限定条件来请求描述文件的。通常，按下“文件->打印”之后 CUPS 以 600dpi 的分辨率，用彩墨打印到一个普通纸上。CUPS 是对 colord 请求的是一个“RGB.Plain.600dpi”限定语的特性文件。如果要打印在光面纸上（光面纸有个范围更广的色域，可以打印更多的色彩）时，您的确需要一个不同的特性文件。这需要您使用光面纸重新校准打印机，得到一个不同的特性文件。于是当在打印对话框中选择“光面纸”选项进行光面纸打印时，CUPS 就会请求 “RGB.Glossy.600dpi”，colord 返回一个正确的特性文件。当然如果您没有光面的特性文件，那么它回退普通纸张的特性文件，因为这样比完全没有特性文件要好。 对那些不是通过 GCM 产生的特性文件，目前我们还没法标识“这是个彩墨，光面纸，1200dpi的特性文件”。当然，在用GCM内置校准工具产生的特性文件时是包含，该元数据的。如果您对 UI 上有任何主意和想法，请到 #gnome-design 和那些设计师们讨论，我会把它加到 GNOME 3.4 的。 现在有多少应用程序已知使用了 colord 的 D-Bus 接口，目前它稳定性么？ 我不确定有多少项目使用了colord，因为即使使用了他们也不是一定要通知的嘛。目前，据我所知的有 CUPS，GTK+，foomatic，simple-scan，compiz-cms，当然少不了 gnome-color-manager。Alex Fiestas 也有计划实现一个 KDE 前端。 colord 的公共 Dbus API 非常的稳定。我们只有去年发生过影响 API 的兼容性，并且那次的变动也只是影响了会话策略代理，对应用程序并没有影响。我们目标是保持 API 的稳定和和对它的支持，当我们觉得需要更多的功能时，再添加更多的属性和方法进去。我并不是说即使是要修复重大的bug，我们都不会打破 API。就目前而言，我看没有看到这样做的必要；colord 只是影响范围有限的简单后台守护程序。 |
