pdfcrop bounding box problem

[Alan Munn]

This is a ghostscript bug. Updating to the latest version (9.50) fixes
it.  Doe TL have a policy on how these sorts of updates are handled? As
I understand it, tlmgr doesn't update ghostscript, but MacTeX at least
installs v9.27.

Alan

Alan Munn wrote:
> Hi, the following document, processed with any engine, crops improperly.
> Perhaps this is a ghostscript problem, but I'll post it here in case
> anyone can figure it out.
>
> \documentclass{article}
> \pagestyle{empty}
> \begin{document}
> \shipout\vbox
> {\parbox{1.75in}{%
> \centering
> \raggedleft
> \vspace{.25in}\par\fontsize{11}{13}\selectfont
> Some Text\par\vspace{12pt}
> \fontsize{10}{12}\selectfont
> Some more text\par%
> \vspace{12pt}\fontsize{8}{10}\selectfont
> Even more text\par
> \vspace{10pt}
> Something else\par}
> }
> \end{document}
>
> The output of pdfcrop (TL 2019, running on a Mac).  David Carlisle also
> replicated this behaviour using cygwin.
>
> pdfcrop --verbose pdfcrop-mwe.pdf
> PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek.
> * PDF header: %PDF-1.5
> * Running ghostscript for BoundingBox calculation ...
> GPL Ghostscript 9.27 (2019-04-04)
> Copyright (C) 2018 Artifex Software, Inc.  All rights reserved.
> This software is supplied under the GNU AGPLv3 and comes with NO
> WARRANTY:
> see the file COPYING for details.
> Processing pages 1 through 1.
> Page 1
> %%BoundingBox: 139 624 210 695
> * Page 1: 139 624 210 695
> %%HiResBoundingBox: 139.805996 624.095981 209.519994 694.745979
> * Running pdfTeX ...
> This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019)
> (preloaded format=pdftex)
> entering extended mode
> (./tmp-pdfcrop-53360.tex [1 <./pdfcrop-mwe.pdf>] )
> Output written on tmp-pdfcrop-53360.pdf (1 page, 22476 bytes).
> Transcript written on tmp-pdfcrop-53360.log.
> ==> 1 page written on `pdfcrop-mwe-crop.pdf'.
>
>
>
>