for (pkg in c("ggplot2")) {
  if (!require(pkg, character.only = TRUE)) install.packages(pkg)
}

In den vorherigen Kapiteln haben wir Plots erstellt, die im RStudio-Vorschaufenster gut aussahen. Aber die Vorschau ist trügerisch: Sie passt jeden Plot an die aktuelle Fenstergröße an, sodass Schriften, Linienstärken und Abstände sich bei jeder Größenänderung des Fensters mitändern. Ein Plot, der in einem breiten Fenster ausgewogen wirkt, kann in einem schmalen Fenster übergroßen Text haben - oder umgekehrt. Für reproduzierbare, publikationsreife Ausgaben muss man in einer festen Größe und Auflösung exportieren.

Dieses Kapitel behandelt zwei Werkzeuge dafür: ggsave() für den direkten Dateiexport und das {camcorder}-Paket für einen WYSIWYG-Vorschau-Workflow. Beide lösen dasselbe grundlegende Problem - das Canvas-Problem.

Das Canvas-Problem

Um zu verstehen, warum Exportabmessungen wichtig sind, betrachten wir folgende Demonstration. Wir erstellen einen einfachen PlantGrowth-Plot und rendern ihn bei zwei sehr unterschiedlichen Canvas-Größen:

p <- ggplot(PlantGrowth, aes(x = group, y = weight)) +
  geom_point() +
  labs(title = "Plant Growth Experiment") +
  theme_minimal()

Bei einem sehr kleinen Canvas (3 x 1 Zoll) dominieren Textelemente den Plot und die Daten sind kaum sichtbar:

Bei einem größeren Canvas (8 x 6 Zoll) hat derselbe Plot viel Platz, aber der Text erscheint proportional winzig:

Der Code ist identisch - nur die Canvas-Größe hat sich geändert. Das ist die zentrale Erkenntnis: Text- und Geom-Größen in ggplot2 sind absolut (gemessen in Punkten oder Millimetern), während das Canvas relativ ist. Ein 12pt-Titel nimmt denselben physischen Platz ein, egal ob der Plot 3 Zoll oder 8 Zoll breit ist. Auf einem kleinen Canvas füllt 12pt-Text den größten Teil der Fläche; auf einem großen Canvas wirkt er wie eine Fußnote.

Das bedeutet, dass die “richtige” Schriftgröße, Linienstärke und Punktgröße alle von den Exportabmessungen abhängen. Ein Plot, der für eine ganzseitige Journal-Abbildung (7 x 5 Zoll) gestaltet wurde, sieht in einer Präsentationsfolie (10 x 5.6 Zoll) falsch aus - und beides sieht im RStudio-Vorschaufenster falsch aus, das keine der beiden Dimensionen hat.

Die Vorschau ist nicht die Ausgabe

Das RStudio/Positron Plots-Panel skaliert jeden Plot auf die aktuelle Fenstergröße. Das ist praktisch zum Explorieren, aber irreführend für die finale Ausgabe. Man sollte immer die exportierte Datei (PNG, PDF etc.) prüfen, nicht die Vorschau.

ggsave

Die ggsave()-Funktion exportiert einen ggplot in eine Datei mit voller Kontrolle über Abmessungen und Auflösung:

ggsave(
  filename = "my_plot.png",
  plot = p,
  width = 6,
  height = 4,
  units = "in",
  dpi = 300
)

Die wichtigsten Argumente sind:

filename: Ausgabepfad. Die Dateiendung bestimmt das Format (.png, .pdf, .svg, .jpg etc.)
plot: Das ggplot-Objekt. Wenn weggelassen, speichert ggsave() den zuletzt angezeigten Plot
width und height: Canvas-Abmessungen
units: "in" (Zoll), "cm", "mm" oder "px"
dpi: Auflösung in Dots per Inch. 300 ist Standard für Druck, 150 für Bildschirm, 72 für schnelle Vorschauen
scale: Multiplikator für die Canvas-Größe. scale = 2 verdoppelt alle Dimensionen, was die relative Größe von Text und Punkten effektiv halbiert
bg: Hintergrundfarbe. Default ist NULL, das heißt der Export übernimmt den plot.background des Plots selbst (weiß im Standard-Theme, aber transparent oder farbig, falls das Theme es so setzt). Das kann überraschen, wenn ein Plot am Bildschirm gut aussieht, in Folien oder PDFs aber einen unerwarteten Hintergrund zeigt. Für Raster-Ausgaben in Präsentationen explizit bg = "white" setzen.
device: Grafik-Device. Für PNG-Ausgabe liefert device = ragg::agg_png (aus dem {ragg}-Paket) schärferen Text und besseres Font-Rendering als der Default - besonders mit showtext oder Nicht-Standard-Fonts.

