# White line at edge of black 16:9 PDF

If I create a PDF with a 16:9 aspect ratio (e.g. for viewing via video projector) with a black background, I get a phantom white line at its bottom edge when I convert it to an image.

Here is minimal code to see this:

\documentclass{article}
\usepackage[papersize={160mm,90mm}]{geometry}
\usepackage{color}
\pagecolor{black}
\begin{document}
\null
\end{document}


Compile this via pdflatex or XeTeX, then:

pdftoppm test.pdf img


The result is a black image white a one pixel white line at the bottom.

I can get rid of this line by setting a slightly different papersize, e.g.:

\usepackage[papersize={159.8mm,89.85mm}]{geometry}


I also can get rid of this if I use a 4:3 aspect ratio, e.g.:

\usepackage[screen]{geometry}


Is there a way to get rid of this line besides fudging papersize, asking pdftoppm to crop the page, or cropping afterward in Imagemagick? E.g. via making a black background rectangle on each page which is slightly larger than the paper size? And is the underlying problem a TeX rounding error or something to do with PDF output? Is there a way to directly set the background of a PDF document to black, not white, rather than working via pagecolor?

The goal here is to generate 1920x1080 viewable images from TeX via, say:

pdftoppm -scale-to-x 1920 -scale-to-y -1 -png test.pdf img


I'd also be happy to learn a better way to produce screen output for pages with dark backgrounds. I got into this because when I view 16:9 PDFs generated this way in Preview via Slideshow mode, I see a distracting white border around dark pages. (I don't see this in Acrobat.) In trying to work around that by creating an image for each page, I ran to the pdftoppm problem.

The only related question I can find: Beamer frames show a white line on top

• Welcome! Converting them to raster images seems wrong-headed to me. White lines aside, this is going to degrade quality very significantly, so that zooming etc. will no longer render clean characters, for example. In Preview, with the original PDF, does zooming make the line disappear? If so, it is a viewer artefact and nothing about the PDF itself. (That Acrobat doesn't show it already suggests this.)
– cfr
Mar 12 '18 at 4:21
• Hi @cfr and thank you! I can only see the edge lines in Preview in Fullscreen or Slideshow, and can't zoom in on them in either case, due to the Preview GUI. I do agree, this is a deeply perverse course of action to make one-time images via pdftoppm (essentially post-processing a PDF for a particular viewing environment). There may be two issues -- quirky viewing software, but also the line I see in pdftoppm is undeniably there in the resulting ppm! Mar 12 '18 at 4:32
• One other clue: identify -verbose test.pdf|grep -i color shows Background color: white. This suggests to me that TeX is generating a white page then drawing black over it, maybe not all the way to the edges? But then I also see Border color: srgba(223,223,223,1), which is confusing. It could be the abstraction of PDF as page breaks down when used as a black background for the screen. Mar 12 '18 at 4:55

The page color is a rectangle drawn on the page. It is already a bit larger than the mediabox but only to the right and the top. At the left and bottom it begins like the media box exactly at zero. And the conversion then seems to introduce some rounding error which gives a white line.

I don't see any reason why the rectangle shouldn't be a bit larger to the other sides too. This here seems to work fine (with pdflatex!) and the white line disappears. If it works for you you could make a feature request.

\documentclass{article}
\usepackage[papersize={160mm,90mm}]{geometry}
\usepackage{color}
\makeatletter %copied from pdftex.def:
\begingroup\expandafter\expandafter\expandafter\endgroup
\expandafter\ifx\csname currentgrouplevel\endcsname\relax
\catcodeX=9  % ignore
\catcodeE=14 % comment
\else
\catcodeX=14 % comment
\catcodeE=9  % ignore
\fi

\def\set@page@color{%
\global\GPT@pagecolortrue
\global\let\current@page@color\current@color
\@ifundefined{GPT@outputbox}{%
% \newbox is outer in plain
\csname newbox\endcsname\GPT@outputbox
}{}%
\@ifundefined{GPTorg@shipout}{%
\global\let\GPTorg@shipout\shipout
\gdef\shipout{%
X     % ensure \GPT@outputbox is really void
X     \begingroup
X       \setbox\GPT@outputbox=\box\GPT@outputbox
X     \endgroup
E     \edef\GPT@saved@grouplevel{\number\currentgrouplevel}%
\afterassignment\GPT@shipout
\global\setbox\GPT@outputbox=%
}%
\gdef\GPT@shipout{%
X     \ifvoid\GPT@outputbox\relax
E     \ifnum\GPT@saved@grouplevel=\currentgrouplevel
E     \else
\expandafter\aftergroup
\fi
\GPT@@shipout
}%
\gdef\GPT@@shipout{%
\ifvoid\GPT@outputbox\relax
\PackageInfo{pdftex.def}{Ignoring void output box}%
\else
\setbox\GPT@outputbox=\vbox{%
\GPT@pageliteral
\box\GPT@outputbox
}%
\GPTorg@shipout\box\GPT@outputbox\relax
\fi
}%
\gdef\GPT@pageliteral{%
\ifGPT@pagecolor
\pdfliteral page{%
q % gsave
\current@page@color\GPT@space
n % newpath
-1 -1 \strip@pt\pdfpagewidth\GPT@space
\strip@pt\pdfpageheight\GPT@space re % rectangle
% there is no need to convert to bp
f % fill
Q% grestore
}%
\fi
}%
}{}%
}
\catcode\X=11 %
\catcode\E=11 %

\pagecolor{black}

\begin{document}
\null
\end{document}

• The size of the rectangle is still the same. The PDF operator re uses a point and the size as arguments unlike the TikZ operator rectangle that takes two diagonal points. Thus, the size of the rectangle needs to be increased for small sizes. Mar 12 '18 at 19:00
• @HeikoOberdiek I didn't know this, so one will have to change the size e.g. with \strip@pt\dimexpr\pdfpagewidth+1pt\relax to compensate. Mar 13 '18 at 8:02
• Except that \dimexpr is not always available. Mar 13 '18 at 17:19
• @HeikoOberdiek isn't etex now required anyway? Mar 13 '18 at 20:06
• No, pdftex.def can even be used with plain TeX formats. Since it is a basic driver file, it should be as compatible as possible. Mar 13 '18 at 20:07