# tcolorbox doesn't print offset correctly? [closed]

Edit: It turned out to be my PDF viewer.

So I made this little tcolorbox and the distance between each subsequent pair of rules does not match for all rules:

The code I have is this:

\documentclass{article}
\usepackage[skins]{tcolorbox}
\definecolor{bg}{HTML}{F8FAFF}
\definecolor{col1}{HTML}{80B2FF} %4 Outer right borderline
\definecolor{col2}{HTML}{99C2FF} %3
\definecolor{col3}{HTML}{B2D1FF} %2
\definecolor{col4}{HTML}{CCE0FF} %1 Outer left borderline
\newdimen\BLW % BorderLine Width
\BLW\dimexpr 5pt\relax
\newdimen\BLS % BorderLine Sep
\BLS\dimexpr 0pt\relax
\newdimen\BLLa % Gap'' between first and second line
\BLLa\dimexpr -\BLW-\BLS-(\dimexpr 3\BLW/4)/2\relax\relax
\newdimen\BLLb % between second and third line
\BLLb\dimexpr -\BLW-\BLS-(\dimexpr 3\BLW/4)-\BLS-(\dimexpr 9\BLW/16)/2 \relax\relax\relax
\newdimen\BLLc % between third and fourth line
\BLLc\dimexpr -\BLW-\BLS-(\dimexpr 3\BLW/4) -\BLS-(\dimexpr 9\BLW/16)-\BLS-(\dimexpr 27\BLW/64)/2 \relax\relax\relax\relax

\begin{document}
\begin{tcolorbox}[
width=\linewidth-6pt,
frame hidden,
colback=bg,
freelance,
arc=0pt,
boxrule=0pt,
frame code={
\draw[col1,line width=\BLW]  % right
([xshift=-\BLW/2]frame.north west) -- ([xshift=-\BLW/2]frame.south west);
\draw[col2,line width=3\BLW/4]
([xshift=\BLLa]frame.north west) -- ([xshift=\BLLa]frame.south west);
\draw[col3,line width=9\BLW/16]
([xshift=\BLLb]frame.north west) -- ([xshift=\BLLb]frame.south west);
\draw[col4,line width=27\BLW/64]
([xshift=\BLLc]frame.north west) -- ([xshift=\BLLc]frame.south west);
}
]
some stuff
\end{tcolorbox}

BLW: \the\BLW\relax

BLS: \the\BLS\relax

$\frac{3}{4}$ BLW: \the\dimexpr3\BLW/4\relax

$\frac{9}{16}$ BLW: \the\dimexpr9\BLW/16\relax

$\frac{27}{64}$ BLW: \the\dimexpr27\BLW/64\relax

BLLa: \the\BLLa\relax

BLLb: \the\BLLb\relax

BLLc: \the\BLLc\relax

\end{document}


As you can see the \dimexpr values are in fact correct, while the offset of the borderlines/rules is not. (This offset should be equal to the \BLS, but instead it's all over the place.)

To understand how I calculated the placement of the rules to create a static offset about \BLS, consider this picture:

Printed values with the \the command show correct values, but the tcolorbox

## closed as off-topic by 1010011010, Heiko Oberdiek, ienissei, Thorsten, WernerMay 17 '14 at 16:43

• This question does not fall within the scope of TeX, LaTeX or related typesetting systems as defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

• Can you give details in which way the calculation is not accurate? – Stephan Lehmke May 17 '14 at 14:12
• Don't assume people have listings (or tcolorbox) or rather assume that they don't want to see them in a question about \dimexpr please make a minimal example (in this case presumably a single call to \dimexpr with a value you think inaccurate. – David Carlisle May 17 '14 at 14:22
• This question appears to be off-topic because the problem was the used PDF viewer. – Heiko Oberdiek May 17 '14 at 16:30
• Voted to close this. :-) – 1010011010 May 17 '14 at 16:32

Your assertion about \dimexpr is not demonstrated by your example. The \dimexpr calculations seem accurate, although you have used a rather verbose style with redundant nested \dimexpr which could be simplified to

\documentclass{article}

\newdimen\BLW % BorderLine Width
\BLW\dimexpr 5pt\relax
\newdimen\BLS % BorderLine Sep
\BLS\dimexpr 1pt\relax
\newdimen\BLLa % Gap'' between first and second line
\BLLa\dimexpr -\BLW/2-\BLS-(3\BLW/4)/2\relax

\newdimen\BLLb % between second and third line
\BLLb\dimexpr -\BLW/2-\BLS-(3\BLW/4)-\BLS-(9\BLW/16)/2 \relax

\newdimen\BLLc % between third and fourth line
\BLLc\dimexpr -\BLW/2-\BLS-(3\BLW/4) -\BLS-(9\BLW/16)-\BLS-(27\BLW/64)/2 \relax

\stop


But presumably your error is using arithmetic expressions in the width key, which is not interpreted by \dimexpr (and if it were interpreted the ^ would be a syntax error)

Your example isn't very minimal and you give no indication of the intended result so I can't suggest a change to that.