Re: New function css-color (accompanying x11-color) (issue 570690043 by g...@ursliska.de)
Reviewers: thomasmorley651, Message: Please do *not* review this patch anymore, it has (for some reason that is surely my fault) been replaced with https://codereview.appspot.com/580780043/ so please review *that*... Description: New function css-color (accompanying x11-color) I was asked if LilyPond could support choosing colors by their CSS name, which I found a reasonable wish. This commit makes make-x11-color-handler generic and specifies a new function css-color. From this it would be easy to also add further namespaces and color lists. CSS colors are case insensitive, so this commit also provides support for this. Incidentally, a warning is now issued when the requested color is not defined (instead of *silently* falling back to black). Only warn about missing color when necessary Merge pull request #6 from rettinghaus/dev/urs/css-fonts add named colors from CSS Color Module Level 4 Rename x11-color.scm to color.scm With the previous commit adding `css-color` the file `x11-color.scm` should be rename to the generic `color.scm`. add named colors from CSS Color Module Level 4 Define function css-color (accompany x11-color) It should be possible to specify colors using the CSS names in addition to the X11 names. This commit makes `make-x11-color-handler` generic and adds a function `css-color`. What remains to be done is (of course documenting and) filling in the remaining ~140 colors. Please review this at https://codereview.appspot.com/570690043/ Affected files (+165, -718 lines): A + scm/color.scm M scm/lily.scm D scm/x11-color.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New function css-color (accompanying x11-color) (issue 570690043 by g...@ursliska.de)
Am 04.06.19 um 10:53 schrieb Urs Liska: Am 04.06.19 um 00:13 schrieb thomasmorle...@gmail.com: https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm File scm/color.scm (right): https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm#newcode678 scm/color.scm:678: (define css-color-list Is there anything new in this list or are all entries always alias? I checked and saw that the following CSS colors are *not* in the X11 list: CSS Color names not defined in X11 colors: ... *Most* of the others are basically defined identical, with the differences being rounding errors. However, there are a number of real differences, AFAICS it's the discrepancies described in https://en.wikipedia.org/wiki/X11_color_names#Clashes_between_web_and_X11_colors_in_the_CSS_color_scheme The proper list of differenlty defined colors is: CSS Color names not defined in X11 colors: aqua crimson fuchsia indigo lime olive rebeccapurple silver teal CSS Color defined differently than X11: gray green grey maroon purple ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New function css-color (accompanying x11-color) (issue 570690043 by g...@ursliska.de)
Am 04.06.19 um 00:13 schrieb thomasmorle...@gmail.com: https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm File scm/color.scm (right): https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm#newcode678 scm/color.scm:678: (define css-color-list Is there anything new in this list or are all entries always alias? I checked and saw that the following CSS colors are *not* in the X11 list: CSS Color names not defined in X11 colors: aqua crimson fuchsia indigo lime olive rebeccapurple silver teal *Most* of the others are basically defined identical, with the differences being rounding errors. However, there are a number of real differences, AFAICS it's the discrepancies described in https://en.wikipedia.org/wiki/X11_color_names#Clashes_between_web_and_X11_colors_in_the_CSS_color_scheme ... Ofcourse this leads to identical definitions for css-color and x11-color and x11-color would return a color even for p.e. Darkblue (wrongly cased). I can't imagine a problem, though I'm not totally sure about the best way to proceed here. I agree that it's not a terrific idea to duplicate all those color definitions. However, especially given the number of differences there should be explicit access methods for both color models. What might be a reasonable approach is: * Have one long list of shared color definitions, basically the existing one plus entries for the list above (I assume we can ignore the rounding errors issue) * For each color model have a list of *names* and a list (doesn't have to be a *separate* list) of definitions for colors that don't match the shared-colors list. For X11 this would *only* be the names list. (The determination of colors that need special definitions should be done once during development, not at runtime.) * When asking for a color it is first checked if it is in the color model's extension list, then in the shared list (and then fall back to black) * Given that the X11 colors Wikipedia entry states that the capitalization of X11 color names isn't handled consistently I suggest that we totally ignore casing (keep the CamelCase names in the manual but state that colors can be requested case insensitively) What do you think? Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
New function css-color (accompanying x11-color) (issue 570690043 by g...@ursliska.de)
https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm File scm/color.scm (right): https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm#newcode678 scm/color.scm:678: (define css-color-list Is there anything new in this list or are all entries always alias? If the latter, why spelling it out? Instead one could do: (map (lambda (elt) (cons (string->symbol (string-downcase (symbol->string (car elt (cdr elt))) x11-color-list) Or even join them with (append x11-color-list) Probably sorting it and deleting duplicates. Would save one argument in make-color-handler below. The other argument could be thrown out, if you first try to get a color with the user-input, then with a downcased user-input and if all that is not successful fallback to black with warning. Ofcourse this leads to identical definitions for css-color and x11-color and x11-color would return a color even for p.e. Darkblue (wrongly cased). I can't imagine a problem, though https://codereview.appspot.com/570690043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
