RoboHelp-Word-Ausgabe nach Firmenvorgaben: Warum es scheitert und wie es geht

Die Szene kennt jede Redaktion mit RoboHelp im Werkzeugkasten: Die Online-Hilfe sieht großartig aus, das Responsive-Design sitzt – und dann kommt die Mail. Der Großkunde will die Dokumentation als Word-Datei im vereinbarten Layout, das Qualitätsmanagement besteht auf dem Firmendokument mit korrekter Kopfzeile, oder der Vertrieb braucht das Handbuch als gedruckte Beilage. Kein Problem, denkt man, RoboHelp hat ja eine Word-Ausgabe – Knopf gedrückt, Datei geöffnet, und was einen anblickt, sieht aus wie ein Dokument aus dem Jahr 1998: Standardschrift, Standardabstände, von den Firmenvorgaben keine Spur.

An diesem Punkt trennen sich die Wege. Der eine Weg führt in die Nachformatier-Hölle: Jemand „macht das Dokument noch schnell schön" – bei jeder einzelnen Generierung aufs Neue, denn der nächste Build überschreibt alles. Der andere Weg führt durch ein Verständnis, das dieser Artikel liefert: Die Word-Ausgabe der neuen RoboHelp-Generation kann Firmenvorgaben sehr wohl – aber nur, wenn man ihre Arbeitsteilung versteht. Das Aussehen wohnt in einer Word-Vorlage, der Inhalt im Projekt, und die Ehe zwischen beiden stiftet das Style-Mapping im Ausgabe-Preset. Wer eines dieser drei Elemente ignoriert, bekommt zuverlässig Murks – und sucht die Ursache dann meist am falschen Ort.

Dieser Artikel erklärt die Mechanik, zeigt das Vorgehensmodell für eine stabile, wiederholbare Ausgabe – und erzählt nebenbei die wahre Geschichte einer tagelangen Fehlersuche, an deren Ende genau eine fehlende Zuordnung stand.

Warum überhaupt Word? Eine kurze Ehrenrettung

Bevor wir in die Mechanik einsteigen, eine Einordnung, denn in Online-Hilfe-Kreisen gilt die Word-Ausgabe gern als Relikt. Das ist sie nicht – sie ist ein Ausgabekanal mit legitimen Abnehmern. Kunden fordern vertraglich Dokumente in ihrem Layout; Qualitäts- und Freigabeprozesse hängen an unterschreibbaren Dokumentständen; gedruckte oder druckbare Handbücher brauchen einen Seitenlauf; und Reviews mit Fachabteilungen funktionieren in Word mit Änderungsverfolgung nun einmal reibungsloser als in jedem Hilfe-Frontend. Word ist nicht die Zukunft der Doku-Bereitstellung – aber es ist die Gegenwart vieler Prozesse, und die Redaktion, die beides bedienen kann, ist die stärkere.

Entscheidend ist die Rollenverteilung im Single-Source-Gedanken: Word ist eine Ausgabe, nicht die Quelle. Geschrieben, gepflegt und übersetzt wird im RoboHelp-Projekt; die Word-Datei fällt am Ende heraus wie die Online-Hilfe auch – generiert, nicht gebastelt. Genau daran scheitern die meisten Versuche: Sie behandeln die Word-Ausgabe als Einbahnstraße mit anschließender Handarbeit, statt sie als das zu konfigurieren, was sie sein kann – ein reproduzierbarer Build. Wer übrigens gerade frisch von Classic in die neue Generation migriert ist: Die Neueinrichtung der Ausgaben nach der Migration ist der perfekte Moment, die Word-Ausgabe gleich richtig aufzusetzen; die Migrationsseite des Themas behandelt der Beitrag zur RoboHelp-Konvertierung.

Und weil die Frage regelmäßig kommt: Ja, der Weg über Word ist auch ein bewährter Weg zum druckfertigen PDF – generieren, prüfen, als PDF exportieren, gegebenenfalls mit den Word-Bordmitteln für PDF/A. Ob dieser Umweg oder eine direkte PDF-Erzeugung der bessere Kanal ist, hängt an den Anforderungen an Layoutkontrolle und Prozess; das ist ein eigenes Thema mit eigenen Abwägungen. Für alle Fälle, in denen der Kunde tatsächlich ein bearbeitbares Word-Dokument erwartet, stellt sich die Frage ohnehin nicht – dann führt am sauberen DOCX-Build kein Weg vorbei.

