# High precision \includegraphics for LaTeX

\includegraphics produces boxes whose witdth and height are about 0.5pt off:

\usepackage{graphicx}
...
\setbox0\hbox{\includegraphics[width=\textwidth,height=\textheight]{mypic}}
\showthe\textheight
\showthe\ht0
\showthe\textwidth
\showthe\wd0


Is there a version of \includegraphics which can resize with higher precision? I'm using pdflatex.

FYI There is no rounding error if only width= or height= is specified, but if both are specified, then both are rounded incorrectly.

-
Didn't you write a package once that promised higher precision? –  Martin Schröder Dec 11 '11 at 21:33
I think the difference here stems from the fact that graphicx (or ultimately graphics) scales items in big points (bp) rather than some smaller length unit. –  Werner Dec 11 '11 at 21:38
@Werner: This is usually an issue but AFAIK its an rounding issue in the graphic/x code. –  Martin Scharrer Dec 11 '11 at 21:51
@Martin Schröder: I can't use my package right now, because it doesn't support all options of \includegraphics I need. –  pts Dec 12 '11 at 22:51

The height and width options and the related \resizebox actually calculate a scale factor and then use some internal form of \scalebox to do the scaling. Because this calculation requires a division (which is implemented using a loop in graphic/x) a numeric error is introduced. The size of the error depends on the original and requested size. If the scale factor is an integer there is no error. The equation is (IIRC) like follows:

(requested size / original size) * original size ~ requested size


Where the (..) factor suffers unfortunately from the limited resolution of TeX.
(~ = approximately)

Also the actually scaling is done by the driver or the output format itself, i.e. the image is added to the PDF as it is and the viewer does the scaling as ordered. I don't think you can get a smaller error. I myself tried other ways for the division and didn't got a better precision.

In order to have an official size in TeX a box with the given size is inserted. Unfortunately graphic/x takes the calculated scale factor to produce the box, not the requested width and height. It would be possible to rewrite the code to do it differently, then the image should still have the same size as before in the PDF viewer but the official TeX size would be "correct", i.e. as requested. This could be done by simple setting the width and height explicitly to the requested sizes. I did some research and work in this direction for my adjustbox package, which is based on graphicx. However, I didn't dared patching graphics/x so far to not risk any hidden comparabilities etc.

You could also check the PDF standard if it is possible to include the scaled image with the given requested size (converted to bp) instead of a scale factor, and then rewrite the pdftex driver accordantly.

-

The expl3 'native' driver code offers one way to get higher precision. At present, that code doesn't have graphics inclusion, so the set up requires first inclusion of the image unscaled into a box, followed by a scaling:

\documentclass{article}
\usepackage{graphicx}
\usepackage[native-drivers]{expl3}
\ExplSyntaxOn
\cs_new_eq:NN \ResizeBox \box_resize:Nnn
\ExplSyntaxOff
\newbox{\mybox}
\begin{document}
% Image from mwe bundle
\setbox\mybox\hbox{\includegraphics{example-image-a}}
\ResizeBox\mybox{\textwidth}{\textheight}
\showthe\textheight
\showthe\ht\mybox
\showthe\textwidth
\showthe\wd\mybox
\end{document}


Here, I get a final width of exactly 345 pt, with the height out very slightly: 550.00113 pt. As Martin observes in his answer, this comes down to the fact that resizing an item is done by the driver itself as a scaling (\pdfsetmatrix primitive with a recent-ish pdfTeX). Thus the final size is the closes that TeX can get to the scale factor times the original size, rather than being the absolute value given. With a sufficiently 'good' FPU (as in expl3) the difference is small but non-zero.

-