The input file is a tall rectangle with a cross, i.e., a tall version of ☒ or ⛝, as shown by `loupe input.png` or `gimp input.png`.  The file was originally produced by processing in GIMP a page scanned with scanimage.

Run

     convert input.png output.pdf

or

     magick input.png output.pdf

followed by `evince output.pdf` or `mupdf output.pdf`. Observe that in the output, you get additional white stripes at the top and to the right.

The same goes when you specify the options `-compress JPEG2000 -quality 50` to `convert`.

This is surprising; compare this to what you get when the input is https://www.debian.org/logos/openlogo-100.png .  From a user's viewpoint, the aforementioned tools produce inconsistent results, so at least one of them should be improved (feel free to reassign if necessary).

Moreover, the generated image seems to have more points than there are pixels in the original:

     $ file input.png
     input.png: PNG image data, 9591 x 13758, 8-bit grayscale, non-interlaced
     $ pdfinfo output.pdf | grep "Page size"
     Page size:       10206 x 14036 pts

(Off-topic: I also have an uncleaned scanned and processed page, which I choose to keep nondisclosed here, that shows an even worse error.)

Gratefully,
Peter

It turned out that the caNv chunk in the PNG file is the culprit. No idea which tools exactly introduced it, but it's likely to be scanimage, GIMP, or pngcrush. Attached is a slightly smaller input.png file (I removed the gAMA chunk) and the corresponding output.pdf resulting from `convert input.png output.pdf`.

Imagemagick contains a tool that can show both PNG and PDF files, namely, display.  I expect that a simple conversion from PNG to PDF doesn't change the visual appearance in the same tool, so `display input.png` and `display output.pdf` should either both show the stripes or both ignore the stripes.

As for conversion, I don't know how to handle this exactly, but if you ask me, the default action during `convert input.png output.pdf` should probably be to follow the standard and ignore private ancillary chunks such as caNv unless some command-line option or some non-default configuration option says otherwise.

retitle 1115346 Lower bottom is cut away, and empty space added to the top right when converting PNG to PDF
affects 1115346 + pngtools libimage-exiftool-perl pngcheck
severity 1115346 important
quit


Consider test.png in the attachment. Open it with loupe, display, or eog, and you'll see a cross in a rectangle, and there is nothing outside the rectangle. We see nothing unusual so far:

$ pnginfo test.png
test.png...
   Image Width: 100 Image Length: 166
   Bitdepth (Bits/Sample): 8
   Channels (Samples/Pixel): 1
   Pixel depth (Pixel Depth): 8
   Colour Type (Photometric Interpretation): GRAYSCALE
   Image filter: Single row per byte filter
   Interlacing: No interlacing
   Compression Scheme: Deflate method 8, 32k window
   Resolution: (not specified)
   FillOrder: msb-to-lsb
   Byte Order: Network (Big Endian)
   Number of text strings: 0
$ exiftool -a -G test.png
[ExifTool]      ExifTool Version Number         : 13.25
[File]          File Name                       : test.png
[File]          Directory                       : .
[File]          File Size                       : 493 bytes
[File]          File Modification Date/Time     : 2026:06:02 08:02:41+02:00
[File]          File Access Date/Time           : 2026:06:02 08:05:45+02:00
[File]          File Inode Change Date/Time     : 2026:06:02 08:03:31+02:00
[File]          File Permissions                : -rw-rw-r--
[File]          File Type                       : PNG
[File]          File Type Extension             : png
[File]          MIME Type                       : image/png
[PNG]           Image Width                     : 100
[PNG]           Image Height                    : 166
[PNG]           Bit Depth                       : 8
[PNG]           Color Type                      : Grayscale
[PNG]           Compression                     : Deflate/Inflate
[PNG]           Filter                          : Adaptive
[PNG]           Interlace                       : Noninterlaced
[Composite]     Image Size                      : 100x166
[Composite]     Megapixels                      : 0.017
$ file test.png
test.png: PNG image data, 100 x 166, 8-bit grayscale, non-interlaced
$ pngcheck test.png
zlib warning:  different version (expected 1.2.13, using 1.3.1)

OK: test.png (100x166, 8-bit grayscale, non-interlaced, 97.0%).


Now run

magick test.png test.pdf

or

convert test.png test.pdf

followed by

$ pdfinfo test.pdf
Title:           test
Author:          https://imagemagick.org
Creator:         https://imagemagick.org
Producer:        https://imagemagick.org
CreationDate:    Tue Jun  2 07:46:05 2026 CEST
ModDate:         Tue Jun  2 07:46:05 2026 CEST
Custom Metadata: no
Metadata Stream: no
Tagged:          no
UserProperties:  no
Suspects:        no
Form:            none
JavaScript:      no
Pages:           1
Encrypted:       no
Page size:       3964 x 6509 pts
Page rot:        0
File size:       3111 bytes
Optimized:       no
PDF version:     1.3

The page size of the PDF file is now huge. However, for the original PNG file, it was not reported by `pnginfo`, `exiftool`, `pngcheck`, or `file`, and it was not noticeable in any of the three image viewers.

Open test.pdf in evince, and observe lots of free space to the right and above the rectangle with a cross. Also, the lower left part of the rectangle with a cross is missing. Clearly, this is not intended. We expect that the target PDF is visibly the same as the original PNG. If a clean conversion cannot be done or doesn't make sense, an error should be reported or the user should be warned at the very least.

In retrospect, we found caNv to be the culprit. No idea which tool added this.

Raising severity as this bug silently makes your life hard: you don't notice that your original PNG files are unusual until after the conversion to a PDF. It's even worse: the target PDF might have only few columns/lines missing on the left/bottom, and it might have only few white lines/columns added to the top/right; these are hard to see, and the wrong PDF might even get shipped to the receiver before you notice this error (if ever).

It turned out that in my workflows, rotation by a nontrivial angle (e.g., strictly between 0 and 90) introduces a caNv chunk, and a subsequent conversion to PDF (but not to many other formats, say, JPG, JPEG2000, GIF, or TIFF) exposes the havoc.  E.g., grab https://www.debian.org/logos/openlogo-100.png and run

     magick openlogo-100.png -rotate 10 openlogo-100.rotated.png
     magick openlogo-100.rotated.png openlogo-100.rotated.pdf

In openlogo-100.rotated.pdf, the stuff in the bottom left is cut away, and white margins on the top and right are added.

The issue is exacerbated by the fact that if you open file.rotated.png in GIMP, crop the image (Shift+C) to a smaller size, resize the layers to the size of the image, and export the result, you get exactly the same caNv chunk in the exported PNG. The tools don't warn you about the contamination during all the operations with magick and GIMP (and probably more tools, as the chunk is safe to copy by the PNG specification). You only notice the mayhem quite late, when viewing the final PDF—if you're lucky.

As caNv is nonstandard, I suggest both skipping this poison during rotation and ignoring it during conversion to PDF by default (i.e., unless an extra switch or extra switches requests it).

… or extra switches requests it
→
… or extra switches request it

---

In the long run, if caNv is deemed useful, it could be suggested for inclusion into the PNG standard with a well-defined, well-specified, and standalone semantics so that other tools, such as GIMP, can handle it properly in all kinds of image processing (e.g., drop the chunk from the file when it stops making sense). If caNv can't be formalized properly in a standalone way, the chunk should be forgotten forever.