Ein letzter Punkt fürs Erwartungsmanagement, bevor es technisch wird: Ziel ist ein Dokument, das die Firmenvorgaben erfüllt – nicht die pixelgenaue Kopie der Online-Hilfe im Hochformat. Web und Seite sind verschiedene Medien; ein randloses Hero-Bild oder eine dreispaltige Kachelansicht haben im A4-Handbuch schlicht keine Entsprechung, und das ist in Ordnung. Wer das vorab mit den Abnehmern klärt – „gleiches Corporate Design, mediengerechte Umsetzung" –, erspart sich Diskussionen über Unterschiede, die keine Fehler sind.

Die drei Beteiligten: Projekt, Vorlage, Preset

Das Fundament für alles Weitere ist eine saubere Arbeitsteilung zwischen drei Beteiligten. Erster Beteiligter: das Projekt. Es liefert Inhalt und Struktur – die Topics mit ihren CSS-Klassen, und das Inhaltsverzeichnis, das bestimmt, welche Topics in welcher Reihenfolge ins Dokument wandern. Die Aufgabe des Projekts ist semantische Sauberkeit: Jeder Absatz trägt eine Klasse, die sagt, was er ist – Fließtext, Hinweis, Handlungsschritt –, nicht, wie er aussieht. Inline-Formatierung, das händische Fett-und-Größer direkt im Topic, ist der natürliche Feind der Word-Ausgabe: Sie unterläuft jedes Mapping und produziert genau die Ausreißer, die später niemand erklären kann.

Zweiter Beteiligter: die Word-Vorlage. Sie ist die Heimat der Firmenvorgaben – vollständig. Formatvorlagen mit den CI-konformen Definitionen für Überschriften, Fließtext, Hinweise, Beschriftungen; das Seitenformat mit Rändern; Kopf- und Fußzeilen mit Logo, Dokumenttitel und Seitenzahl; Tabellenformatvorlagen für jeden Tabellentyp, der im Projekt vorkommt. Die Vorlage wird in Word gebaut und gepflegt, von jemandem, der Formatvorlagen-Disziplin beherrscht – sie ist das Gegenstück zum CSS des Projekts, nur eben in der Word-Welt. Und der dritte Beteiligte: das Ausgabe-Preset in RoboHelp. Es verknüpft beide Welten – wählt das Inhaltsverzeichnis, wählt die Vorlage und definiert im Style-Mapping, welcher Projektstil auf welche Formatvorlage abgebildet wird.

Diese Dreiteilung ist mehr als Ordnungsliebe – sie ist das Diagnosewerkzeug. Wenn etwas falsch aussieht, gibt es genau drei Verdächtige, und jeder hat ein klares Ressort: Stimmt der Inhalt nicht oder tanzt ein einzelner Absatz, liegt es am Projekt. Stimmt das generelle Aussehen nicht – Schrift, Farben, Seitenlayout, Kopfzeile –, liegt es an der Vorlage. Landet der richtige Inhalt im falschen Gewand, liegt es am Mapping im Preset. Wer diese Zuordnung verinnerlicht, sucht nie wieder tagelang – er fragt: Was genau ist falsch, und wessen Ressort ist das?

Ein Wort zur Pflege der Vorlage, denn sie ist ein Betriebsmittel, kein Einmalprodukt: Es gibt genau eine verbindliche Fassung, sie ist versioniert abgelegt, und Änderungen laufen über einen definierten Weg – idealerweise abgestimmt mit der Stelle, die das Corporate Design verantwortet. Nichts untergräbt eine stabile Ausgabe zuverlässiger als drei Vorlagen-Varianten in Umlauf, von denen jeder Kollege eine andere für die aktuelle hält. Die Vorlage gehört an denselben geordneten Ablageort wie das Projekt selbst – mit Stand, Historie und einem Verantwortlichen mit Namen.

