Save color data for expl3

[josephwright]

Internal housekeeping

Status of pull request

• Feedback wanted

Checklist of required changes before merge will be approved

• [ ] Test file(s) added
• [x] Version and date string updated in changed source files
• [x] Relevant \changes entries in source included
• [x] Relevant changes.txt updated
• [ ] ltnewsX.tex updated

[FrankMittelbach]

anything open on this one or could/should it be merged? or has the backend changed?

[josephwright]

This is independent of the backend: it will work as long as l3color is loaded. (Longer-term I'd like to merge that to expl3 core, but that's also independent.)

Assuming it looks OK, I'd like to see it merged. More tricky is xcolor (as there are models it provides that are not at present in l3color), but that is also solvable.

[u-fischer]

One of the color changes in one branch/pull request failed with the named color model but I haven't had the time to check if this is the one or if I have another one in mind. I will try to look in the afternoon.

[u-fischer]

This here breaks with latex-dev:

\documentclass{article}
\usepackage{l3color}
\usepackage{color}
\begin{document}
blub
\end{document}

when reading the \DefineNamedColor{named}{GreenYellow} {cmyk}{0.15,0,0.69,0} definitions in dvipsnam.def:

.... /tex/latex-dev/graphics/dvipsnam.def
File: dvipsnam.def 2016/06/17 v3.0m Driver-dependent file (DPC,SPQR)
! LaTeX3 Error: Unknown color model 'GreenYellow'.

For immediate help type H <return>.
 ...                                              
                                                  
l.20 ...amed}{GreenYellow}   {cmyk}{0.15,0,0.69,0}

[josephwright]

Ah, right, that would be tricky: do you want us to even try to set up named colors? Either way, we'll need some dedicated function that allows for 'unknown model' cases.

[car222222]

Where do these 'unnamed model cases' come from?

If there is a possibility to end up in such a situation, then maybe assume RGB and give a warning?

More complex would be to look at the number of coordinates given (if any) and map

1 to Gray 3 to RGB 4 to cmyk

[josephwright]

@car222222 Separations are each models in their own right, so l3color is moving to having them not as a single spot model but rather creating a model for each one. That is currently a work-in-progress that @u-fischer and I are refining.

[car222222]

Sure, but that has little to do with ordinary 'named colors' like these defined by dvips.

And these would all have a color model specified. So where do the 'unspecified model' cases come from?

[car222222]

Oh maybe you mean 'unknown to ...' well, to what?

[u-fischer]

Sure, but that has little to do with ordinary 'named colors' like these defined by dvips.

It isn't so easy. The named colors in the postscript have quite a lot in common with spot colors/separation in the pdf: They need a setup in the header, they use a name in the stream (and a printer could change the header so that every such color uses an ink), and they have a cmyk fallback. The main difference to separation is that there is no tint value, so instead of an 1-dimensional colorspace with a range of color there is only a 0-dimensional with one color.

@josephwright

Ah, right, that would be tricky: do you want us to even try to set up named colors?