Gängige Exportgrößen

Einige typische Dimensionskombinationen:

Anwendungsfall	Breite	Höhe	DPI
Journal-Abbildung (einspaltig)	3.5 in	3 in	300
Journal-Abbildung (volle Breite)	7 in	5 in	300
Präsentationsfolie (16:9)	10 in	5.6 in	150
Poster-Panel	8 in	6 in	300
Web/Blog	8 in	5 in	150

Ein typischer Workflow ist iterativ: Exportieren, Datei öffnen, prüfen ob Textgrößen und Abstände passen, width/height oder theme(base_size = ...) anpassen, erneut exportieren. Diese Schleife ist effektiv, aber mühsam - und genau hier hilft camcorder.

Die Export-Prüf-Schleife beschleunigen

Zwei Tricks machen den iterativen Prüfzyklus schneller:

Die Datei direkt aus R öffnen mit shell.exec("my_plot.png") (Windows) oder browseURL("my_plot.png") (plattformübergreifend). Das spart den manuellen Schritt, die Datei im Dateimanager zu suchen.
Während der Entwicklung als PDF exportieren und in einem Viewer öffnen, der die Datei nicht sperrt. Sumatra PDF (Windows, kostenlos) lädt die Datei automatisch neu, sobald sie sich auf der Festplatte ändert - man kann ggsave() erneut ausführen und sieht den aktualisierten Plot sofort, ohne ihn schließen und neu öffnen zu müssen. Adobe Acrobat hingegen sperrt die Datei während sie geöffnet ist, sodass ggsave() mit einem “Datei wird verwendet”-Fehler fehlschlägt.

Das camcorder-Paket

Das {camcorder}-Paket verfolgt einen anderen Ansatz: Anstatt zu exportieren und zu prüfen, fixiert es die RStudio-Viewer-Leinwand auf die exakten Exportabmessungen, bevor man mit dem Plotten beginnt. So stimmt die Vorschau mit dem Export überein - man sieht, was man bekommt.

camcorder::gg_record(
  device = "png",
  width = 6,
  height = 4,
  units = "in",
  dpi = 300
)

Nach einmaligem Ausführen von gg_record() zu Beginn einer Session wird jeder nachfolgende Plot im Viewer exakt mit 6 x 4 Zoll und 300 dpi gerendert. Die Abmessungen bleiben fest, unabhängig von der Fenstergröße. Man kann dann am Plot-Code iterieren - Schriftgrößen anpassen, Ränder justieren, Legendenpositionen ändern - und das Ergebnis in Echtzeit in der finalen Exportgröße sehen.

Wenn man fertig ist, speichert gg_record() auch eine Aufzeichnung jeder Plot-Version, die sich in ein animiertes GIF der Plot-Entwicklung verwandeln lässt:

camcorder::gg_playback(
  name = "plot_development.gif",
  first_image_duration = 3,
  last_image_duration = 8,
  frame_duration = 0.5
)

ggsave vs. camcorder

Beide Werkzeuge lösen das Canvas-Problem, aber auf unterschiedliche Weise:

ggsave() ist eine einmalige Export-Funktion - Plot gestalten, dann exportieren. Am besten für schnelle Exports und geskriptete Pipelines.
camcorder ist eine sitzungsweite Vorschau-Fixierung - Canvas zuerst fixieren, dann gestalten. Am besten für interaktive Entwicklung, bei der man iterativ an der Ästhetik arbeitet.

In der Praxis nutzen viele camcorder während der Entwicklung und ggsave() in finalen Skripten.

Zitat

Mit BibTeX zitieren:

