Modularisierung von Tabellen

Hallo Frau Mitschke, hallo andere NutzerInnen,

momentan bin ich dabei eine modularisierte Dokumentation mit Texteinschüben im Strukturierten Framemaker 12 aufzubauen. Die Doku hat unterschiedlich große Module. Teilweise sind ganze Kapitel im Gesamten wiederzuverwenden... das ist ein Traum. ... soweit alles gut...

Aber jetzt habe ich eine Tabelle, die aus einem Tabellenkopf (1. Zeile) und 4 (2.-5. Zeile) weiteren inhaltlichen Zeilen besteht... Aus dieser Tabelle werden an unterschiedlichen Stellen teilweise einzelne Zeilen mit dem Tabellenkopf benötigt, teilweise aber auch die gesamte Tabelle...
Kurzes Beispiel:
Stelle 1: Zeile 1 + 3
Stelle 2: Zeile 1 - 5
Stelle 3: Zeile 1 + 3 + 4

Gibt es einen anderen Weg als jede Zeile in ein eigenständiges Framemaker-Dokument zu packen?
Macht es hier Sinn mit bedingten Texten zu arbeiten? Bzw. geht das hier überhaupt?
Mit bedingten Texten hatte ich bisher nicht zu tun... ich nutze Framemaker erst seit wenigen Monaten...

Vielen Dank schonmal für Ihre Hilfe und frohes Diskutieren

Hallo Sarah,

bedeutet "im Strukturierten Framemaker 12", dass Sie xml-basiert arbeiten?

Die Sache mit der Gültigkeit einzelner Tabellen-Reihen für verschiedene Varianten ist eine Herausforderung.
Ich sehe hier 3 Lösungsansätze:

1. (mein favorisierter) entspricht Ihrem Vorschlag, Module mit wiederholtem Inhalt aufzubauen. (Nicht nur) Im Hinblick auf die XML-Basis ist es die beste Lösung, da dabei keine invalide Tabellenstruktur entsteht und Sie alle Zusammenstellungen gut kontrollieren können..

2. Es ist möglich in FrameMaker-Dokumenten, Tabellen so aufzubauen, dass für jede Reihe eine eigene Tabelle erstellt wird. Der Absatz mit dem Tabellenanker kann durch entsprechende Formatierung direkt hinter der Tabellenreihe verschwinden, so dass die hintereinander im Textfluss stehenden Einzel-Reihen-Tabellen im Seitenlayout so aussehen, als würden sie eine Tabelle ergeben. Soll später allerdings nach XML oder HTML5 exportiert werden, braucht es beim Export eine kleine Transformation, um die Einzelreihen-Tabellen zu einer einheitlichen Tabelle zu verbinden.
Allerdings hinkt sie bei Seitenwechsel, da die Kopfreihe immer nur vor der ersten Tabellenreihe steht und sich deshalb nicht wiederholt. Wenn die Tabelle klein ist und immer zusammengehalten wird, so dass sie nur komplett umbricht, mag das allerdings funktionieren.

3. Bedingter Text funktioniert, wenn Sie wissen, was Sie tun und sich Regeln aufbauen, welche Objekte Sie mit bedingtem Text ein-/ausblenden wollen. Es ist möglich, sowohl Tabellenspalten als auch Tabellenreihen Bedingungsformate zuzuweisen. Wichtig ist dabei, die Bedingungsformate dem Varianten-Konzept insgesamt mit unterzuordnen. Widersprüchliche Zuweisungen machen Dokumente schwer handhabbar.

Warum ich die erste Variante bevorzuge: sie bedeutet zwar, dass sie bei Änderungen mehrere Module pflegen müssen, ist aber am transparentesten bei Änderungen/Erweiterungen und kann mit dem allgemeinen Varianten-Konzept gehandhabt werden. Außerdem erkennen Sie immer den vollständigen Inhalt der Variante, was bei bedingtem Text und den farblich gestalteten Bedingungsformaten nicht gleichzeitig gut erkennbar ist.

Es interessiert mich, welche Lösung Sie bevorzugen und freue mich über Ihr Feedback - oder das anderer Leser.

Herzliche Grüße, Ute Mitschke

Hallo Ute,

vielen Dank für Ihre Antwort...

Ja, wir arbeiten XML-basiert mit einer eigen erstellten EDD.

Und nach Ihrer Antwort bevorzugen wir auch die Variante 1 .
Momentan haben wir das Problem, dass wir "row" leider nicht als Wurzelelement einsetzen können.
Somit ist in der Struktur so viel "Mist" (root - head - chapter - table - table group), den wir leider nicht brauchen können im endgültigen Dokument.

Die "normalen" Texteinschübe bekommen wir hoffentlich damit in Griff, dass wir die Wurzel "root" in "Module" umbenennen... Aber ich sehe bei der Tabelle ein Problem bei der Struktur.

Haben Sie oder ein anderer Nutzer hier einen Tipp?

Hallo Sarah,

ein Screenshot der existierenden Struktur wäre zum Verständnis des Problems ganz hilfreich.

Ansonsten: Wenn eine eigene EDD besteht, sollte doch auch jedes gewünschte Element als Root-Element zu verwenden sein? Oder gibt da jemand anderes schon etwas vor?

Viele Grüße
Peter

Hallo Sarah und Peter,

für das Verschachteln von einzelnen <row>-Elementen gibt es innerhalb von FrameMaker keine direkte Lösung:
1. In einem strukturierten FrameMaker-Dokument kann bei einer "normalen"-Element-Struktur von Tabellen eine einzelne Tabellenreihe innerhalb des strukturierten FrameMaker-Dokuments nicht als Wurzel-Element verwendet werden. Für den Export des Content nach XML ist allerdings sehr wohl gut möglich.

Folgende zwei Umsetzungen möchte ich vorschlagen:

1. Im strukturierten FrameMaker-Dokument
- spezielles Absatzformat für einen Absatz anlegen, in dem der Anker stehen wird und der hinter der Tabelle "verschwindet" und im EDD via Textformatregeln dem Container zuweisen, der die einreihige Tabelle dann aufnehmen wird. Damit wird es möglich, die importierten Module so dicht aufeinander folgen zu lassen, dass es so aussieht, als wäre es im Kapitel eine Tabelle.
- Im EDD erlauben, dass die Tabelle ohne thead angelegt werden darf (wenn nicht bereits erlaubt)
2. Für den Export einer kompletten Publikation nach XML
- in der Applikation ein XSLT-Script unter Postprocessing angeben.
- in diesem XSLT die aufeinander folgenden Tabellen so reduzieren, dass sie im XML dann als eine Tabelle mit vielen Reihen ankommen.
-> allerdings gibt es ohne zusätzliche Attributierung nach dem Export keinen Weg zurück für den Import, weil definiert sein muss, welche Reihen beim Import wieder als eigene Tabellen dargestellt werden müssen.

Herzliche Grüße und ein schönes Wochenende
Ute