Difference between revisions of "Color Entry Widget"

From Inkscape Wiki
Jump to navigation Jump to search
(Add Summary and Prepare SVG2)
Line 1: Line 1:
The entry accepts colors as defined by the [http://www.w3.org/TR/SVG/color.html SVG 1.1 Specifications]. Those colors are stored in the SVG file as specified by the user (i.e. no more forced conversions to RRGGBBAA). However, for internal purposes, the colors can be stored and handled differently.
+
Here are the aims of this blueprint.
 +
 
 +
== Deal with full SVG 1.1 colors ==
 +
 
 +
The entry accepts colors as defined by the [http://www.w3.org/TR/SVG/color.html SVG 1.1 Specifications].
 +
 
 +
SVG 1.1 colors do not handle alpha (it's stored in a separate attribute). We have three options:
 +
 
 +
# Change nothing and keep displaying the alpha value with the color value by extanding the SVG specification (#RRGGBB => RRGGBBAA, rgb(255, 255, 255) => rgba(255, 255, 255, alpha)...).
 +
# Do like many softwares and display the color in the entry without the alpha (which is displayed in it's own entry). This would probably need a widget rearrangement.
 +
# Allow both: implement the SVG 1.1 specification (case 2) and keep case 1 as a preparation for SVG 2. This will allow inputs but, because Inkscape files are SVG 1.1, any loaded file will be displayed using case 2.
 +
 
 +
The third case is proposed.
 +
 
 +
== Prepare SVG 2 ==
 +
 
 +
Based on [http://www.w3.org/TR/SVG2/color.html SVG2]. The idea is to be more ''SVG 2 ready''.
 +
 
 +
=== sRGB colors ===
 +
 
 +
The HSL format is closed to RGB: no issue.
 +
 
 +
Some color named are added: no issue.
 +
 
 +
=== sRGB colors with alpha ===
 +
 
 +
RGBA and HSLA are added: no issue.
 +
 
 +
=== ICC and LAB colors ===
 +
 
 +
To be implemented?
 +
 
 +
== Keep the user value ==
 +
 
 +
Colors are stored in the SVG file as specified by the user (i.e. no more forced conversions to hex values). However, for internal purposes, the colors can be stored and handled differently. This would mean having an internal color value (as now) and a display value.
  
 
The color sets in the entry is (chronologically):
 
The color sets in the entry is (chronologically):
Line 6: Line 40:
 
# Then, if modified by the user (pasted or typed), the user value
 
# Then, if modified by the user (pasted or typed), the user value
 
# Then, if modified by the software (in case of multiple input widgets), the software value
 
# Then, if modified by the software (in case of multiple input widgets), the software value
 +
 +
If the alpha is not part of the user input, Inkscape keep the previous one and will not append it in the entry.
 +
 +
== Help the user ==
  
 
If the text in the entry cannot be converted to a valid color, the entry changes it's appearance (red border?).
 
If the text in the entry cannot be converted to a valid color, the entry changes it's appearance (red border?).
  
 
If a color from the palette is dragged and dropped on the entry, it takes the color value.
 
If a color from the palette is dragged and dropped on the entry, it takes the color value.
 
The SVG specification split colors and opacity in two different properties. However, the Inkscape Color Entry propose the user to merge them in the same entry. We would extend the SVG specifications to allow Alpha (ie RRGGBB => RRGGBBAA) but, if not set, Inkscape append the previous alpha.
 
  
 
[[Category:Proposals]]
 
[[Category:Proposals]]
 
[[Category:Widgets]]
 
[[Category:Widgets]]

Revision as of 14:21, 26 December 2012

Here are the aims of this blueprint.

Deal with full SVG 1.1 colors

The entry accepts colors as defined by the SVG 1.1 Specifications.

SVG 1.1 colors do not handle alpha (it's stored in a separate attribute). We have three options:

  1. Change nothing and keep displaying the alpha value with the color value by extanding the SVG specification (#RRGGBB => RRGGBBAA, rgb(255, 255, 255) => rgba(255, 255, 255, alpha)...).
  2. Do like many softwares and display the color in the entry without the alpha (which is displayed in it's own entry). This would probably need a widget rearrangement.
  3. Allow both: implement the SVG 1.1 specification (case 2) and keep case 1 as a preparation for SVG 2. This will allow inputs but, because Inkscape files are SVG 1.1, any loaded file will be displayed using case 2.

The third case is proposed.

Prepare SVG 2

Based on SVG2. The idea is to be more SVG 2 ready.

sRGB colors

The HSL format is closed to RGB: no issue.

Some color named are added: no issue.

sRGB colors with alpha

RGBA and HSLA are added: no issue.

ICC and LAB colors

To be implemented?

Keep the user value

Colors are stored in the SVG file as specified by the user (i.e. no more forced conversions to hex values). However, for internal purposes, the colors can be stored and handled differently. This would mean having an internal color value (as now) and a display value.

The color sets in the entry is (chronologically):

  1. First, the color as written in the SVG file (if any)
  2. Then, if modified by the user (pasted or typed), the user value
  3. Then, if modified by the software (in case of multiple input widgets), the software value

If the alpha is not part of the user input, Inkscape keep the previous one and will not append it in the entry.

Help the user

If the text in the entry cannot be converted to a valid color, the entry changes it's appearance (red border?).

If a color from the palette is dragged and dropped on the entry, it takes the color value.