Abb.: Drei Beteiligte, drei Ressorts – das Projekt liefert Inhalt, die Vorlage das Aussehen, das Preset die Zuordnung.

Die Pipeline: vom Inhaltsverzeichnis zum DOCX

Der Ablauf der Generierung folgt aus der Rollenverteilung fast von selbst. Am Anfang steht das Inhaltsverzeichnis: Es ist die Buchdefinition der Word-Ausgabe – was drinsteht und in welcher Reihenfolge, entscheidet sich hier, nicht im Preset. Für ein Kundenhandbuch, das nur einen Teil der Online-Hilfe enthalten soll, legst du schlicht ein eigenes Inhaltsverzeichnis an; das ist der saubere Weg zu unterschiedlichen Dokumentzuschnitten aus derselben Quelle. Dann kommt das Preset: Word-Vorlage auswählen, Style-Mapping pflegen, Ausgabeoptionen setzen – und generieren.

Zwei Eigenschaften der Pipeline verdienen besondere Erwähnung, weil sie Betriebsentscheidungen beeinflussen. Erstens: Kopf- und Fußzeilen kommen aus der gewählten Word-Vorlage. Das ist die richtige Heimat für sie – dort leben Logo, Titelfelder und Seitenzahlen in der Word-eigenen Logik. Die Kehrseite: Wenn im Projekt Master Pages im Spiel sind, die ebenfalls Kopf- oder Fußzeilen mitbringen, kollidieren zwei Quellen – die bekannte Ursache für doppelte oder verunglückte Seitenköpfe. Die Regel lautet: eine Quelle, und das ist die Vorlage. Zweitens: Die DOCX-Datei wird direkt erzeugt, ohne dass auf dem Rechner ein Word installiert sein muss. Das macht die Ausgabe serverfähig – und öffnet die Tür zur Automatisierung, denn die Ausgabegenerierung lässt sich über die Kommandozeile ansteuern: das Kundenhandbuch als nächtlicher Build statt als Klickstrecke.

Wie oft generiert man? So oft wie nötig, so beiläufig wie möglich. In der Einrichtungsphase nach jedem Fix; im Betrieb zu jedem Freigabestand und – als stiller Frühwarner – regelmäßig automatisiert. Eine Ausgabe, die nur zweimal im Jahr unter Termindruck erzeugt wird, sammelt unbemerkt Abweichungen; eine, die routinemäßig läuft, meldet Probleme, solange sie klein sind.

Abb.: Die Pipeline von den Topics zum Firmendokument – die Word-Vorlage speist das Aussehen ein, geprüft wird am Ende, nachformatiert nie.

Die Dokument-Zutaten: Verzeichnis, Deckblatt, Umbrüche

Ein Handbuch ist mehr als formatierter Fließtext – und auch die Buchzutaten folgen der Arbeitsteilung. Das Inhaltsverzeichnis im Word-Dokument entsteht nach Word-Logik aus den Überschriften-Formatvorlagen: Wenn dein Mapping die Projektüberschriften sauber auf die Überschrift-Ebenen der Vorlage abbildet, funktioniert das Verzeichnis von selbst – samt Seitenzahlen und Aktualisierbarkeit. Daran hängt eine Prüfroutine, die man kennen muss: Word-Feldern wie Verzeichnissen und Seitenzahl-Bezügen tut nach der Generierung eine Feldaktualisierung gut, bevor das Dokument in die Abnahme oder den PDF-Export geht – ein Handgriff, der zur dokumentierten Routine gehört, nicht zur verbotenen Nacharbeit.

Das Deckblatt ist eine Architekturentscheidung mit zwei sauberen Varianten: entweder als Bestandteil der Word-Vorlage – mit Feldern für Titel, Version und Datum, die aus den Dokumenteigenschaften gespeist werden – oder als eigenes Topic am Anfang des Inhaltsverzeichnisses, das damit aus dem Projekt gepflegt wird. Beides funktioniert; wichtig ist die bewusste Wahl und ihre Dokumentation, damit nicht beides gleichzeitig passiert. Ähnlich die Seitenumbruch-Frage: Dass jedes Kapitel auf einer neuen Seite beginnt, regelt man elegant in der Vorlage – über die Absatzeinstellung der obersten Überschriften-Formatvorlage –, nicht über manuelle Umbrüche im generierten Dokument. Auch Querverweise und Links verdienen einen Blick im Testlauf: Sie reisen als Word-Hyperlinks mit und gehören ins Prüfprogramm des Referenzkapitels.

