Haben Sie schon einmal versucht, eine PowerPoint-Datei „zu verstehen“? Wollten Sie einmal die „Führungslinien“ benutzen, um Objekte in einer Präsentation zuverlässig auszurichten? Haben Sie sich gewundert, dass die Werte in den Bedienfeldern so krumm sind? Kurz: Wollten Sie wegen PowerPoint schon mal alles anzünden? 

Kann doch nicht so schwer sein

Nun; wenn Sie mit einer Version von PowerPoint 2013, 2016 oder neuer arbeiten, gibt es Hoffnung. Aber Sie müssen ein bisschen fleißig sein. Und Sie müssen einen XML-Editor benutzen. 

Sie sind noch da? Gut. Dann krempeln wir die Ärmel hoch.
Sie haben noch 2.000 Worte vor sich. 

Mit einer gewissen Wahrscheinlichkeit ist das Programm PowerPoint älter als der geneigte Leser dieses Beitrags; denn es wurde bereits Mitte der 1980er Jahre entwickelt und 1987 vorgestellt. Zu Beginn war es ein reines Macintosh-Programm. Und es wurde von Microsoft zugekauft. Von diesen Informationen kann man ableiten, dass es im Kern einige Herausforderungen gibt, über die man beim Thema „Dokumentaufbau“ stolpern kann. Und so ist es auch.

Steigen wir ein

Formatfragen

Es ist nicht zielführend, zu versuchen, sich von den eingangs geschilderten Rahmenbedingungen freistrampeln zu wollen. Damit meine ich: die Software wurde in den USA konzipiert (Inch sind schlüssiger als Zentimeter), die Jahrtausendwende war noch fern (72 dpi versus HiDPI) und es wurde zum Behufe des Drucks von Transparentfolien für Overheadprojektoren entwickelt (statische Inhalte versus animierte Inhalte). Wer versucht, gegen diese Fundamente „anzuarbeiten“, wird früher oder später feststellen, dass er seine Energien fehlgeleitet hat. 

4:3, 16:9 – oder DIN A4?

Bei der Entscheidung für ein Präsentationsformat gibt es zwei augenfällige Möglichkeiten – und darüber hinausgehende Optionen. Von Haus aus möchte PowerPoint wissen, mit welchem Seitenverhältnis gearbeitet werden soll. In den meisten Fällen wird man sich für 16:9 entscheiden. Erfahrene Anwender werden bemerken, dass die angegebenen Abmessungen der Folien in PowerPoint früher andere waren; Microsoft hat das im Zuge der Umstellung auf XML-basierte Dateiformate – auf höherem Niveau – vereinheitlicht. Die Höhe der Folien ist in beiden Fällen 7,5 Zoll – nur die Breite variiert. Einer der Gründe dafür ist, dass PowerPoint in begrenztem Umfang in der Lage ist, Präsentationen von einem ins andere Seitenverhältnis zu überführen. Das ist etwas logischer herstellbar, wenn eins der Maße stabil bleibt. Doch darum soll es hier nicht gehen; auch wenn das massive Auswirkungen auf das Zusammenschieben von Folien alter und neuer Machart hat.

Mutige Anwender legen sich ein abweichendes/eigenes Format an; beispielsweise ein eigenes DIN A4. Dazu sollte man wissen, dass PowerPoint stets davon ausgeht, dass es einen Druckerrand gibt (es wurde im Zeitalter der Nadel-Matrixdrucker entwickelt). Heißt; wenn Sie wirklich ein an 297 x 210 mm angenähertes Format (Inch zu cm bei geringer Präzision; siehe unten), werden Sie bei Ausdrucken auf A4-Papier stets die Drucke skalieren müssen; oder Sie legen das Format gleich umlaufend etwas kleiner an … so wie das „eingebaute“ A4. Aber auch das möchte ich hier nicht weiter vertiefen. 

Wir gehen von der Nutzung des „Standardformates“ aus – das ist „Breitbild“ mit 16:9-Seitenverhältnis. Eine 16:9-Datei hat angeblich die Abmessungen 13,33 x 7,5 Zoll. Das entspricht 33,86 x 19,05 cm. Beide Maße werden Ihnen aber nur im Frontend angezeigt. In Wirklichkeit sind die Präsentationen nämlich 

<p:sldSz cx="12192000" cy="6858000"/>

groß. Das sind „EMU“ – „English Metric Unit“; eine Einheit, die es ermöglichen soll, zwischen Zoll und Zentimetern zu vermitteln; bei ganzzahligen Werten. Ein Zentimeter sind 360000 EMU; ein Zoll entspricht 914400 EMU. 

