hvengel: 10:37 Aug 05, 2008
This is specific to *nix platforms other than OS/X.
Applications need to be able to query the print server to obtain a list of installed ICC profiles from the sever. This is currently possible for "standard" ICC profiles (IE. those that are in the PPD file for the printer) but it is not possible for "custom" ICC profiles. There needs to be a mechanism for user land apps to query the print server to get a list of available custom ICC profiles.
In addition user land apps need to be able to get copies of these profiles (both standard and custom) for doing things like:
1. Soft proofing.
2. Presenting lists of profiles to users so that they can select a custom profile.
UI note - it is considered bad form for application user interfaces to present these as a list of file names for profiles. All commercial and most open source CM aware applications present these as a list of the descriptions that are extracted from the profiles. Scribus is currently considered the OSS application that has the nicest implementation of this feature but many other OSS applications work this way (LProf, CinePaint, Oryanos, Krita, kolor-manager...). The reason for presenting the description is that it generally contains information about the profile that will help users select the correct profile. So it is necessary for user land applications to have access to the actual profiles to implement this functionality. In addition, these applications will in many cases present other information to users about the profiles to help them select appropriate profiles or use information from the profiles to filter the profile list. For example, depending on the printer settings some applications filter the list of profiles presented to the user (IE. the ColorMode is set to CMYK so the user can only select from a list of CMYK profiles). The application needs to have access to the profiles to be able to do this.
|
till.kamppeter: 05:07 Jul 31, 2009
The ICC profiles listed in the PPD file (without absolute path) should reside in a standardized directory like
$PREFIX/share/color/icc/
with $PREFIX being /usr, /usr/local, and /opt (similar to the PPD directories).
CUPS could make them available under
http://<server>:631/printer/<queue name>/icc/
|
hvengel: 10:33 Aug 08, 2009
I think this:
http://<server>:631/printer/<queue name>/icc/
should be:
http://<server>:631/profiles/<path and file name from PPD file>/
Since the only way to get the <path and file name from PPD file> is to parse that information from the PPD file (either directory using cups API calls or by reading the PPD file or indirectly by using the new CUPS facilities in Oyranos) we can assume that any app or user getting the profile from CUPS will know what queue he/she is requesting a profile for. In addition there may be some basic profiles that are commonly used by many printers and perhaps other devices on many queues and these will presumably be installed in a common location to avoid duplication. For example a default profile for many printers might be sRGB.icc and this profile will almost always exist in:
/usr/share/icc/color
by default. This is very common at this time and will be going forward.
How would CUPS know that
http://<server>:631/printer/Epson_R2400/sRGB.icc/
and
http://<server>:631/printer/Epson_R1800/sRGB.icc/
are referring to the same file and that this file is /usr/share/color/icc/sRGB.icc? I think adding <queue name> to the URI adds a complication that does not have any benefit. In addition the same basic thing can be done by placing printer specific profiles in:
<prefix>/share/color/icc/printer/<queue name>
and then using:
"printer/<queue name>/<profile file name>"
in the *cupsICCProfie setting. This would result in a URI of:
http://<server>:631/profiles/printer/<queue name>/<profile file name>
While still allowing the use of common/generic profiles that are located in <prefix>/share/color/icc.
|