Das Style-Mapping: Herzstück und Hauptverdächtiger

Kommen wir zum Herzstück – und zum Ort, an dem die meisten Word-Ausgaben scheitern. Das Style-Mapping im Preset listet auf der einen Seite die Stile deines Projekts: die Absatz-, Zeichen- und Tabellenstile aus den CSS-Dateien, die in den Topics des gewählten Inhaltsverzeichnisses vorkommen. Auf der anderen Seite stehen die Formatvorlagen der gewählten Word-Vorlage. Und dazwischen triffst du je Stil eine von drei Entscheidungen: den RoboHelp-Stil beibehalten (die CSS-Optik wandert mit ins Dokument), den Stil verwerfen und Words Standard verwenden – oder, die Königsdisziplin, auf eine Formatvorlage der Vorlage abbilden. Wichtig zu wissen: Ohne gewählte Word-Vorlage existiert die dritte Option gar nicht erst – dann stehen nur Behalten oder Verwerfen zur Wahl, und von Firmenvorgaben kann keine Rede sein.

Für ein Dokument nach Firmenvorgaben ist die Marschrichtung klar: konsequent auf die Vorlagen-Stile abbilden, Stil für Stil, vollständig. Die Betonung liegt auf vollständig – jeder nicht gemappte Stil ist ein künftiger Ausreißer, der irgendwann in irgendeinem Kapitel auftaucht und dann mühsam zurückverfolgt werden muss. Zwei Disziplinen machen das Leben dabei drastisch leichter. Erstens die Namensdisziplin: Wenn Projektklassen und Word-Formatvorlagen systematisch korrespondierende Namen tragen, wird das Mapping zur Fleißaufgabe statt zur Detektivarbeit – und Zuordnungsfehler fallen sofort auf. Zweitens die Stil-Diät: Je weniger Klassen das Projekt-CSS führt, desto kürzer die Mapping-Tabelle und desto kleiner die Fehlerfläche. Ein historisch gewachsenes CSS mit vierzig Sonderklassen produziert vierzig Mapping-Entscheidungen – die Konsolidierung des Stylesheets, idealerweise gleich bei der Migration, zahlt hier direkt ein.

Ein Sonderkapitel sind die Tabellen. Sie werden auf Words Tabellenformatvorlagen abgebildet – so weit, so konsistent. Aber Word-Tabellenformatvorlagen haben eine Eigenheit: die Optionshäkchen für Sonderformate wie Kopfzeile und gebänderte Zeilen, von denen standardmäßig drei gesetzt sind. Die Ausgabe arbeitet mit dieser Standardbelegung – wenn deine Vorlagen-Tabellen mit anderen Häkchen gestaltet wurden, weicht das Ergebnis sichtbar ab, und niemand versteht auf Anhieb, warum. Die pragmatische Linie: Tabellenformatvorlagen in der Vorlage so bauen, dass sie mit der Standardbelegung der drei Häkchen korrekt aussehen – dann gibt es nichts anzugleichen. Und wo das nicht geht, gehört der Abgleich der Häkchen als dokumentierter Schritt in die Nachprüfung.

Für mehrsprachige Redaktionen kommt eine Dimension dazu: Jedes Sprachprojekt braucht seine funktionierende Word-Ausgabe, und die Vorlage trägt Sprachanteile – Kopfzeilen-Beschriftungen, Verzeichnistitel, Feldbezeichnungen. Praktisch bewährt sich eine Vorlagen-Familie: eine Master-Vorlage je Sprache, identisch in Formatvorlagen-Namen und Aufbau, unterschiedlich nur in den sprachabhängigen Texten. Die identischen Namen sind der Schlüssel – sie halten die Mapping-Logik über alle Sprachen gleich und machen die Einrichtung je Sprachprojekt zur Kopierarbeit statt zur Neuentwicklung.

Abb.: Das Mapping-Prinzip – links die Projektklassen, rechts die Firmen-Formatvorlagen, dazwischen die Entscheidung je Stil.

