support of CMYK colors in dvisvgm backend about latex3

[josephwright]

@mgieseki That approach occurred to me to: I'm going to see how well it works in practice.

[u-fischer]

In your example the code is clearly from the tikz backend driver, the relevant code is in pgfsys-common-svg.def and pgfsys-dvisvgm.def.

So you should make for this a feature request at the pgf/tikz repo.

But I checked also the l3draw code, and it applies to the stroke color a conversion:

\documentclass[dvisvgm]{article}
\usepackage{l3draw}

\begin{document}\showoutput
\ExplSyntaxOn
%temporary bug fix
\cs_set_eq:NN\__color_backend_cmyk:w\__color_backend_stroke_cmyk:w

\color_set:nnn{mycolor}{cmyk}{1, 0, 1, 0}
\tl_set:Nn\l_color_fixed_model_tl{cmyk}

\draw_begin:
\draw_path_moveto:n { 0cm , 0cm }
\draw_path_lineto:n { 1cm , 1cm }
\draw_path_lineto:n { 2cm , 1cm }
\draw_path_lineto:n { 3cm , 0.5cm }
\draw_path_lineto:n { 3cm , 0cm }
\color_stroke:n { mycolor }
\color_fill:n { mycolor }
\draw_path_use_clear:n { fill , stroke }
\draw_end:
\ExplSyntaxOff
\end{document}

This shows these specials:

.......\special{dvisvgm:raw <g stroke="rgb(-0%,-100%,-0%)">{?nl}}
.......\special{color push cmyk 1.0 0.0 1.0 0.0}

I assume that is wrong for your use case too and the stroke color should be set differently?

[josephwright]

Is there an (easy) way to detect the version of dvisvgm within the output? We need to allow for older and newer versions, at least for a transition.

[mgieseki]

In your example the code is clearly from the tikz backend driver, the relevant code is in pgfsys-common-svg.def and pgfsys-dvisvgm.def.
So you should make for this a feature request at the pgf/tikz repo.

Thank you for the fast reply and the helpful information. I'll post a feature request there too.

.......\special{dvisvgm:raw <g stroke="rgb(-0%,-100%,-0%)">{?nl}}
.......\special{color push cmyk 1.0 0.0 1.0 0.0}

I assume that is wrong for your use case too and the stroke color should be set differently?

Yes, right. Since there's no information about the intended CYMK color space, dvisvgm can't do the conversion here either.

Is there an (easy) way to detect the version of dvisvgm within the output? We need to allow for older and newer versions, at least for a transition.

What output do you refer to exactly? dvisvgm adds a comment to the generated SVG files with version information.
However, I think, it's not necessary to handle the older dvisvgm releases differently. The {?color} macro has already been available since version 0.7.1. It just used a different conversion function for CMYK colors resulting in different RGB hex values. The suggested mixture of color and dvisvgm:raw specials should work with both the previous and latest versions.

[josephwright]

Right - I think the reason for the current code in dvisvgm.def (and others) is that it will go back a long way, plus the ?color directive is only mentioned very briefly in the docs.

[mgieseki]

Indeed. I've made a note to extend the explanations of the macros. Usually it only becomes apparent in cases like this that the initially added information is too brief. So thanks for the feedback.

[josephwright]

Ah, right, I see why this might not be so useable. For the L3 backend, we cover 'general' colour and fill/stroke colour - 'general' colour is what applies outside drawings. For 'general' colour or for fill colour, with dvisvgm we can use the colour stack in the same way as dvips. However, stroke colour needs to be handled manually as dvisvgm only has one colour stack which can hold only one colour. Contrast that with the model in pdfTeX where we can stack stroke and fill colour separately.

The result in dvisvgm (and in dvips) is that stroke colour has to be managed at the macro level. The problem then is that {?color} won't know what the stroke colour is at all: it only knows the fill colour. I'm not sure that is solvable at present.

[mgieseki]

Ok, I see. Wouldn't it be possible to switch the stroke/fill color using classic color specials? I guess, the backend knows the two colors as they are currently hard-coded in the SVG attributes. I would have thought you could set them with color specials instead of directly writing the attribute values even if that's somewhat cumbersome:

xxx: 'color push cmyk 0 1 1 0'
xxx: 'dvisvgm:raw <g stroke="{?color}"'
xxx: 'color pop'
xxx: 'color push cmyk 1 0 1 0'
xxx: 'dvisvgm:raw fill="{?color}">{?nl} '

But maybe it's more complex and this color swapping would break the current usage of the stack.
Of course, I could also add a separate stack for the stroke color in one of the next updates.

[josephwright]

Taking a look, seems we stick with current approach for other models and just adjust CMYK.