I suspect we should try to do this ;-(

Setting them up as "0-dimensional-color-space" could work: \DefineNamedColor{named}{White} {cmyk}{0,0,0,0} would then create the color space and the single color instance if dvips is detected but define a normal cmyk color in the other cases. All the colorspace code would apply then.

An alternative could be to have with dvips e.g. "namedcmyk" and "namedrgb" models with a dedicated backend function. That could work too. But I'm not sure how mixing would work, it would probably lead to more combinations wouldn't it?

[josephwright]

@u-fischer Something like

\protected\def\DefineNamedColor#1#2#3#4{%
  \@ifundefined{define@color@#1}%
    {\c@lor@error{model `#1'}}%
    {\@ifundefined{color@#3}%
      {\c@lor@error{model `#3'}}%
      {\@ifundefined{col@#2}{}%
        {\PackageInfo{color}{Redefining color #2 in named color model}}%
      \csname color@#3\endcsname\@tempa{#4}%
      % New: support "usenames"
      \ifx\c@lor@usename\@gobble\else
        \@expl@color@set@@nnn{#2}{#3}{#4}%
      \fi
      \csname define@color@#1\endcsname{#2}\@tempa
      \c@lor@usename{#2}}}}

deals with the current case, at least where usenames is active (though we could just force the issue and declare in all cases). If we ignore the usenames test, we could avoid 'legacy spot colors' needing special handling: they are just colors in their fallback model for l3color. Would that work?

[car222222]

@u-fischer Aha, now I see what we are talking about! I thought it was 'named colours' on the a Latex side.

I need to look at the details of what the dvips colour names etc. stuff needs to do, both in the postscript and in the eventual (in the English sense:-) pdf.

Meantime, we need a different terminology for these two: 'using colours set up, with names supplied by, or known to, a consumer, in the pdf (possibly derived from postscript header); and 'naming colours on the latex side' when there is no need for any header file or pdf resources.

I wrote something (probably not enough) about this under Issue latex3/#746.

Important point! There is no reason to drop the second case: simple names on the LaTeX side only are very useful and important. Just do not call them (or anything else:-) 'spot colors'.

I have a lot more to say about this but enough for now.

[car222222]

@josephwright wrote: they are just colors in their fallback model for l3color.

Not quite, rather: 1 They are just colors with a LaTeX name.
2 They can have specifications in any color space, possibly in many. 3 They do not need to have (and probably will not have) any relationship to any Separation color space.

In practice most of these 'named colors' will be simply names of things in the rgb color space as they will not be used for printing, maybe some will provide explicit cmyk values for 'home/office printing' but that is unnecessary.

[josephwright]

@josephwright wrote: they are just colors in their fallback model for l3color.

Not quite, rather: 1 They are just colors with a LaTeX name. 2 They can have specifications in any color space, possibly in many. 3 They do not need to have (and probably will not have) any relationship to any Separation color space.

In practice most of these 'named colors' will be simply names of things in the rgb color space as they will not be used for printing, maybe some will provide explicit cmyk values for 'home/office printing' but that is unnecessary.

My point was the 'link' here is being set up to help @u-fischer with hyperref, etc., so these historical cases just need to resolve to something we can export in a parameter-based model.

[car222222]

Sure, good. hyperlink needs all the help we can give it:-). I must check why it is playing with color too.

[davidcarlisle]

On Wed, 29 Jul 2020 at 15:54, Ulrike Fischer [email protected] wrote:

Sure, but that has little to do with ordinary 'named colors' like these defined by dvips.

It isn't so easy. The named colors in the postscript have quite a lot in common with spot colors/separation in the pdf: They need a setup in the header, they use a name in the stream (and a printer could change the header so that every such color uses an ink), and they have a cmyk fallback. The main difference to separation is that there is no tint value, so instead of an 1-dimensional colorspace with a range of color there is only a 0-dimensional with one color.

@josephwright https://github.com/josephwright

Ah, right, that would be tricky: do you want us to even try to set up named colors?

I suspect we should try to do this ;-(

Setting them up as "0-dimensional-color-space" could work: \DefineNamedColor{named}{White} {cmyk}{0,0,0,0} would then create the color space and the single color instance if dvips is detected but define a normal cmyk color in the other cases. All the colorspace code would apply then.

An alternative could be to have with dvips e.g. "namedcmyk" and "namedrgb" models with a dedicated backend function. That could work too. But I'm not sure how mixing would work, it would probably lead to more combinations wouldn't it?

the color package named color model does support named colours as one dimensional parameterised by a numeric value in addition to the color name (possibly only implemented in textures)

% The color2' drivers (textures) use a special postscript operator % that takes both the name and the cmyk equivalent. so if the names are % not being used, fall back' definitions in the cmyk model are available. % These drivers also allow a numeric value to affect the `density' % of the colour to use.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.

[josephwright]

Are we good to go here? This would be nice to have in 2021-05-01.

[u-fischer]

@josephwright imho it is fine and it should be merged.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.

[josephwright]

Bump

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.