Warum es scheitert: die üblichen Verdächtigen

Sortieren wir die klassischen Fehlerbilder nach Symptomen, denn so kommen sie in der Praxis daher. Symptom eins: Das ganze Dokument sieht nach Word-Standard aus. Heiße Spur: Im Preset ist keine Vorlage gewählt, das Mapping steht flächig auf Verwerfen – oder die Mapping-Tabelle ist schlicht leer geblieben. Letzteres ist auch als Community-Fall dokumentiert: Gelegentlich füllt sich die Tabelle in einem Preset nicht mit den erwarteten Stilen; dann hilft erfahrungsgemäß der Neuaufbau des Presets in der sauberen Reihenfolge – erst Inhaltsverzeichnis wählen, dann Vorlage, dann Mapping – statt langen Rätselns im bestehenden.

Symptom zwei: Das Dokument stimmt weitgehend, aber einzelne Absätze tanzen aus der Reihe. Heiße Spur: Inline-Formatierung im Topic oder eine Sonderklasse, die im Mapping fehlt. Hier lohnt der Blick in die Topic-Quelle an der betreffenden Stelle – fast immer findet sich dort ein historisches Format-Fossil oder eine Klasse, von deren Existenz niemand mehr wusste. Symptom drei: Kopf- oder Fußzeilen doppelt, leer oder falsch – die Master-Page-Kollision aus dem Pipeline-Kapitel; eine Quelle festlegen, fertig. Symptom vier: Tabellen sehen anders aus als in der Vorlage gestaltet – die Häkchen-Falle. Diese vier Muster decken nach aller Erfahrung den Großteil aller „die Word-Ausgabe funktioniert nicht"-Fälle ab – und keines davon ist ein Fehler der Ausgabe. Es sind Konfigurationslücken mit klarer Adresse.

Der fünfte Verdächtige verdient eine lobende Erwähnung, weil er seltener zuschlägt, als viele erwarten: die Bilder. Grafiken reisen zuverlässig mit ins Dokument; Aufmerksamkeit brauchen eher die Ränder des Themas – Beschriftungen, die als sauberer Absatzstil geführt und gemappt sein wollen, und sehr breite Screenshots, die im Seitenformat der Vorlage anders wirken als im endlosen Browserfenster. Beides gehört ins Referenzkapitel des Testlaufs; beides ist mit einem Beschriftungsstil und einem Blick auf die Bildbreiten dauerhaft erledigt.

Und für alles, was dann noch übrig bleibt, hilft ein unscheinbares Werkzeug: das Fehlerjournal. Jeder Befund aus Testläufen wird mit Symptom, Ursache und Fix in einer schlichten Liste festgehalten – drei Spalten, kein Prozesstheater. Nach der Einrichtungsphase ist diese Liste die Wissensbasis für alle künftigen Fälle und für jeden neuen Kollegen; die meisten „neuen" Fehlerbilder entpuppen sich als Wiedergänger mit bekanntem Fix. So wird aus Fehlersuche Wissensaufbau – einmal gelöst bleibt gelöst.

Abb.: Die vier häufigsten Fehlerbilder mit ihren heißen Spuren – jede führt in eines der drei Ressorts.

Der Praxisfall: tagelange Suche, eine Zuordnung

Zeit für die Geschichte, die diesem Artikel seinen Untertitel gibt – anonymisiert, aber in den entscheidenden Zügen echt. Die ausführliche Fassung mit allen Wendungen folgt in einer eigenen Fallstudie; hier die Kurzform mit den Lehren.

Warum passieren solche Fälle ausgerechnet gestandenen Redaktionen? Weil die Suche dem Schmerz folgt statt der Struktur: Das Fehlerbild wirkt zufällig verteilt, also verdächtigt man das große Ganze – die Vorlage, das Werkzeug, die Umgebung – und übersieht die kleinste Einheit, die alle betroffenen Stellen gemeinsam haben. Die Klasse am Element ist unspektakulär, unsichtbar im Ausgabedokument und deshalb der letzte Ort, an dem man sucht. Genau dafür lohnt es, die Diagnose-Reihenfolge einmal aufzuschreiben und ihr auch dann zu folgen, wenn die Intuition längst woanders gräbt.

