Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
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:
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.
CUPS.org User: till.kamppeter
The ICC profiles listed in the PPD file (without absolute path) should reside in a standardized directory like
with $PREFIX being /usr, /usr/local, and /opt (similar to the PPD directories).
CUPS could make them available under
CUPS.org User: hvengel
I think this:
Since the only way to get the 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:
by default. This is very common at this time and will be going forward.
How would CUPS know that
are referring to the same file and that this file is /usr/share/color/icc/sRGB.icc? I think adding 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:
and then using:
in the *cupsICCProfie setting. This would result in a URI of:
While still allowing the use of common/generic profiles that are located in /share/color/icc.