samcarter
> *Background story: As I recently needed to replace my goto tool `sips` because of a bug in macOS 13, I thought I'd post the results of my tests here in case others face a similar problem*
Let's assume one has a TikZ drawing with pattern, shadings and transparency. Which tools can be used to convert the resulting PDF to PNG?
Test file:
```
\documentclass{standalone}
\usepackage{tikzducks}
\definecolor{dblue}{RGB}{41,38,66}
\definecolor{dred}{RGB}{255,90,85}
\usetikzlibrary{patterns.meta}
\tikzdeclarepattern{
name=myStars,
type=uncolored,
bounding box={(-2pt,-2pt) and (2pt,2pt)},
tile size={(\tikztilesize,\tikztilesize)},
parameters={\tikzstarpoints,\tikzstarradius,\tikzstarrotate,\tikztilesize},
tile transformation={rotate=\tikzstarrotate},
defaults={
points/.store in=\tikzstarpoints,points=5,
radius/.store in=\tikzstarradius,radius=1pt,
rotate/.store in=\tikzstarrotate,rotate=0,
tile size/.store in=\tikztilesize,tile size=3pt,
}, code={
\pgfmathparse{180/\tikzstarpoints}\let\a=\pgfmathresult
\fill (90:\tikzstarradius) \foreach \i in {1,...,\tikzstarpoints}{
-- (90+2*\i*\a-\a:\tikzstarradius/2) -- (90+2*\i*\a:\tikzstarradius)
} -- cycle;
} }
\begin{document}
\begin{tikzpicture}
\duck[
parrot,
bill=gray!80!black
]
% wing
\path (0.1,0.1) rectangle (2.1,2.4);
\begin{pgfinterruptboundingbox}
\shade[bottom color=yellow!70!brown, top color=green!40!teal] \duckpathcrazyhair;
\end{pgfinterruptboundingbox}
\begin{pgfinterruptboundingbox}
\path[pattern=myStars,pattern color=blue] \duckpathtshirt;
\end{pgfinterruptboundingbox}
\fill[red,opacity=0.3] (0,0) circle [radius=1cm];
\end{tikzpicture}
\end{document}
```
Top Answer
samcarter
# xpdf
```
pdftopng -r 150 -alpha document.pdf test_xpdf
```
- transparent background
- shading works fine
- the pattern is visible, although a tiny bit shifted to what my pdf viewer would show me (no idea which of both is right...)
# ImageMagick
```
magick -density 1000 document.pdf +antialias -interpolate Nearest -resample 150 test_imagemagick.png
```
- transparent background
- shading works fine
- pattern looks the same as in pdf viewer
- memory usage can be pretty high if the pdf has many pages. It seems that first all pdf pages are read in and at the end all pngs are created. This is what I currently use for smaller documents.
# inkscape
```
inkscape --export-type=png --export-filename=test_inkscape --export-overwrite --export-dpi=150 document.pdf
```
- transparent background
- shading missing
- pattern in wrong size
(... but there are a lot of options, maybe I did not look hard enough to find the holy grail...)
# poppler
```
pdftoppm -png -r 150 document.pdf test_poppler
```
- no transparent background
- shading works fine
- pattern looks the same as in my pdf viewer
- memory usage seems to be lower for multi-page pdfs compared to ImageMagick, each page seems to be processed after another. This is what I use to convert the pdfs of the Xmas extravaganzas to png.
# MacOS
MacOS comes with the build in command line tool `sips`. Note that in macOS 13, it had some bug and would throw an error when trying to produce pngs. It works again in macOS 14.
```
sips -s format png document.pdf --out test_mac.png
```
In the macOS 14 version:
- no transparent background
- shading works fine
- pattern seems to work (as far as one can see)
- changing the image resolution does not seem to work atm
Answer #2
frougon
# Using the `gegl` command-line tool
This tool is based on the [GEGL](https://www.gegl.org/) library that current [GIMP](https://www.gimp.org/) is based on. GEGL allows one to apply a sequence of image processing operations described by a [directed acyclic graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph) in which nodes represent images and edges represent operations.
As far as I understand it, general graph input is normally provided in XML format, however the [`gegl` command-line tool](https://www.gegl.org/commandline.html) supports a [special syntax](https://www.gegl.org/gegl-chain.html) after the optional `--` argument that allows one to describe chains of operations as one-liners. Using this special syntax, one can perform the conversion (the `gegl:` prefixes may be omitted):
```
gegl -- gegl:pdf-load path=docu.pdf page=1 ppi=300 gegl:png-save path=docu.png compression=9
```
This works, except one gets an opaque white background instead of a transparent one. After applying the following patch to the [GEGL source](https://gitlab.gnome.org/GNOME/gegl/-/blob/master/operations/external/pdf-load.c):
```
--- a/operations/external/pdf-load.c
+++ b/operations/external/pdf-load.c
@@ -187,7 +187,7 @@
cairo_t *cr;
surface = cairo_image_surface_create (CAIRO_FORMAT_ARGB32, p->width, p->height);
cr = cairo_create (surface);
- cairo_set_source_rgb (cr, 1,1,1);
+ cairo_set_source_rgba (cr, 0.0, 0.0, 0.0, 0.0);
cairo_paint (cr);
cairo_scale (cr, p->scale, p->scale);
```
then everything works as expected (transparency, pattern, shading):
The report and patch have been filed as [GEGL issue #344](https://gitlab.gnome.org/GNOME/gegl/-/issues/344).
## Parameters allowed in the above operations
- Loading from PDF: [gegl:pdf-load](https://www.gegl.org/operations/gegl-pdf-load.html);
- Saving to PNG: [gegl:png-save](https://www.gegl.org/operations/gegl-png-save.html).
Answer #3
Skillmon
# Cairo (poppler-cairo to be precise[^1])
```sh
pdftocairo -png -r 150 document.pdf test_cairo
```
For transparent background:
```sh
pdftocairo -png -r 150 -transp document.pdf test_cairo
```
(Comparing with Zathura with MuPDF-backend as PDF-viewer):
- the colours seem a bit more saturated/darker without the transparent background
- transparency works fine (option for transparent background for PNG and TIFF files)
- pattern looks fine
- multiple pages supported, no idea about performance/memory usage
[^1]: `pdftoppm` uses poppler-splash, see https://poppler.freedesktop.narkive.com/SXaTfjEx/pdftoppm-vs-pdftocairo
# MuTool (part of MuPDF)
There are two subcommands that lead to slightly different results
1. `mutool draw`
```sh
mutool draw -o test_mupdf_draw.png -c rgba -r 150 document.pdf
```
- transparent background (don't forget `rgba`, without it you don't get transparent backgrounds)
- shading works
- pattern supported (looks like in my MuPDF-based PDF-viewer... took a close look at 600dpi resolution, on low resolutions the pattern placement looks off)
2. `mutool convert`
```sh
mutool convert -o test_mupdf_convert.png -O resolution=150,alpha document.pdf
```
- transparent background (thanks to the `alpha` key)
- shading works
- pattern placed slightly off, it seems (took a close look at 600dpi resolution, worse on low resolutions)
- silently appends page number if you omit `%d` in the output file name to support multi-page documents (even if the document is single page)
For both the manpage in Arch Linux is incomplete (found the `alpha` key by the error message when I input some wrong syntax for the `convert` subcommand), same is true (and even worse) for `--help` (but the error message shows then very much information upon an unknown option!)