Die Lehren aus dem Fall sind übertragbar. Erstens: Bei Formatfehlern immer zuerst die Klasse des betroffenen Elements feststellen und ihren Weg durchs Mapping verfolgen – das ist der kürzeste Pfad, und er hätte hier Tage gespart. Zweitens: Vollständigkeit des Mappings ist prüfbar – die Liste der Projektstile gegen die Mapping-Tabelle halten, fertig; was nicht gemappt ist, ist ein Kandidat. Drittens: Sonderklassen sind technische Schulden – jede historisch gewachsene Spezialklasse ist ein potenzieller Wiedergänger dieses Falls, und die Konsolidierung des Stylesheets ist die nachhaltigste Prävention. Und viertens, vielleicht am wichtigsten: Systematik schlägt Intuition. Die Rollenverteilung aus diesem Artikel ist genau dafür da – sie verwandelt „irgendwas stimmt nicht" in drei gezielte Fragen.

Das Vorgehensmodell: in sechs Schritten zur stabilen Ausgabe

Zum Abschluss das Vorgehen für den Aufbau von Grund auf – die Reihenfolge ist bewusst gewählt. Schritt eins: die Word-Vorlage bauen, und zwar sauber. Die Firmenvorgaben werden vollständig in Formatvorlagen gegossen – für jede inhaltliche Rolle eine, mit systematischen Namen –, dazu Seitenlayout, Kopf- und Fußzeilen und die Tabellenformatvorlagen. Das ist Word-Handwerk und verdient dieselbe Sorgfalt wie das Projekt-CSS; eine schlampige Vorlage kann kein Mapping der Welt retten. Schritt zwei: die Projektseite inventarisieren – welche Klassen existieren, welche werden wirklich gebraucht, was lässt sich konsolidieren? Jede eingesparte Klasse ist eine Mapping-Zeile und eine Fehlerquelle weniger.

Schritt drei: das Preset anlegen – Inhaltsverzeichnis wählen, Vorlage setzen. Schritt vier: das Mapping pflegen, Stil für Stil, vollständig, mit der Namensdisziplin als Rückenwind. Schritt fünf: der Testlauf – und zwar nicht mit dem Gesamtwerk, sondern mit einem Referenzkapitel, das alle Stile enthält. Generieren, gegen eine schriftliche Abnahme-Checkliste prüfen (Überschriftenhierarchie, Fließtext, Hinweise, Listen, Tabellen, Bilder mit Beschriftung, Kopf- und Fußzeilen, Verzeichnis), Befunde an der Wurzel beheben, erneut generieren – bis drei Läufe in Folge sauber sind. Schritt sechs: dokumentieren und automatisieren – die Einrichtung als kurze Doku festhalten, die Generierung in die Kommandozeilen-Routine aufnehmen, und bei mehrsprachigen Projekten dieselbe Preset-Logik je Sprachprojekt nachziehen, damit das französische Handbuch genauso zuverlässig fällt wie das deutsche; das Zusammenspiel mit dem Übersetzungsworkflow beschreibt der Beitrag zur Mehrsprachigkeit mit RoboHelp.

Und danach der Betrieb: Die Ausgabe ist eingerichtet, aber die Welt dreht sich weiter. Ändert sich das Corporate Design, wird die Vorlage aktualisiert – eine Stelle, ein Vorgang, alle künftigen Dokumente folgen. Kommt eine neue Inhaltsklasse ins Projekt, wandert sie gleichzeitig in Stil-Zoo und Mapping. Und einmal im Quartal lohnt der Routine-Build des Zoos als Gesundheitscheck. Das klingt nach wenig, und genau das ist der Punkt: Eine richtig eingerichtete Word-Ausgabe verursacht im Betrieb fast keinen Aufwand mehr – aller Aufwand, der doch anfällt, ist ein Hinweis auf eine Regel, die gerade verletzt wird.

Fazit