@online{schmidt2026,
  author = {{Dr. Paul Schmidt}},
  publisher = {BioMath GmbH},
  title = {4. Export und Canvas},
  date = {2026-08-13},
  url = {https://biomathcontent.netlify.app/de/content/ggplot2/04_export_canvas.html},
  langid = {de}
}

Bitte zitieren Sie diese Arbeit als:

Dr. Paul Schmidt. 2026. “4. Export und Canvas.” BioMath GmbH. August 13, 2026. https://biomathcontent.netlify.app/de/content/ggplot2/04_export_canvas.html.

--- title: "4. Export und Canvas" subtitle: "Plotgrößen kontrollieren mit ggsave und camcorder" --- ```{r} #| label: export-packages #| message: false #| warning: false for (pkg in c("ggplot2")) { if (!require(pkg, character.only = TRUE)) install.packages(pkg) } ``` In den vorherigen Kapiteln haben wir Plots erstellt, die im RStudio-Vorschaufenster gut aussahen. Aber die Vorschau ist trügerisch: Sie passt jeden Plot an die aktuelle Fenstergröße an, sodass Schriften, Linienstärken und Abstände sich bei jeder Größenänderung des Fensters mitändern. Ein Plot, der in einem breiten Fenster ausgewogen wirkt, kann in einem schmalen Fenster übergroßen Text haben - oder umgekehrt. Für reproduzierbare, publikationsreife Ausgaben muss man in einer festen Größe und Auflösung exportieren. Dieses Kapitel behandelt zwei Werkzeuge dafür: `ggsave()` für den direkten Dateiexport und das [{camcorder}](https://thebioengineer.github.io/camcorder/)-Paket für einen WYSIWYG-Vorschau-Workflow. Beide lösen dasselbe grundlegende Problem - das **Canvas-Problem**. # Das Canvas-Problem Um zu verstehen, warum Exportabmessungen wichtig sind, betrachten wir folgende Demonstration. Wir erstellen einen einfachen `PlantGrowth`-Plot und rendern ihn bei zwei sehr unterschiedlichen Canvas-Größen: ```{r} #| label: export-base-plot p <- ggplot(PlantGrowth, aes(x = group, y = weight)) + geom_point() + labs(title = "Plant Growth Experiment") + theme_minimal() ``` Bei einem sehr kleinen Canvas (3 x 1 Zoll) dominieren Textelemente den Plot und die Daten sind kaum sichtbar: ```{r} #| label: export-canvas-small #| fig-width: 3 #| fig-height: 1 p ``` Bei einem größeren Canvas (8 x 6 Zoll) hat derselbe Plot viel Platz, aber der Text erscheint proportional winzig: ```{r} #| label: export-canvas-large #| fig-width: 8 #| fig-height: 6 p ``` Der Code ist identisch - nur die Canvas-Größe hat sich geändert. Das ist die zentrale Erkenntnis: **Text- und Geom-Größen in ggplot2 sind absolut (gemessen in Punkten oder Millimetern), während das Canvas relativ ist.** Ein 12pt-Titel nimmt denselben physischen Platz ein, egal ob der Plot 3 Zoll oder 8 Zoll breit ist. Auf einem kleinen Canvas füllt 12pt-Text den größten Teil der Fläche; auf einem großen Canvas wirkt er wie eine Fußnote. Das bedeutet, dass die "richtige" Schriftgröße, Linienstärke und Punktgröße alle von den Exportabmessungen abhängen. Ein Plot, der für eine ganzseitige Journal-Abbildung (7 x 5 Zoll) gestaltet wurde, sieht in einer Präsentationsfolie (10 x 5.6 Zoll) falsch aus - und beides sieht im RStudio-Vorschaufenster falsch aus, das keine der beiden Dimensionen hat. :::{.callout-important} ## Die Vorschau ist nicht die Ausgabe Das RStudio/Positron Plots-Panel skaliert jeden Plot auf die aktuelle Fenstergröße. Das ist praktisch zum Explorieren, aber irreführend für die finale Ausgabe. Man sollte immer die exportierte Datei (PNG, PDF etc.) prüfen, nicht die Vorschau. ::: # ggsave Die `ggsave()`-Funktion exportiert einen ggplot in eine Datei mit voller Kontrolle über Abmessungen und Auflösung: ```{r} #| label: export-ggsave #| eval: false ggsave( filename = "my_plot.png", plot = p, width = 6, height = 4, units = "in", dpi = 300 ) ``` Die wichtigsten Argumente sind: - **`filename`**: Ausgabepfad. Die Dateiendung bestimmt das Format (`.png`, `.pdf`, `.svg`, `.jpg` etc.) - **`plot`**: Das ggplot-Objekt. Wenn weggelassen, speichert `ggsave()` den zuletzt angezeigten Plot - **`width`** und **`height`**: Canvas-Abmessungen - **`units`**: `"in"` (Zoll), `"cm"`, `"mm"` oder `"px"` - **`dpi`**: Auflösung in Dots per Inch. 300 ist Standard für Druck, 150 für Bildschirm, 72 für schnelle Vorschauen - **`scale`**: Multiplikator für die Canvas-Größe. `scale = 2` verdoppelt alle Dimensionen, was die relative Größe von Text und Punkten effektiv halbiert - **`bg`**: Hintergrundfarbe. Default ist `NULL`, das heißt der Export übernimmt den `plot.background` des Plots selbst (weiß im Standard-Theme, aber transparent oder farbig, falls das Theme es so setzt). Das kann überraschen, wenn ein Plot am Bildschirm gut aussieht, in Folien oder PDFs aber einen unerwarteten Hintergrund zeigt. Für Raster-Ausgaben in Präsentationen explizit `bg = "white"` setzen. - **`device`**: Grafik-Device. Für PNG-Ausgabe liefert `device = ragg::agg_png` (aus dem [{ragg}](https://ragg.r-lib.org/)-Paket) schärferen Text und besseres Font-Rendering als der Default - besonders mit `showtext` oder Nicht-Standard-Fonts. :::{.callout-tip collapse="true"} ## Gängige Exportgrößen Einige typische Dimensionskombinationen: | Anwendungsfall | Breite | Höhe | DPI | |----------------|--------|-------|-----| | Journal-Abbildung (einspaltig) | 3.5 in | 3 in | 300 | | Journal-Abbildung (volle Breite) | 7 in | 5 in | 300 | | Präsentationsfolie (16:9) | 10 in | 5.6 in | 150 | | Poster-Panel | 8 in | 6 in | 300 | | Web/Blog | 8 in | 5 in | 150 | ::: Ein typischer Workflow ist iterativ: Exportieren, Datei öffnen, prüfen ob Textgrößen und Abstände passen, `width`/`height` oder `theme(base_size = ...)` anpassen, erneut exportieren. Diese Schleife ist effektiv, aber mühsam - und genau hier hilft camcorder. :::{.callout-tip} ## Die Export-Prüf-Schleife beschleunigen Zwei Tricks machen den iterativen Prüfzyklus schneller: 1. **Die Datei direkt aus R öffnen** mit `shell.exec("my_plot.png")` (Windows) oder `browseURL("my_plot.png")` (plattformübergreifend). Das spart den manuellen Schritt, die Datei im Dateimanager zu suchen. 2. **Während der Entwicklung als PDF exportieren** und in einem Viewer öffnen, der die Datei nicht sperrt. [Sumatra PDF](https://www.sumatrapdfreader.com/) (Windows, kostenlos) lädt die Datei automatisch neu, sobald sie sich auf der Festplatte ändert - man kann `ggsave()` erneut ausführen und sieht den aktualisierten Plot sofort, ohne ihn schließen und neu öffnen zu müssen. Adobe Acrobat hingegen sperrt die Datei während sie geöffnet ist, sodass `ggsave()` mit einem "Datei wird verwendet"-Fehler fehlschlägt. ::: # Das camcorder-Paket Das [{camcorder}](https://thebioengineer.github.io/camcorder/)-Paket verfolgt einen anderen Ansatz: Anstatt zu exportieren und zu prüfen, fixiert es die RStudio-Viewer-Leinwand auf die exakten Exportabmessungen, *bevor* man mit dem Plotten beginnt. So stimmt die Vorschau mit dem Export überein - man sieht, was man bekommt. ```{r} #| label: export-camcorder #| eval: false camcorder::gg_record( device = "png", width = 6, height = 4, units = "in", dpi = 300 ) ``` Nach einmaligem Ausführen von `gg_record()` zu Beginn einer Session wird jeder nachfolgende Plot im Viewer exakt mit 6 x 4 Zoll und 300 dpi gerendert. Die Abmessungen bleiben fest, unabhängig von der Fenstergröße. Man kann dann am Plot-Code iterieren - Schriftgrößen anpassen, Ränder justieren, Legendenpositionen ändern - und das Ergebnis in Echtzeit in der finalen Exportgröße sehen. Wenn man fertig ist, speichert `gg_record()` auch eine Aufzeichnung jeder Plot-Version, die sich in ein animiertes GIF der Plot-Entwicklung verwandeln lässt: ```{r} #| label: export-camcorder-gif #| eval: false camcorder::gg_playback( name = "plot_development.gif", first_image_duration = 3, last_image_duration = 8, frame_duration = 0.5 ) ``` :::{.callout-tip} ## ggsave vs. camcorder Beide Werkzeuge lösen das Canvas-Problem, aber auf unterschiedliche Weise: - **`ggsave()`** ist eine einmalige Export-Funktion - Plot gestalten, dann exportieren. Am besten für schnelle Exports und geskriptete Pipelines. - **`camcorder`** ist eine sitzungsweite Vorschau-Fixierung - Canvas zuerst fixieren, dann gestalten. Am besten für interaktive Entwicklung, bei der man iterativ an der Ästhetik arbeitet. In der Praxis nutzen viele camcorder während der Entwicklung und `ggsave()` in finalen Skripten. :::