# Arithmetic overflow error using bytefield package while attempting to constrain width

I'm attempting to draft a document that makes very heavy use of the bytefield package and running into the situation that it seems no good solution exists for fields that have to be 64 bits wide (even the documentation doesn't show such examples!). Without further ado, here's the result:

As you can see, the width of the 64-bit value drives off the page. I've attempted to constrain this with the optional bitwidth parameter as described in the documentation (such as following this answer's question to provide an argument of 0.8\textwidth, adjusting from there, but doing so generates an "Arithmetic overflow" error. Does anyone know how to constrain the width of the whole field itself, or at least force bytefield to produce a field that cannot be wider than the page itself?

Here is the code for the minimum working example:

\documentclass[10pt]{extreport}
\usepackage[margin=2.0cm,a4paper]{geometry}
\usepackage[utf8]{inputenc}
\usepackage{bytefield}

\begin{document}
\noindent
An \texttt{unsigned word} is defined as a 16-bit or two-octet quantity, having the range \texttt{[0, 65535]}: \\

\begin{center}
\begin{bytefield}[endianness=big]{16}
\bitbox{16}{\texttt{unsigned word}} \\
\end{bytefield}
\end{center}

An \texttt{unsigned word} is addressable as an 2-size array of bytes, where \texttt{byte[0]} corresponds to the most-significant byte in the word (the \textit{high byte}) and \texttt{byte[1]} corresponds to the least-significant byte in the word (the \textit{low byte}). \\

\vspace{5pt}
\hrule
\vspace{15pt}

\noindent
An \texttt{unsigned doubleword} is defined as a 32-bit or four-octet quantity, having the range \texttt{[0, 4294967295]}: \\

\begin{center}
\begin{bytefield}[endianness=big]{32}
\bitheader{31, 23, 15, 7, 0}                \\
\bitbox{32}{\texttt{unsigned doubleword}}   \\
\end{bytefield}
\end{center}

An \texttt{unsigned doubleword} is addressable as an 4-size array of bytes, where \texttt{byte[0]} corresponds to the most-significant byte in the doubleword (the \textit{high byte}) and \texttt{byte[3]} corresponds to the least-significant byte in the doubleword (the \textit{low byte}). \\

\vspace{5pt}
\hrule
\vspace{15pt}

\noindent
An \texttt{unsigned quadword} is defined as a 64-bit or eight-octet quantity, having the range \texttt{[0, 18446744073709551615]}: \\

\begin{center}
\begin{bytefield}[endianness=big]{64}
\bitheader{63, 55, 47, 39, 31, 23, 15, 7, 0}    \\
\end{bytefield}
\end{center}

An \texttt{unsigned quadword} is addressable as an 8-size array of bytes, where \texttt{byte[0]} corresponds to the most-significant byte in the quadword (the \textit{high byte}) and \texttt{byte[7]} corresponds to the least-significant byte in the quadword (the \textit{low byte}). \\
\end{document}


The non-working code that generates the error is as follows - wrapping it in curly braces does not alleviate the error:

\begin{center}
\begin{bytefield}[endianness=big, bitwidth=0.8\textwidth]{64}
\bitheader{63, 55, 47, 39, 31, 23, 15, 7, 0}    \\
\end{bytefield}
\end{center}


Also, word to the wise - I'm still (slowly) getting the ropes in TeX, so my skill for self-serving is still somewhat limited to "hunt online for solution, hope someone has implemented it"; you may have to help break a potential answer down for me a bit.

The environment in question, if it helps, is MacTex 2015 (TeXLive-2015); code was built using TeXstudio 2.10.4.

• bitwidth=0.015\textwidth seems more likely to work – egreg Feb 8 '16 at 19:16
• @egreg That did it! – ecfedele Feb 8 '16 at 19:17

You can try with \resizebox of package graphicx.

\documentclass[10pt]{extreport}
\usepackage[margin=2.0cm,a4paper]{geometry}
\usepackage[utf8]{inputenc}
\usepackage{bytefield}
\usepackage{graphicx}
\begin{document}
\noindent
An \texttt{unsigned word} is defined as a 16-bit or two-octet quantity, having the range \texttt{[0, 65535]}: \\

\begin{center}
\begin{bytefield}[endianness=big]{16}
\bitbox{16}{\texttt{unsigned word}} \\
\end{bytefield}
\end{center}

An \texttt{unsigned word} is addressable as an 2-size array of bytes, where \texttt{byte[0]} corresponds to the most-significant byte in the word (the \textit{high byte}) and \texttt{byte[1]} corresponds to the least-significant byte in the word (the \textit{low byte}). \\

