Made some final overhauls for 1.0

Cargo.toml

@@ -1,7 +1,7 @@
 [package]
 name = "scarlet"
 description = "Colors and color spaces made simple"
-version = "0.2.2"
+version = "1.0.0"
 authors = ["Nicholas Miklaucic <nicholas.miklaucic@gmail.com>"]
 license = "Apache-2.0"
 readme = "README.MD"
@@ -11,17 +11,17 @@ categories = ["multimedia::images", "visualization", "data-structures"]
 
 
 [dependencies]
-regex = "0.2"
-termion = "1"
-num = "0.1.41"
+regex = "1.0"
+termion = "1.5"
+num = "0.2"
 float-cmp = "0.4.0"
-csv = "1.0.0-beta.5"
+csv = "1.0.2"
 serde = "1"
 serde_derive = "1"
-geo = "0.7.1"
+geo = "0.10"
 rulinalg="0.4.2"
 maplit = "1.0.1"
-lazy_static = "1.0"
+lazy_static = "1.1"
 
 [package.metadata.docs.rs]
 rustdoc-args = ["--html-after-content", ".cargo/registry/src/github.com-1ecc6299db9ec823/scarlet-0.2.2/colorize.html"]

README.MD

@@ -5,10 +5,6 @@
 Status](https://travis-ci.org/nicholas-miklaucic/scarlet.svg?branch=master)](https://travis-ci.org/nicholas-miklaucic/scarlet)
 [![dependency status](https://deps.rs/repo/github/nicholas-miklaucic/scarlet/status.svg)](https://deps.rs/repo/github/nicholas-miklaucic/scarlet)
 
-
-**Note: This is in beta stage. Breaking changes can and will be made without warning on new
-versions, up until 1.0, expected before June 2018. This is not mature software.**
-
 Humans and computers don't view color the same way, and so color descriptions like RGB don't
 effectively describe colors in the way that humans perceive them and vice versa. Image processing
 and other disciplines require the ability to interconvert and work with colors in a way that
@@ -30,7 +26,7 @@ Add this to your `Cargo.toml`:
 
 ```toml
 [dependencies]
-scarlet = "0.2"
+scarlet = "1.0.0"
 ```
 
 and this to your crate root:

src/bound.rs

@@ -1,6 +1,6 @@
-//! This module describes the [`Bound`] trait, which allows for a description of what colors a color
-//! gamut supports. For example, the sRGB gamut only supports RGB values ranging from 0-1 that are
-//! scaled to 0-255, which is about 30% of the total visible range of human vision.
+//! This module describes the [`Bound`](bound::Bound) trait, which allows for a description of what
+//! colors a color gamut supports. For example, the sRGB gamut only supports RGB values ranging from
+//! 0-1 that are scaled to 0-255, which is about 30% of the total visible range of human vision.
 
 
 use color::{Color, RGBColor};

src/color.rs

@@ -1,26 +1,27 @@
-//! This file defines the [`Color`] trait, the foundational defining trait of the entire
-//! library. Despite the dizzying amount of things [`Color`] can do in Scarlet, especially with its
+//! This file defines the [`Color`](color::Color) trait, the foundational defining trait of the entire
+//! library. Despite the dizzying amount of things [`Color`](color::Color) can do in Scarlet, especially with its
 //! extending traits, the definition is quite simple: anything that can be converted to and from the
 //! [CIE 1931 XYZ space](https://en.wikipedia.org/wiki/CIE_1931_color_space). This color space is
 //! common to use as a master space, and Scarlet is no different. What makes XYZ unique is that it
 //! can be computed directly from the spectral data of a color. Although Scarlet does not implement
 //! this due to its scope, this property makes it possible to derive XYZ colors from real-world data,
 //! something that no other color space can do the same way.
 //!
-//! The thing that makes [`XYZColor`], the base implementation of the CIE 1931 XYZ space, special is
-//! that it is the only color object in Scarlet that keeps track of its own illuminant data. Every
-//! other color space assumes a viewing environment, but because XYZ color maps directly to neural
-//! perception it keeps track of what environment the color is being viewed in. This allows Scarlet
-//! to translate between color spaces that have different assumptions seamlessly. (If you notice
-//! that Scarlet's values for conversions differ from other sources, this may be why: some sources
-//! don't do this properly or implement it differently. Scarlet generally follows best practices and
-//! industry standards, but file an issue if you feel this is not true.)  The essential workflow of
-//! [`Color`], and therefore Scarlet, is generally like this: convert between different color spaces
-//! using the generic [`convert<T: Color>()`](trait.Color.html#method.convert) method, which allows
-//! any [`Color`] to be interconverted to any other representation. Leverage the specific attributes
-//! of each color space if need be (for example, using the hue or luminance attributes), and then
-//! convert back to a suitable display space. The many other methods of [`Color`] make some of the
-//! more common such patterns simple to do.
+//! The thing that makes [`XYZColor`](color::XYZColor), the base implementation of the CIE 1931 XYZ
+//! space, special is that it is the only color object in Scarlet that keeps track of its own
+//! illuminant data. Every other color space assumes a viewing environment, but because XYZ color
+//! maps directly to neural perception it keeps track of what environment the color is being viewed
+//! in. This allows Scarlet to translate between color spaces that have different assumptions
+//! seamlessly. (If you notice that Scarlet's values for conversions differ from other sources, this
+//! may be why: some sources don't do this properly or implement it differently. Scarlet generally
+//! follows best practices and industry standards, but file an issue if you feel this is not true.)
+//! The essential workflow of [`Color`](color::Color), and therefore Scarlet, is generally like this:
+//! convert between different color spaces using the generic [`convert<T:
+//! Color>()`](trait.Color.html#method.convert) method, which allows any [`Color`](color::Color) to
+//! be interconverted to any other representation. Leverage the specific attributes of each color
+//! space if need be (for example, using the hue or luminance attributes), and then convert back to
+//! a suitable display space. The many other methods of [`Color`](color::Color) make some of the more
+//! common such patterns simple to do.
 //!
 
 use std::collections::HashMap;

src/colormap.rs

@@ -1,4 +1,4 @@
-//! This module defines a generalized trait, [`ColorMap`], for a colormap—a mapping of the numbers between 0 and 1
+//! This module defines a generalized trait, [`ColorMap`](colormap::ColorMap), for a colormap—a mapping of the numbers between 0 and 1
 //! to colors in a continuous way—and provides some common ones used in programs like MATLAB and in
 //! data visualization everywhere.
 

src/colorpoint.rs

@@ -44,7 +44,7 @@ pub trait ColorPoint: Color + Into<Coord> + From<Coord> + Clone + Copy {
         Self::from(c1.weighted_midpoint(&c2, weight))
     }
 
-    /// Like [`weighted_midpoint`], but with `weight = 0.5`: essentially, the
+    /// Like `weighted_midpoint`, but with `weight = 0.5`: essentially, the
     /// [`Color`](../color/trait.Color.html) representing the midpoint of the two inputs in 3D space.
     fn midpoint(self, other: Self) -> Self {
         let c1: Coord = self.into();

src/colors/cielabcolor.rs

@@ -179,12 +179,12 @@ mod tests {
     #[test]
     fn test_out_of_gamut() {
         // this color doesn't exist in sRGB! (that's probably a good thing, this can't really be represented)
-        let color1 = CIELABColor {
+        let _color1 = CIELABColor {
             l: 0.0,
             a: 100.0,
             b: 100.0,
         };
-        let color2: RGBColor = color1.convert();
-        let color3: CIELABColor = color2.convert();        
+        let _color2: RGBColor = _color1.convert();
+        let _color3: CIELABColor = _color2.convert();
     }
 }

src/colors/rommrgbcolor.rs

@@ -1,4 +1,4 @@
-//! This module implements the Romm, or ProPhoto, RGB space. Unlike other RGB gamuts, ProPhnoto trades
+//! This module implements the Romm, or ProPhoto, RGB space. Unlike other RGB gamuts, ProPhoto trades
 //! having some imaginary colors in its gamut (13% of it can't be seen) in exchange for a much wider
 //! gamut than other RGB spaces (90% of CIELAB surface colors).
 //!

src/coord.rs

@@ -1,4 +1,4 @@
-//! This module contains a struct, [`Coord`], that models a 3D coordinate space and supports limited
+//! This module contains a struct, [`Coord`](coord::Coord), that models a 3D coordinate space and supports limited
 //! math in 3 dimensions with scalars and other coordinates. Used to unify math with colors that is
 //! the same, just with different projections into 3D space.
 
@@ -17,11 +17,9 @@ impl<T: NumCast + Num> Scalar for T {}
 /// `Coord` has three axes, denoted `x`, `y`, and `z`. These are not any different in any method of
 /// `Coord`, so the distinction between them is completely conventional. In Scarlet, any [`Color`]
 /// that converts to and from a `Coord` will match its components with these axes in the order of the
-/// letters in its name: for example, [`CIELABColor`] maps to a coordinate such that `l` is on the
+/// letters in its name: for example, `CIELABColor` maps to a coordinate such that `l` is on the
 /// x-axis, `a` is on the y-axis, and `b` is on the z-axis.
 ///
-/// [`Color`]: ../color/trait.Color.html
-/// [`CIELABColor`]: ../colors/cielabcolor/struct.CIELABColor.html
 /// # Examples
 /// ## Basic Operations
 /// ```

src/lib.rs

@@ -6,7 +6,7 @@
 //! working with color convenient enough that it's *easier* to treat colors correctly than it is to do
 //! anything else.
 
-#![doc(html_root_url = "https://docs.rs/scarlet/0.2.2")]
+#![doc(html_root_url = "https://docs.rs/scarlet/1.0.0")]
 
 // we don't mess around with documentation
 #![deny(missing_docs)]

src/material_colors.rs

@@ -1,5 +1,11 @@
 //! This file provides some basic facilities for creating a [`Color`](color/trait.Color.html) object,
-//! specifically an [`RGBColor`](color/struct.RGBColor.html), from the Google Material design spec.
+//! specifically an [`RGBColor`](color/struct.RGBColor.html), from the Google Material design
+//! spec.
+//!
+//! One thing to keep in mind is that the Material Design specification has changed somewhat. Now,
+//! they use "algorithmic adjustment of hue, chroma, lightness" instead of these palette colors. I'm
+//! keeping these here because they're still useful: you can certainly replicate any adjustments
+//! Google does with the other capabilities of Scarlet.
 
 use color::RGBColor;