"current color" handling

[u-fischer]

I'm trying to improve the use of spot colors in LaTeX. For some background see https://www.tug.org/TUGboat/tb43-2/tb134fischer-spotcolor.pdf.

A good solution for this problem requires the switch to the color commands provided the l3color module. This is complicated as various packages use "internal" commands of the color and xcolor package and would break if these internal commands change. (This is not meant as a reproach, due to the long history of these packages I'm quite aware that the border between internal and public interfaces are quite blurry and that some uses of internal commands simply reflect the fact that some interfaces were or still are missing.)

An example from tcolorbox is this

\def\tcb@set@color#1{%
  \edef\current@color{\@nameuse{\string\color@#1}}%
  \colorlet{.}{#1}%
}  

This is from my point of view problematic as

• It changes \current@color which should be only done by the color code when a color is actually selected (and so the current color actually changes)
• It makes an assumption about the internal format of \current@color by mapping it to \@nameuse{\string\color@#1}
• It makes an assumption about the internal format how color names are stored
• It changes the reserved color name .

I would be grateful to get some feedback why this is done this way. Why e.g. doesn't the code do something like \colorlet{tcb@tempcolor}{#1} and then use \color{tcb@tempcolor} later?

[muzimuzhi]

Looks like the key question is, why tcolorbox wants to update value of "current color" without pushing it to or popping it from the color stack? Similarly, which problems did tcolorbox want to resolve at each time when its color implementation grew?

• In v3.35 2015/01/07, one \colorlet{tcbcol@origin}{.} and several \letcs{\current@color}{\string\color@...} were added.
  Corresponding CHANGELOG entry:

  • text color implementation changed to fix some color problems

• In v3.50 2015/03/16, \tcb@set@color and \tcb@reset@color were introduced as a thin wrapper of \letcs{\current@color}{\string\color@...}.

  \def\tcb@set@color#1{%
    \letcs{\current@color}{\string\color@#1}%
    \colorlet{.}{#1}%
  }
  
  \def\tcb@reset@color{%
    \colorlet{.}{tcbcol@origin}%
    \letcs{\current@color}{\string\color@tcbcol@origin}%
  }

  CHANGELOG entry:

  • text color implementation changed to fix some color problems

• In v4.12 2018/01/12, \letcs{\current@color}{\string\color@...} were replaced with \edef\current@color{\@nameuse{\string\color@...}}.
  CHANGELOG entry:

  • color implementation changed to fix problems with expl3 (thanks to Ulrike Fischer)

Sorry I'm tired to do further digging today.

---

I find places where pgf manually uses \string\color@... as well. Just run grep -rni '\\string\\color@' **/*.tex on the top level of pgf-tikz repo. Even worse pgf has to make use of the structure of value stored in \\color@..., as discussed in the mentioned tugboat article. Should I record this in pgf-tikz too?

I have a feeling that xcolor may need to first expose some new macros, but in the expected naming as if l3color already takes over color works.

[u-fischer]

@muzimuzhi

Should I record this in pgf-tikz too?

Basically yes (I already investigated pgf-tikz a lot too), but I didn't want to do all at once. If you see missing interface, then please report them to xcolor. (Side remark: l3color doesn't know the concept of global colors, and that could be a problem in some places).

[T-F-S]

The reason for the implementation was a very time consuming trial and error process to iron out color bleeding problems years ago. As far as I remember, closing a problem here opened a problem there. Also, pdflatex, lualatex, xelatex all had their own special cases of problems. The current implementation is a working compromise.

I do not want to open Pandora's box. But, anyway, I'm open for suggestions for improvement.

Currently, I have no time to look into it (hopefully, next week or the week after).

[u-fischer]

It is a bit difficult to test properly and the code is rather complex due to the various boxes. But I have some doubts about this in the breakable library

   \pdfcolSwitchStack{tcb@breakable}%
   \pdfcolSetCurrentColor%

\pdfcolSetCurrentColor is imho useful to reinstate the current color after a switch back to the main color, but it feels wrong to use it to initialize the stack at the begin, as it then can really bleed out:

\documentclass{article}
\usepackage{xcolor}
\usepackage{pdfcol}
\begin{document}
\pdfcolInitStack{mystackB} 
\pdfcolInitStack{mystackA} 

{ 
 \color{blue}
  blue 
  {%
    \pdfcolSwitchStack{mystackA}%     
     {\pdfcolSetCurrentColor blue} black??
  }% 
  \pdfcolSetCurrentColor{}%
  blue  
}%
 black  \pdfcolSetCurrent{mystackA}black?? 


{ 
 \color{red}
  red 
  {%
    \pdfcolSwitchStack{mystackB}%     
     {\color{.}red} black
  }% 
 \pdfcolSetCurrentColor{}%
  red
}%
 black  \pdfcolSetCurrent{mystackB}black

\end{document}

[T-F-S]

\pdfcolSetCurrentColor is imho useful to reinstate the current color after a switch back to the main color, but it feels wrong to use it to initialize the stack at the begin, as it then can really bleed out:

Here, the idea is to initialize the color stack with the current color. The current color is given by \tcb@set@color as upper or lower color. The stack keeps track of possibly changed colors for the splitted boxes. Then, \pdfcolSetCurrent{tcb@breakable} is inserted before a box part is used.

Instead of \pdfcolSetCurrentColor I would rather like to use some \pdfcolSetColor to initialize the stack with a specific color, but pdfcol does not contain such a macro. This would help to avoid \tcb@set@color which, I think, primarily tries to avoid \color here, which would insert spaces/whatsits before tikzenvironment starts.

[T-F-S]

To sum up a little history:

In version 4.32, color handling did not need \tcb@set@color with changing \current@color. Here, I tried a cleaner approach, but this did work for pdflatex and, I think, lualatex, but not Xelatex, see #120.

Therefore, I reverted back to the old/current handling with 4.42.

[u-fischer]

Instead of \pdfcolSetCurrentColor I would rather like to use some \pdfcolSetColor to initialize the stack with a specific color, but pdfcol does not contain such a macro. This would help to avoid \tcb@set@color which, I think, primarily tries to avoid \color here, which would insert spaces/whatsits before tikzenvironment starts.

I'm not completly sure that I get your meaning but I think that you have a misunderstanding here. \pdfcolSetCurrentColor does insert a whatsits too, so the reason why it is used there can't be to avoid that. Also tt would be easy to define a \pdfcolSetColor but there is no real need, as you would get the same as with \pdfcolSwitchStack{tcb@breakable}\color{.} or
\pdfcolSwitchStack{tcb@breakable}\color{somename} (depending on what your want).

In version 4.32, color handling did not need \tcb@set@color with changing \current@color. Here, I tried a cleaner approach, but this did work for pdflatex and, I think, lualatex, but not Xelatex, see #120.

I will try to look later what is going on there.

[u-fischer]

To sum up a little history:

In version 4.32, color handling did not need \tcb@set@color with changing \current@color. Here, I tried a cleaner approach, but this did work for pdflatex and, I think, lualatex, but not Xelatex, see #120.

I took a look. I could reproduce the error from #120 with version 4.32 in a texlive 2019 but it disappears in texlive 2020. I'm not completly sure why, but looking at the logs and \showoutput, my hunch would be that with the advent of LaTeX hooks pgf stopped to doing low-level manipulations with everyshi.

[T-F-S]

I took a look. I could reproduce the error from #120 with version 4.32 in a texlive 2019 but it disappears in texlive 2020. I'm not completly sure why, but looking at the logs and \showoutput, my hunch would be that with the advent of LaTeX hooks pgf stopped to doing low-level manipulations with everyshi.

That is interesting and (hopefully) good news. I will do tests with an approach similar to 4.32 with cleaner code and see, if the \current@color hacks can be removed.

[T-F-S]

I try to come up with an MWE to test a proper a color stack usage for breakable boxes. It should simplify what happens (or should happen) with a tcolorbox.

The MWE uses

• two boxes \upperbox and \lowerbox which are splitted into three parts each
• a single color stack mystack
• the \upperbox is colored in red, the \lowerbox in green; also a color change happens inside the boxes

\documentclass{article}

\usepackage[a4paper]{geometry}

\usepackage{tikz}
\usepackage{pdfcol}

\newbox\upperbox
\newbox\lowerbox
\newbox\partbox

\pdfcolInitStack{mystack}%  remove to disable color stack

\begin{document}

\setbox\upperbox=\vbox{%
  \hsize=5cm%
  \begingroup%
  \pdfcolIfStackExists{mystack}{%
    \pdfcolSwitchStack{mystack}%
    \leavevmode\color{red}}{}%
  1 red 1 red 1 red 1 red 1 red 1 red 1 red 1 red
  1 red 1 red 1 red 1 red 1 red 1 red 1 red 1 red
  1 red 1 red 1 red 1 red 1 red 1 red 1 red 1 red
  \color{blue}
  1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue
  1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue
  1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue
  1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue
  1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue
  \endgroup
}

\setbox\lowerbox=\vbox{%
  \hsize=5cm%
  \begingroup%
  \pdfcolIfStackExists{mystack}{%
    \pdfcolSwitchStack{mystack}%
    \leavevmode\color{green}}{}%
  2 green 2 green 2 green 2 green 2 green 2 green
  2 green 2 green 2 green 2 green 2 green 2 green
  2 green 2 green 2 green 2 green 2 green 2 green
  \color{yellow}
  2 yellow 2 yellow 2 yellow 2 yellow 2 yellow 2 yellow
  2 yellow 2 yellow 2 yellow 2 yellow 2 yellow 2 yellow
  2 yellow 2 yellow 2 yellow 2 yellow 2 yellow 2 yellow
  2 yellow 2 yellow 2 yellow 2 yellow 2 yellow 2 yellow
  2 yellow 2 yellow 2 yellow 2 yellow 2 yellow 2 yellow
  \endgroup
}

\noindent text before picture
\bigskip

\noindent%
\begin{tikzpicture}

\setbox\partbox=\vsplit\upperbox to 1cm%

\draw[gray] (0,-1) -- (0,0) -- (5,0) -- (5,-1);
\draw[gray] (6,-1) -- (6,0) -- (11,0) -- (11,-1);

\pgftext[x=0cm,y=0cm,left,top]{%
  \begingroup
  \pdfcolIfStackExists{mystack}{\pdfcolSetCurrent{mystack}}{\color{red}}%
  \box\partbox
  \endgroup
}

\setbox\partbox=\vsplit\upperbox to 2cm%

\pgftext[x=0cm,y=-1.5cm,left,top]{%
  \begingroup%
  \pdfcolIfStackExists{mystack}{\pdfcolSetCurrent{mystack}}{\color{red}}%
  \box\partbox%
  \endgroup%
}

\pgftext[x=0cm,y=-4cm,left,top]{%
  \begingroup%
  \pdfcolIfStackExists{mystack}{\pdfcolSetCurrent{mystack}}{\color{red}}%
  \box\upperbox%
  \endgroup%
}

\setbox\partbox=\vsplit\lowerbox to 1cm%

\pgftext[x=6cm,y=0cm,left,top]{%
  \begingroup%
  \pdfcolIfStackExists{mystack}{\pdfcolSetCurrent{mystack}}{\color{green}}%
  \box\partbox%
  \endgroup%
}

\setbox\partbox=\vsplit\lowerbox to 2cm%

\pgftext[x=6cm,y=-1.5cm,left,top]{%
  \begingroup%
  \pdfcolIfStackExists{mystack}{\pdfcolSetCurrent{mystack}}{\color{green}}%
  \box\partbox%
  \endgroup%
}

\pgftext[x=6cm,y=-4cm,left,top]{%
  \begingroup%
  \pdfcolIfStackExists{mystack}{\pdfcolSetCurrent{mystack}}{\color{green}}%
  \box\lowerbox%
  \endgroup%
}

\end{tikzpicture}

\bigskip
\noindent text after picture

\end{document}

For pdflatex and lualatex this gives:

For xelatex this gives (as has to be expected):

This second output is also what we get, if the color stack handling is removed.

I am open for improvements for this MWE code:

• Is it OK to have just one color stack for both boxes? (Seems to work)
• Is the color stack empty after the picture or is it growing with waste?
• Is this code compatible to the planned spot color features?

If this code has no fundamental flaws, my next step would be changing the real implementation following that pattern.

[u-fischer]

The grouping is wrong. If you look into the log you will see message like this:

pdfTeX warning: pdflatex-dev.exe: pop empty color page stack 0
pdfTeX warning: pdflatex-dev.exe: pop empty color page stack 0
pdfTeX warning: pdflatex-dev.exe: pop empty color page stack 0

This means that you pushed colors on your stack (1) but pop them from the main stack 0.
This happens because \color resets ("pops") a color with \aftergroup. And so you typically need two group layers:

\documentclass{article}
\usepackage{pdfcol}

\pdfcolInitStack{mystack}%  remove to disable color stack

\begin{document}
% Wrong:
{
 \pdfcolSwitchStack{mystack} \color{red} %pushes to stack 1
} % after the group popped from stack 0  


% Correct

{
 \pdfcolSwitchStack{mystack} 
  {
    \color{red} %pushes to stack 1
  } % after the group popped from stack 1  
} % now back to stack 0

% alternative (needs implementation ...)

\pdfcolSwitchStack{mystack} 
 {
    \color{red} %pushes to stack 1
 } % after the group popped from stack 1  
\pdfcolSwitchStack{main} % currently missing but could be added. 
\end{document}

For your boxes this means something like this

\setbox\upperbox=\vbox{%
  \hsize=5cm%
  \pdfcolIfStackExists{mystack}{%
    \pdfcolSwitchStack{mystack}}{}%
  \begingroup%
    \leavevmode\color{red}
  1 red 1 red 1 red 1 red 1 red 1 red 1 red 1 red
  1 red 1 red 1 red 1 red 1 red 1 red 1 red 1 red
  1 red 1 red 1 red 1 red 1 red 1 red 1 red 1 red
  \color{blue}
  1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue
  1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue
  1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue
  1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue
  1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue 1 blue
  \endgroup
}

Is this code compatible to the planned spot color features?

Yes, my main problem there is the use of "internals". As soon as package use only user interface I can change the backend as needed.

[T-F-S]

This means that you pushed colors on your stack (1) but pop them from the main stack 0.
This happens because \color resets ("pops") a color with \aftergroup. And so you typically need two group layers:

Thank you for your helpful explanations. I would never figured out the necessity for two group layers.

[T-F-S]

I integrated the changes into the actual tcolorbox code (not uploaded yet), but finally run into some problems. I think this kind of problems are the real reason for \current@color trickery.

The situation is: If no color stack is used, the box content is saved without coloring into a \box. Later this box is used with a given color. The reason is to avoid a whatsit at the begin of the content.

Problems arise with things like itemize or listings which obviously use the current color while the \box is created. For itemize I made the following MWE to show:

\documentclass{article}

\usepackage[a4paper]{geometry}

\usepackage{tikz}

\newbox\upperbox

\begin{document}

\color{blue}

\noindent Blue text.

% miracle code to trick the current color to red without inserting
% a whatsit and without using internals

\setbox\upperbox=\vbox{%
  \hsize=5cm%
  \begingroup%
  %\color{red}%   inserts a whatsit (no visual effect in this MWE)
  \begin{itemize}
  \item Item 1
  \item Item 2
  \end{itemize}
  \endgroup%
}

\noindent%
\begin{tikzpicture}
\pgftext[x=0cm,y=0cm,left,top]{%
  \begingroup
  \color{red}%
  \box\upperbox
  \endgroup
}
\end{tikzpicture}

\noindent Text after picture.

\end{document}

This gives blue bullets instead of red bullets:

I see two possibilites:

• Adding miracle code to trick itemize, listings etc. to think the current color is red without adding a whatsit. My version of such a miracle code is the internals hackery which should be replaced.
• Inserting \color{red} or \leavevmode\color{red} directly in the box and accepting the additional vertical space which will appear. This would change (many?) existing \tcolorboxes and will give some user complaints. Because of complaints I made the color stack usage optional where this whatsit insertion cannot be avoided... Mainly, boxes starting with itemize and friends would get additional spacing, most others not.

[u-fischer]

The bullets are black as their code "ensure" the current color (as does \sbox) with \color@setgroup. You can avoid that with

\makeatletter
\setbox\upperbox=\vbox{%
  \hsize=5cm%
  \begingroup%
  \def\color@setgroup{\begingroup}
  %\color{red}%   inserts a whatsit (no visual effect in this MWE)
  \begin{itemize}
  \item Item 1 {\color{green} aaaa}
  \item Item 2
  \end{itemize}
  \endgroup%
}

If this works for you generally, I could think about some user interface, e.g. \noensurecurrent or something like that. (I don't have much time today).

[T-F-S]

\def\color@setgroup{\begingroup}

A possible problem with this could be that if the box has complex content (boxes in boxes, all kind of stuff), this could give a lot of side effects (worse than the original hack which is overwritten with every internal color setting).

I test-implemented the other approach (color insertion at the begin of every \box). The most notable complaint from the past was the xelatex problem which now seems to have vanished. For the spacing with itemize and friends I made more tests with the following MWE:

\documentclass{article}

\usepackage[a4paper]{geometry}

\usepackage{tcolorbox}
\tcbuselibrary{breakable,skins}

\NewTColorBox{testbox}{ O{} m }{%
    draft,
    size     = tight,
    colupper = red,
    collower = yellow,
    title    = {#2},
    #1
  }

\begin{document}

(A) Simple:

  \begin{testbox}{Basic box}
    Upper color red.\par
    \color{green} Something in green.
  \end{testbox}

  \begin{testbox}[breakable]{Breakable box}
    Upper color red.\par
    \color{green} Something in green.
  \end{testbox}

  \begin{testbox}[breakable,use color stack]{Breakable box with color stack}
    Upper color red.\par
    \color{green} Something in green.
  \end{testbox}

(B) Itemize:

  \begin{testbox}{Basic box}
    \begin{itemize}
    \item Item 1
    \item Item 2
    \end{itemize}
  \end{testbox}

  \begin{testbox}[breakable]{Breakable box}
    \begin{itemize}
    \item Item 1
    \item Item 2
    \end{itemize}
  \end{testbox}

  \begin{testbox}[breakable,use color stack]{Breakable box with color stack}
    \begin{itemize}
    \item Item 1
    \item Item 2
    \end{itemize}
  \end{testbox}

(C) Itemize with with color change:

  \begin{testbox}{Basic box}
    \begin{itemize}
    \item Item red
    \color{green}
    \item Item green
    \end{itemize}
  \end{testbox}

  \begin{testbox}[breakable]{Breakable box}
    \begin{itemize}
    \item Item red
    \color{green}
    \item Item green
    \end{itemize}
  \end{testbox}

  \begin{testbox}[breakable,use color stack]{Breakable box with color stack}
    \begin{itemize}
    \item Item red
    \color{green}
    \item Item green
    \end{itemize}
  \end{testbox}

\end{document}

Most notably is test example (C) which gives with the current implemenation and pdflatex:

The new test implementation with color setting at begin of every \box and pdflatex gives:

A made compilations with pdflatex, lualatex, and xelatex with a variants. The following rough table displays the height of the upper box:

My current considerations are:

• None of the itemize examples with color change are optimal - not with the current implementation and not with the test color setting implementation. In that sense, the new implemenation does not worsen things.
• With simple boxes (not starting with an itemize etc), denoted by mini example (A), the new implementation does not impose vertical changes
• For the itemize examples there is possible additional vertical space. I do not have the time now, but maybe end of next week I try to research what complaints were filed in the past against version 4.32 - and if they really speak against the new test implemenation
• A real advantage of the new test implementation is that (for the examples) there is no height difference between boxes which are unbreakable/breakable/breakable with color stack (see table).
• Side note: lualatex and xelatex behave nearly identical (rounded), but pdflatex produces boxes with less height. My guess is that this has to do with different font measurement (?)

I will come back to this end of next week, but my current feeling is, that I should go for the color setting implementation (which needs no hacks and therefore is cleaner).

[u-fischer]

regarding the additional spacing: you could try if hyperref's method (which has to suppress spaces from anchors) helps. Basically it does in vmode (see e.g. https://tex.stackexchange.com/a/600142/2388)

\Hy@SaveLastskip
 %problematic code
\Hy@RestoreLastskip

(but I didn't test ...)

[T-F-S]

\Hy@SaveLastskip
%problematic code
\Hy@RestoreLastskip

There was no difference with this code...

Changing the implementation to direct color setting at the begin of a box, which is IMHO the natural thing to do but was avoided with tricks until now, will add additional spacing at begin of a tcolorbox, if enumerate or similar code it there. This was formerly discussed in

• v4.32: Extra top space if tcolorbox env starts with a list #123: Here, a \vspace{-\parsep} can be used to remove the additonal space.
• https://tex.stackexchange.com/questions/565801/color-stack-switch-with-current-color-interferes-with-vertical-list: Here the verdict was that the problem must be solved on the latex side

Also see the following example which displays the effects with boxed enumeration lists AND side effects coming from just including hyperref:

\documentclass{article}

\usepackage{color}
%\usepackage{hyperref}

\begin{document}

\fbox{%
  \begin{minipage}{10cm}%
  \begin{enumerate}
    \item abc
  \end{enumerate}
  \end{minipage}%
}

\fbox{%
  \begin{minipage}{10cm}%
  \color{red}%
  \begin{enumerate}
    \item abc
  \end{enumerate}
  \end{minipage}%
}

\end{document}

Here, the additional space is clearly seen.

Now, if hyperref is included, the output changes to

Presumably, hyperref fiddles with \item. Now, the space is everywhere.

From my current point of view I see two ways for tcolorbox:

• Do nothing. Obviously, problems will arise as soon as the color implementation changes
• Insert colors at begin of a box and accept additional spaces. v4.32: Extra top space if tcolorbox env starts with a list #123 opened by @muzimuzhi will come up again, but then it is as it is...

[u-fischer]

\Hy@SaveLastskip
%problematic code
\Hy@RestoreLastskip

There was no difference with this code...

Yes, I realized that it wasn't useful as you aren't on the main galley but in a box.

Presumably, hyperref fiddles with \item. Now, the space is everywhere.

The problem is the \refstepcounter (which is issued before the item) and sets an anchor, which is a whatsits like the color, and whatsits are sometimes quite a pain ;-)

With hyperref and lists one could resolve the problem: hyperref could set the anchor later, when the paragraph has started, but with color it is bit more difficult unless you use luatex and luacolor ;-). If you have control, you naturally can try to move the color setting:

\documentclass{article}

\usepackage{color}

\begin{document}

\fbox{%
  \begin{minipage}{10cm}%
  \color{red}%
  \begin{enumerate}
    \item abc
  \end{enumerate}
  \end{minipage}%
}

\fbox{\leavevmode\color{red}%
  \begin{minipage}{10cm}%
  \begin{enumerate}
    \item abc
  \end{enumerate}
  \end{minipage}%
}

\end{document}

[T-F-S]

If you have control, you naturally can try to move the color setting:

Yes, that's the basic idea of the current tcolorbox implementation (not setting the color inside the box, but outside). Nevertheless, I'm frustrated in this question for tcolorbox. With the direct color setting, the boxes of my 500 pages documentation do not change visibly for the more than overwhelming part. If no dramatic things come up, I am going to do the new color setting and document the changes/problems.

[T-F-S]

Just an additional remark: lualatex plus luacolor work flawless with the new test implementation.

[T-F-S]

I uploaded a preview version of tcolorbox with the new color setting method (no hacks anymore):
dabf431

There were several side effects, especially for the parbox=false feature. I added circumventions which seem to work.

[u-fischer]

Just an additional remark: lualatex plus luacolor work flawless with the new test implementation.

luacolor is much more safer and easy to use ;-) One reason why we explore https://github.com/latex3/xpdftex.

[u-fischer]

Regarding lists and color/hyperref whatsits at the begin of boxes: latex3/latex2e#989. I can't be completly sure, but I think it will also resolve the tcolorbox problems. At least if I insert manually a color command before the list (in the second box) then I get this with the new code:

compared to this with the old code:

[T-F-S]

Done with https://github.com/T-F-S/tcolorbox/releases/tag/v6.0.0