Woher habe ich diese Codezeile? Aus dem XML-Code der PowerPoint-„Datei“.

EMU? XML? Hä?

Etwas Hintergrund

Eine PowerPoint-„Datei“ ist – seit der Version 2010/2011 – keine solche mehr. In Wirklichkeit arbeiten Sie in einer Ordnerhierarchie, die gezippt und mit der Endung .pptx versehen wird. 

Das hat auch den angenehmen Nebeneffekt, dass PowerPoint-Dateien – so vorhergehende Benutzer nicht aktiv zerstörend eingegriffen haben – stets die originalen Zuspieler enthalten (Logos, Bilder) und aus dieser Struktur wieder extrahiert werden können. Jede PowerPoint-Datei – komplexe Ausnahmen bestätigen die Regel – hat zunächst folgende verdeckte Ordnerstruktur, in der Sie sich bewegen müssen: 

• _rels
• docProps
• ppt
[Content_Types].xml

Ihr Leben als PPT-Profi beginnt am besten mit der Installation der sogenannten „OOXML-Tools“ in Google Chrome. Damit kommen Sie in die Lage, recht komfortabel und kurzwegig die relevanten Informationen zu verändern, um die es im Folgenden geht. Die OOXML-Erweiterung für Chrome verkürzt den Weg, nach der Bearbeitung des XML wieder an eine gültige .pptx zu kommen.

Sollten Sie irgendwelche Befindlichkeiten bei der Benutzung von Chrome oder der zusätzlichen Einbindung von Plugins in Chrome haben, bleibt Ihnen nur der sehr steinige Weg, den John Korchok dankenswerterweise für Macintosh und Windows schildert. So habe ich jahrelang gearbeitet, bis er mit dem OOXML-Editor-Tipp um die Ecke kam. Seitdem kann ich wieder häufiger lächeln (und deutlich flotter vorwärtskommen). 

Haben Sie die Bearbeitung des XML in den OOXML-Tools abgeschlossen, können Sie per „Download“ das Verpacken der .pptx anstoßen. Die Datei landet im Download-Ordner des Rechners und kann von dort an sinnvolle Orte transferiert und in PowerPoint geöffnet werden. 

Okay, PowerPoint. Berechne! 
Na gut. Ich mach’ das.

Vergessen Sie, was PowerPoint an Werten im Frontend anzeigt

Wenn Sie wirklich präzise in PowerPoint arbeiten möchten – beispielsweise, weil Sie ein tragfähiges Template für hunderte Mitarbeiter eines Konzerns erstellen müssen – sollten Sie alle Maße im XML hinterlegen. Vergessen Sie das Frontend. Das Frontend ist für den fahrigen, unter Zeitnot agierenden Endanwender da. Der wird in den meisten Fällen mit einigen Pixeln Versatz klarkommen – Template-Erzeuger nicht. 

Wann immer Sie Objekte im Interface von PowerPoint bewegen, muss Ihnen bewusst sein, dass unter der Haube immer in EMU umgerechnet wird. Da das Interface einzig zwischen Zoll/Zentimeter unterscheidet, haben Sie „vorne“ keine Chance, exakt aneinander anstoßende Objekte anzulegen. Lassen Sie sich auch nicht durch die „magnetischen“ Hilfslinien blendblindberauschen – es funktioniert nicht. Das sehen Sie spätestens, wenn Sie sich die exakten EMU-Positionen der Objekte im XML anschauen. Es mag daran liegen, dass PPT offenkundig wirklich nur mit zwei Nachkommastellen auf Basis der belanglosen Frontend-Werte rechnet und dabei auch noch rundet – das kann nur in die Grütze gehen bzw. zufällig stimmen.

Maßsystem im Betriebssystem: Metrisch oder US?

Das Umgang von PowerPoint mit Maßeinheiten und Bewegungen per Cursortasten im Interface ist etwas organischer, wenn man das Betriebssystem (!) auf „US-Maße“ umstellt. Sie werden gleich sehen, weshalb. 

Das gilt sowohl für den Mac als auch für Windows. Es ist allerdings ein recht tiefer Eingriff ins System. Ich mache das nur auf einer dedizierten PowerPoint-Maschine oder in einer Virtualisierung. Ähnliches gilt auch für Spracheinstellungen, wenn Sie Vorlagen für fremdsprachliche Fassungen liefern müssen:

Ich schicke an dieser Stelle vorweg, dass Führungslinien in PowerPoint nicht in EMU und auch nicht in Inch – sondern in Black-Magic-Units vermaßt werden. Dafür gibt es eine (vollkommen undokumentierte) Berechnung, die im Kern auf Inch basiert.

Für die Werteermittlung müssen Sie nicht von Hand zwischen Inch/cm/EMU umrechnen, weil Herr Lars Corneliussen – der dafür mehrere internationale Verdienstorden am Bande verdient (aber vermutlich nicht bekommen) hat, einen wundervollen Onlinerechner bereitstellt (siehe folgende Screenshots). Den Rechner finden Sie auf seiner Website: http://lcorneliussen.de/raw/dashboards/ooxml/

Führungslinien –
as good as it gets

Seit einigen Jahren wird sowohl im Print- wie auch im Webdesign versucht, Gestaltungen in „Raster“ bzw. „Grids“ zu pressen. Es wird ein Satzspiegel definiert und dieser in vertikal gleich große Bereiche gesplittet. Auf diese Flächen werden dann Inhalte gelegt. Das sorgt für einen sauberen Auftritt; und im Falle des Webdesigns erzieht es auch dazu, sich mit Fragen der Responsiveness zu beschäftigen. Das spielt für PowerPoint aber keine Rolle. Dennoch gibt es natürlich auch hier das Bestreben, den Benutzer der Software dazu anzuhalten, sich an diesen vertikalen Rastern zu orientieren. Dieses Verhalten kann man dadurch begünstigen, dass Texte, Objekte und Charts sich in PowerPoint ebenfalls an ein solches 12er / 16er / whatever Raster anlehnen. Auch, wenn es dem Benutzer der Präsentation nicht gelingt, letzte Präzision zu erzielen, wird doch eine größere Ruhe in die Gestaltung einkehren – was die präsentationsbetrachtende Zielgruppe durch ruhigere Folienübergänge zu schätzen weiß: Weniger visuelle Aufregung lässt der vermittelten Information mehr Raum und Zeit.

Wo ist eigentlich „0“?

Im Frontend bietet PowerPoint nach der Aktivierung der Führungslinien zunächst jeweils eine zentrale vertikale bzw. horizontale Führungslinie an. Dass hierbei keine sonst bekannten Bedienlogiken greifen, merkt der Anwender schnell: 

Einmal bewusst oder unbewusst versetzt, kann man die Hilfslinien nicht per „Undo“ an ihren Ausgangspunkt zurücksetzen. Die Lineale haben den Nullpunkt im Zentrum der Folie; wie bei einem mathematischen Graphen. Und wie kriegt man eigentlich mehr als zwei Führungslinien? 

In Wirklichkeit folgt die Position der Führungslinien der üblichen Computerlogik; der Nullpunkt sitzt oben links. Davon ausgehend, kann man ganzzahlige Werte nach rechts und unten wachsen lassen. Die Präzision dabei ist überaus mäßig, weil die dahinterstehenden Werte nicht sehr groß werden. 

Master / Layout / Slide

PowerPoint kann Führungslinien auf drei Ebenen verwalten; dem eigentlichen Folienmaster, einem darauf basierenden Layout oder auf einer „echten“ Inhaltsfolie. 

Die Linien auf den Inhaltsfolien sind nicht viel mehr als ein Ausrichtungshilfsmittel im Frontend. Werden sie berührt, versetzen sie. Das macht sie für belastbare Anwendungen nutzlos.

Für Dinge wie verbindliche Raster möchte man die Linien im XML des Folienmasters hinterlegen. Dann kann der Anwender sie im Frontend-Bearbeitungsmodus nicht mehr versehentlich bewegen. 

Jede Linie kann mit einem eigenen Farbwert ausgegeben werden. Am wenigsten Umstellung/Ärger hatte ich dabei bislang mit Hex-Werten; die meisten Anwendungen können damit umgehen und sie können direkt ins XML einkopiert werden. PowerPoint selbst wünscht sich Frontend RGB-Angaben. Daher sollten Sie beides immer parallel dokumentieren. 

Besitzt eine PowerPoint-Datei mehrere Folienmaster, müssen die einzeln betrachtet werden. Die Führungslinien wandern nicht mit; ergo können sie auch zwischen verschiedenen Mastern abweichend sein bzw. müssen in das XML jedes Masters eingefügt werden, wenn sie überall ident sein sollen.

Definition einer Führungslinie

Jedes Slidemaster-XML enthält hinter der Definition der „Textstyles“ eine Liste mit den „Guides“. Zumeist liegt das eher am Ende des XML-Codes. Zur Bearbeitung muss man folgende Informationen handhaben: 