Die RoboHelp-Word-Ausgabe scheitert nie an RoboHelp – sie scheitert an ungeklärter Arbeitsteilung. Sobald die drei Rollen sauber besetzt sind – das Projekt liefert semantisch sauberen Inhalt, die Word-Vorlage trägt die kompletten Firmenvorgaben, das Preset verbindet beide über ein vollständiges Style-Mapping –, wird aus dem Ärgernis ein Build: reproduzierbar, automatisierbar, abnahmefähig ohne Handgriff. Die klassischen Fehlerbilder haben klare Adressen, die Fehlersuche folgt der Klasse statt dem Gefühl, und die eine übersehene Zuordnung aus dem Praxisfall bleibt anderen erspart, wenn Vollständigkeit geprüft statt vermutet wird.

Der pragmatische Einstieg: Vorlage bauen, Stylesheet verschlanken, Stil-Zoo anlegen – und dann Mapping und Testläufe, bis drei Generierungen in Folge sitzen. Wenn du dabei Unterstützung willst – von der CI-gerechten Word-Vorlage über die CSS-Konsolidierung bis zur automatisierten Ausgabe: Genau dabei unterstütze ich dich gern; die Details findest du auf der Beratungsseite zur Technischen Dokumentation.

Häufige Fragen zur RoboHelp-Word-Ausgabe

Warum sieht meine Word-Ausgabe nach Word-Standard aus?

Fast immer, weil im Ausgabe-Preset keine Word-Vorlage gewählt ist oder das Style-Mapping nicht gepflegt wurde – ohne Vorlage existiert die Option, auf Firmen-Formatvorlagen abzubilden, gar nicht erst. Abhilfe: eine sauber gebaute Vorlage im Preset hinterlegen und das Mapping vollständig pflegen, Stil für Stil. Bleibt die Mapping-Tabelle leer, hilft erfahrungsgemäß der Neuaufbau des Presets in der Reihenfolge Inhaltsverzeichnis, Vorlage, Mapping.

Wo gehören die Firmenvorgaben hin – ins CSS oder in die Word-Vorlage?

Für die Word-Ausgabe: in die Word-Vorlage. Sie definiert Formatvorlagen, Seitenformat, Kopf- und Fußzeilen sowie Tabellenformatvorlagen nach CI – das Projekt-CSS beschreibt dieselben inhaltlichen Rollen für die Online-Ausgaben. Das Style-Mapping im Preset verbindet beide Welten. Faustregel: Das Projekt beantwortet „Was ist dieser Absatz?", die Vorlage beantwortet „Wie sieht das aus?" – und keines pfuscht dem anderen ins Ressort.

Kann ich die generierte Datei nicht einfach nachformatieren?

Können ja, sollten nein: Jede Korrektur im generierten DOCX lebt nur bis zur nächsten Generierung und verdeckt zugleich die eigentliche Ursache in Vorlage, Mapping oder Quelle. Nachhaltiger ist die Regel, jeden Befund an seiner Wurzel zu beheben und neu zu generieren, bis mehrere Läufe in Folge ohne Handgriff abnahmefähig sind. Bewusste, dokumentierte Ausnahmen sind erlaubt – alles andere ist wiederkehrende Handarbeit mit Verfallsdatum.

Woher kommen Kopf- und Fußzeilen im Word-Dokument?

Aus der im Preset gewählten Word-Vorlage – dort leben Logo, Titelangaben und Seitenzahlen in der Word-eigenen Logik. Wichtig: Master Pages aus dem Projekt dürfen nicht zusätzlich Kopf- oder Fußzeilen beisteuern, sonst kollidieren zwei Quellen – das klassische Fehlerbild doppelter oder verunglückter Seitenköpfe. Für die Word-Ausgabe gilt: eine Quelle, und das ist die Vorlage.

Brauche ich Word auf dem Rechner, der die Ausgabe erzeugt?

Nein – die DOCX-Datei wird direkt erzeugt, ein installiertes Word ist dafür nicht erforderlich. Das macht die Word-Ausgabe build- und serverfähig: In Kombination mit der Kommandozeilen-Automatisierung der Ausgabegenerierung lässt sich das Firmendokument als regelmäßiger, reproduzierbarer Build erzeugen – für alle Sprachfassungen in einem Rutsch, ohne Klickstrecke und ohne Office-Installation auf dem Buildsystem.