\vspace{5pt}
\hrule
\vspace{15pt}

\noindent
An \texttt{unsigned doubleword} is defined as a 32-bit or four-octet quantity, having the range \texttt{[0, 4294967295]}: \\

\begin{center}
\begin{bytefield}[endianness=big]{32}
\bitheader{31, 23, 15, 7, 0}                \\
\bitbox{32}{\texttt{unsigned doubleword}}   \\
\end{bytefield}
\end{center}

An \texttt{unsigned doubleword} is addressable as an 4-size array of bytes, where \texttt{byte[0]} corresponds to the most-significant byte in the doubleword (the \textit{high byte}) and \texttt{byte[3]} corresponds to the least-significant byte in the doubleword (the \textit{low byte}). \\

\vspace{5pt}
\hrule
\vspace{15pt}

\noindent
An \texttt{unsigned quadword} is defined as a 64-bit or eight-octet quantity, having the range \texttt{[0, 18446744073709551615]}: \\

\begin{center}
\resizebox{1.0\linewidth}{\height}{\begin{bytefield}[endianness=big]{64}
\bitheader{63, 55, 47, 39, 31, 23, 15, 7, 0}    \\
\end{bytefield}}
\end{center}

An \texttt{unsigned quadword} is addressable as an 8-size array of bytes, where \texttt{byte[0]} corresponds to the most-significant byte in the quadword (the \textit{high byte}) and \texttt{byte[7]} corresponds to the least-significant byte in the quadword (the \textit{low byte}). \\
\end{document}


Else, keeping the same size:

\begin{center}
\centerline{\begin{bytefield}[endianness=big]{64}
\bitheader{63, 55, 47, 39, 31, 23, 15, 7, 0}    \\
\end{bytefield}}
\end{center}


although \centerline isn't the best of LaTeX commands. (but is is fine here, as the only thing in the center stuff).

## Update:

needed a bit of trial and error due to some surprising depth of the bytefield box. Also, it is not entirely clear to me why I have to reduce a tiny bit the width to avoid a vertical shift.

\begin{center}
\mbox{\resizebox{.9999\linewidth}{\height}{%
\begin{bytefield}[endianness=big]{64}
\bitheader{63, 55, 47, 39, 31, 23, 15, 7, 0}    \\
\bitbox{64}{}         \\
\end{bytefield}}%
\kern-\linewidth
}
\end{center}


• I like the first route, and it certainly solves the issue with the field itself, but is there a way to counteract the (noticeable) compression of the text? – ecfedele Feb 8 '16 at 19:15
• the need for .9999\width sounds like something fishy happening with \resizebox. – user4686 Feb 8 '16 at 20:07
• @DavidCarlisle \setbox0\hbox{\resizebox{\linewidth}{\height}{Hello}} \number\wd0 gives 31699616 (sp) but \number\linewidth returns 31699558 (sp). The former is bigger than the latter, which explains the need for the .9999 in my code above to avoid the vertical extra space. \number\linewidth – user4686 Feb 8 '16 at 20:13
• @DavidCarlisle looking quickly graphicx.dtx, \resizebox obtains ratios, then multiplies original lengths on the TeX side. If it kept memory of the user-specified width and/or height, last step of \Gscale@box could set the driver modified box to exactly the user desired TeX dimensions. Ratios #1=\Gscale@x, #2=\Gscale@y would serve the driver only, not the \Gscale@box last step. This would solve the \resizebox{\linewidth}{...}{stuff} constructing a box wider than \linewidth in some cases. Which in turn causes problems in a center environment due to \trivlist usage. – user4686 Feb 9 '16 at 8:40
• bug report here – user4686 Feb 9 '16 at 9:04

The width reserved for a bit has to be multiplied by the number of bits, so a figure like

bitwidth=0.015\textwidth


or less is more likely to work (option showframe just for the example):

\documentclass[10pt]{extreport}
\usepackage[margin=2.0cm,a4paper,showframe]{geometry}
\usepackage[utf8]{inputenc}
\usepackage{bytefield}

\begin{document}
An \texttt{unsigned quadword} is defined as a 64-bit or quantity, in the range
\texttt{[0, 18446744073709551615]}:
\begin{center}
\begin{bytefield}[endianness=big,bitwidth=0.015\textwidth]{64}
\bitheader{63, 55, 47, 39, 31, 23, 15, 7, 0}    \\