[Xmlgraphics Wiki] Update of "ColorHandling" by JeremiasMaerki

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Xmlgraphics Wiki" for change notification.

The "ColorHandling" page has been changed by JeremiasMaerki.
The comment on this change is: Updated based on some new insights over the weekend.
http://wiki.apache.org/xmlgraphics/ColorHandling?action=diff&rev1=6&rev2=7

--------------------------------------------------

  Both SVG and XSL-FO allow specification of color in various color spaces (defined by ICC color profiles, with 1, 3, 4 or n components). In both cases, sRGB is the default color space. sRGB also serves as fallback in both cases. With SVG 1.2 and XSL 2.0, additional color specifications will be introduced. Among these are:
  
   * device-specific (uncalibrated) colors, mainly for specifying CMYK colors, but also for gray, RGB values and N-Component colorspaces (like HP's IndiChrome 6-color printing).
-  * CIE LAB and CIE LCHab colors
+  * CIE Lab and CIE LCHab colors
   * ICC Named Color (for spot colors)
  
- Not all possible output formats for SVG and XSL-FO documents support all of the above color specifications. In all cases, fallback colors in sRGB color space are specified to achieve at least an approximation of the intended color. What's intended here is to find a way to represent these colors as primary color specifications for output formats that support them. In all other case, the sRGB fallback shall be used.
+ Not all possible output formats for SVG and XSL-FO documents support all of the above color specifications. In all cases, fallback colors in sRGB color space are specified to achieve at least an approximation of the intended color. What's intended here is to find a way to represent these colors as primary color specifications for output formats that support them. In all other case, the sRGB fallback shall be used. There are a few more details in the SVG Color spec:
+ 
+  * For calibrated colors (ICC color, ICC named color or CIE Lab/LCHab ), the spec says that the user agent shall use these and convert to other color spaces (for interpolation or compositing, for example) using the specific color values rather than the sRGB fallback.
+ 
+  * For device-specific colors, the color values are to be passed through to the output device but interpolation and compositing shall occur using the sRGB fallback.
+ 
+ Although not clearly specified, yet, it can be assumed that XSL-FO 2.0 will handle this in a similar way. XSL 1.1, at any rate, clearly says that the sRGB fallback is only used for ICC colors, if the associated color profile is unavailable.
+ 
+ So, we're presented with essentially two different way of color handling: Use the calibrated color if supported and the calibration info (color profile) is available. Device-specific colors are only used in the output format if it is supported and not involved in any color calculations. The sRGB fallback has a more important role in the latter case.
  
  === FOP-specific requirements ===
  
@@ -36, +44 @@

  
  The member variable {{{colorValues}}} of {{{ColorExt}}} saves the same values as {{{fvalue}}} in the super class, so this seems to be superfluous.
  
- Batik currently only supports sRGB colors and ICC colors with a backing (and loaded) ICC profile. No access is possible to the original ICC profile file since plain Java classes are used. However, Batik has a class ICCColorSpaceExt which can hold a rendering intent and provides sRGB values by selected rendering intent. That could be useful to FOP, too, so the functionality is also a candidate to be ported to XGC.
+ Batik currently only supports sRGB colors and ICC colors with a backing (and loaded) ICC profile. No access is possible to the original ICC profile file (only the loaded data is available) since plain Java classes are used. However, Batik has a class ICCColorSpaceExt which can hold a rendering intent override (an ICC color profile has a rendering intent value, too) and calculates sRGB values by selected rendering intent. That could be useful to FOP, too, so the functionality is also a candidate to be ported to XGC. One current problem in Batik is that ICC colors are converted to sRGB on the input side, rather than the output side (information is lost even when a conversion to sRGB is not necessary or not desired). This will have to be changed so the specific color is preserved as long as possible. Fortunately, the {{{Color}}} class can always return the corresponding sRGB value when needed.
+ 
+ == Current state (2010-07-02) ==
+ 
+ With the XGC 1.4 release, the ColorExt class has been moved back to FOP pending the color redesign discussed on this page.
  
  == Ideas ==
  
@@ -46, +58 @@

  
  So, another possibility is to attach additional color specifications to the main Color(Ext) instance and the super class' constructor simply receives the fallback sRGB color. The additional color specifications would be held as an ordered list which also represents the prioritized order of the color with the sRGB always being the last in the chain. So the primary color would always be a plain sRGB color value but could optionally contain one or more additional colors which implementations can choose over the fallback. That would avoid the work-around with the various local variables in {{{ColorExt}}}.
  
+ For calibrated colors, the specific color could be used as the primary color (since the sRGB color is only to be used if a color profile is unavailable). Additional color specifications could be attached to the ordered list of alternative colors mentioned above.
+ 
+ For device-specific colors, the sRGB fallback is the primary color. The alternative is only used if the output format supports it and no color calculations were necessary.
+ 
- {{{ColorExt}}} could be relieved of the replacement and original color values and the additional color profile variables. Instead we'd create additional subclasses for ICC-based colors which simply carries the name and URI for the color profile in addition to the stuff inherited from {{{java.awt.Color}}}. For device-specific fonts, we could also use the same class but work with specially marked {{{ColorSpace}}} instances (a slightly enhanced {{{CMYKColorSpace}}}, for example) instead of normal ICC profiles.
+ {{{ColorExt}}} could be relieved of the replacement and original color values and the additional color profile variables. Instead we'd create additional subclasses for ICC-based colors which simply carries the name and URI for the color profile in addition to the stuff inherited from {{{java.awt.Color}}}. For device-specific colors, we could also use the same class but work with specially marked {{{ColorSpace}}} instances (a slightly enhanced {{{CMYKColorSpace}}}, for example) instead of normal ICC profiles.
  
  For each named color, we'd have to provide a new {{{ColorSpace}}} instance with just one component for the tint, so it will probably have to have type {{{ColorSpace.TYPE_GRAY}}} which is the only one with just one component. Maybe the alpha value could actually be used instead but that's not sure. The tricky thing here is probably to calculate the right XYZ coordinate for the various tint values given a specific white point if the color shall be used directly by the Java2D subsystem which is not necessary for just embedding the color spec in the output format. Once support for named color profiles is available, those special color spaces could be linked together with a common parent representing the actual named color profile.
  
@@ -54, +70 @@

  
  {{{
  
- public class ColorExt extends Color {
+ public class ColorWithAlternatives extends Color {
  
-     private List<Color> alternateColors;
+     private List<Color> alternativeColors;
  
  [..]
  }

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: commits-help@xmlgraphics.apache.org