• Alle Linien im XML müssen fortlaufende IDs besitzen
• Vertikale Führungslinien bekommen kein Orientierungs-Tag
• Die Position wird in Black-Magic-Einheiten (Berechnung: siehe unten) angegeben
• Die Farbe muss immer angegeben werden; welche, ist freigestellt. 
• Im Frontend gezogene Linien haben eine „userdrawn“-Eigenschaft. Wird sie entfernt, verhalten sich die Linien etwas robuster.

<p15:guide id="1" orient="horz"pos="227" userDrawn="1">
<p15:clr>
<a:srgbclr val="36715E" />
</p15:clr>
</p15:guide>

Black-Magic-Einheiten für Führungslinien

Der Positionswert für die Linie im Frontend wird wie folgt berechnet: 

Position in Zoll mal 72 mal 8

Benutzen Sie zur cm/inch-Berechnung das Online-Tool von Lars– das verkürzt den Weg. Im Beispiel sitzt die Linie auf einem Zentimeter. Oder: 

0.3937007874015748 Zoll mal 72 (dpi) mal 8 (black magic) = 226.771653543

Sprich: präziser als rund (!) 227 Punkte pro Zentimeter wird es nicht. 

Das Drama hierbei: Zoomt man im Interface auf die maximal möglichen 400% und positioniert seine Führungslinien akribisch, kommt trotzdem nichts Präziseres dabei heraus. Obwohl da eine höhere Präzision suggeriert wird. Schade. 

Wo Werte hinterlegen?

Ich rate dazu, relevante Hilfslinien auf die Slidemaster-XMLs zu legen und die anderen Optionen zu ignorieren. Grundsätzlich können „guides“ auf allerlei einzelne „Seiten“ der PPTX-Struktur angelegt werden. Dort sind sie aber meist von äußerst begrenztem Nutzen. Oder sie verwirren im Frontend. Wertvoll sind sie, wenn sie durch den Frontendarbeiter nicht versetzt werden können – ohne dass er das aktiv einleitet, indem er den Folienmaster verändert. 

Aufbaustudium

Hat man seine Führungslinien per präziser Berechnung im XML-Code hinterlegt, schließt sich direkt der nächste Wunsch an: 

Die Objekte im Frontend (Master-Bildrahmen, Logos …) mögen doch bitte ebenfalls präzise herumstehen. 

Dazu wiederum braucht man Lars’ Berechnungstool. Mit dem kann man dann – auf Basis von EMU – Rahmen und Objekte korrekt und präzise positionieren. Ohne dass es zu „Blitzern“ kommt. Dazu müssen allerdings sämtliche Berechnungen – parallel zu den Black-Magic-Berechnungen – hierzu in EMU vorgenommen werden. Nur dann stehen die Objekte tatsächlich so deckungsgleich wie möglich. Natürlich stets mit der bestehenden Einschränkung, dass „Black Magic“ nur 227 Einheiten pro Zentimeter liefert – EMU aber 360000 Einheiten für die gleiche Strecke. 

Die Führungslinien sind also nicht viel mehr als das; ein visueller Anhalt. Tatsächliche Präzision erreichen Sie also einzig durch das manuelle Setzen von Objekten im XML. Nicht per Führungslinie, nicht im Interface. 

Print?

Falls Sie sich fragen, was dieser Beitrag mit „Print“ zu tun hat: 

Auf Basis dieser Informationen können Sie auch ein A4-Template mit „Beschnitt“ aufbauen, das sich vorhersagbar verhält und 303 x 216 mm groß ist. Oder Führungslinien mit negativen Werten hinterlegen. 

Kurz: Sie werden ziemlich flexibel mit PowerPoint. Das ist doch was. 

Danksagung und Online-Tools

Ich danke an dieser Stelle John Korchok und Lars Corneliussen, die ich beide um die Zustimmung gebeten habe, ihr mühsam erarbeitetes Wissen für diesen Beitrag nutzen und teilen zu dürfen. Beide haben umgehend zugestimmt und ihre Erlaubnis erteilt. Das hat mir sehr geholfen und viele vorher „unlösbare“ Probleme ausgeräumt. Allerherzlichsten Dank! 

Besuchen Sie zur Vertiefung Ihres Wissens bitte die Internetauftritte beider Herren:

Lars Corneliussen – Umrechnungstool – http://lcorneliussen.de/raw/dashboards/ooxml/

John Korchok – XML-Einblicke – http://www.brandwares.com/bestpractices/