-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
L3 interface #41
Comments
As you may be aware there is a separate L3 interface to colors https://github.com/latex3/latex3/blob/develop/l3kernel/l3color.dtx that has similar syntax to xcolor but a different underlying implementation. At some point there will probably need to be some legacy unifying module to help integrate l3color/xcolor/color but currently for now if you want an L3 color module I would use l3color rather than wrapping an L3 syntax over xcolor. |
Your question is quite unclear. The dvipsnames and svgnames option simply load files with a bunch of color definitions. If you don't want to load the files you have to retrieve the values and define the colors manually:
There are no namespaces and I don't see how l3 can simplify or even help with such color definitions. |
Doing this for several colors would quickly become unmaintainable. I was thinking of something like the following dummy code, which would be very practical, but perhaps it would make more sense to have a dedicated package that provided multiple color palettes ready-to-use.
|
well not more unmaintainable then the current definitions in the .def files. If you want a number of predefined colors someone has to write them down first, they can not appear out of the blue. If you don't want to load one of the existing collections you will have to write your own collection. |
Could I then use the definitions used by If so, do I need to respect a license, or not? I'd be inclined to use a Creative Commons-type license. |
We do not want an arbitrary list of colours in |
That's why I am finally talking about a specific package proposing |
If you load the pdfmanagement colors defined for xcolor are also defined for l3color:
|
But, AFAI, you can't work with |
sure you can. Nobody prevents you from loading as many color definitions as you want. You only get problems if they define the same name in a clashing way. Sorry but I really don't get what you want. dvipsnames and svgnames are rather random collections of color names, they are others on ctan, e.g. xkcdcolors and ninecolors. They are useful if you want fast a bunch of different colors, but nothing more. In any important document or template I would take care to define the document colors manually and not rely on such lists. |
It's a shame that these color palettes aren't brought together in a single package to simplify their use via a unified syntax... For example, we have |
why do you need these color names at all? As Ulrike says there is a use for a quick access to a set of names for some documents but what's the use case for using multiple sets or having a package that loads the existing ones, few documents use more than three or four colors so by the time you have loaded the combined package and selected options to select whichever set you want it would be simpler to simply declare the colors you want in the document. |
This can be useful for graphical themes and to simplify their definitions. |
Is there a
LaTeX3
interface for coders?This could be used, for example, to access the cyan of namespace
svgnames
, and the green fromdvipsnames
. Useful? Yes, if a named color suits us insvgnames
, but not indvipsnames
, and vice versa. It seems to me that it would even be better to stop using thesvgnames
anddvipsnames
class options.I don't know if this is a good idea, but I'll suggest it anyway.
The text was updated successfully, but these errors were encountered: