Use colors without defining them beforehand #13
Comments
|
Isn't that already in |
|
Hum, I don't know, but I was not able to make it work: I get an error |
|
Hmm. checking I was wrong: the extended models won't help. The thing here is, I suspect, that for |
|
In particular, for TikZ the docs say
|
|
Sorry but it would complicate the parsing quite a lot if something like |
|
I think it is a bit sad to ask to each program using xcolor to implement it on his side because most of the time they will either forget to implement it, or use a syntax which will differ between programs. Concerning the parsing, I guess you know better than me what you are talking about, but answers like this one suggests that we can easily define a simpler parser that can recognize something like |
Why do you think that the parts need only to be passed to |
|
Even if adding a syntax to xcolor might not make it available in all other packages, it would still help standardize how the color model should be supported. Perhaps |
from the point of view of color and xcolor (and l3color and luacolor etc) that's not really an improvement, just adding a somewhat strained syntax duplicating
than
|
|
I'd rather see
|\whatever[color-model=HTML, color=00aa52]{zzz}|
than
|\whatever[color={[HTML]00aa52}]{zzz}|
But then if I define a shortcut
\newcommand\mywhat[1][]
{\whatever[color-model=HTML, color=00aa52, font=bold, #1]}
and somewhere I want to override the color with
\colorlet{decaff}{brown!50}
\mywhat[color=decaff]
then accidentally my overriding color is interpreted as HTML instead of a named
color.
|
|
well perhaps but that's just user error: if you define a command that takes html colors only then you need to pass that in, no different to any other command you define that may have syntax requirements. If the model isn't fixed as HTML you should expose that as an argument of the command being defined. |
|
Cooperation with all other packages that support color would probably be a nightmare. But in my opinion, this thread starts from a wrong point of view. Colors should be defined by name before their usage, possibly in a special section of the preamble. Coloring documents is not using whatever color pops out of mind at a given moment. They should be carefully chosen and weighed to mix with each other and in a small number. There's no such thing as “a color that's used only once” in a well formed document. Maybe in a small example one would not bother with defining names that carry some semantic about their usage. And for a TikZ application, one can just do It's possible that a brand new syntax might catch on and be supported in the future by packages such as TikZ/PGF, but I don't really expect it. |
|
In my opinion, the best and easiest solution is to provide only some hook to users and other packages. Then any one could write \AddToHook{xcolor/undefined}{
Do something you need
} |
That would introduce an order requirement into the key list and you would have to handle I don't think that this is worth it. As @eg9 wrote in most cases one should define a color first anyway, and in the cases where using values can make sense like in a \hypersetup the existing syntax is imho ok. |
|
While investigating #15, I browsed through the issues, found this one and thought: Hey, maybe the workaround might work for your use case, too... I think, some colors can be given as extended expressions, e.g., TikZ seems to accept something like the following: \documentclass{article}
\usepackage{tikz}
\begin{document}
\begin{tikzpicture}
\draw[fill={rgb:red,100;green,50;blue,20}] (5.0,0) rectangle ++(.4,.4);
\end{tikzpicture}
\end{document}That might be somewhat lengthy, but could maybe be used to specify colors on-the-fly... |
|
I'm closing this as it is not an xcolor issue. xcolor allows to use colors "on-the-fly" with the mentioned syntax |
As I explained in this question, using
definecoloreverytime I want to use a new color can be sometimes cumbersome. Notably, when the color is supposed to be used only once, it does not make sense to create a named color: it is not only time consuming, but it can also lead to strange bugs, for instance if multiple parts of the file redefine the same color by mistake.As of today, it is possible to use something like
\textcolor[HTML]{a65dbd}{...}but it does not generalize to other packages easily, each package need a custom code to accept this optional argument. For instance, it is not possible to do\tikz \node[draw=[HTML]{a65dbd},text=[HTML]{00aa00}]{...}, and people are struggling to find a syntax to add it to existing packages like tabularray lvjr/tabularray#106.On the other hand, xcolor already accepts pretty involved colors with arguments (which work for any package based on xcolor like tikz or tabularray...), like
red!50!white!30.Would it be possible to follow the approach used in
red!50!white!30to provide a way to use colors without defining them beforehand? Something likemodel(parameters), such asHTML(00aa52)orrgb(0.1,0.5,0.9)? If it's too hard to get a generic approach, at least could you provide this syntax for the html model as it is used pretty much in all applications?The text was updated successfully, but these errors were encountered: