von Konrad Rudolph » Do, 28.12.2006 00:38
Stephan hat geschrieben:Ich weiß, dass das bei den Listenvorlagen Standard ist aber ich finde es konzeptionell einfach furchtbar.
Dann erkläre das bitte, ich bin hochgespannt. (Du hast "konzeptionell" gebraucht, nicht etwa 'unbequem zu bedienen' o.ä.)
Gerne.
Zuersteinmal finde ich es "furchtbar", weil hier drei unterschiedliche Absätze benötigt werden, um einen zusammengehörenden Stil auszudrücken. Die Liste der Stilvorlagen ist so schon unübersichtlich genug, da muss man nicht noch drei Elemente pro Stilvorlage reinquetschen.
So. Wenn wir uns jetzt das ODT-Format unter der Haube anschauen, dann sehen wir, dass es sich um XML handelt -- also um eine Datenstruktur, die perfekt geeignet für eine hierarchische Ordnung ist. Und die wird hier einfach nicht ausgenutzt. Wenn schon so eine Krücke mit "erstes" bzw. "letztes Element" sein muss, wieso dann nicht, wie vom Format suggeriert, hierarchisch? Also folgendermaßen:
Code: Alles auswählen
<p:formatvorlage>
<special:first>...</special:first>
...
<special:last>...</special:last>
</p:formatvorlage>
Wieso das konzeptionell ein gravierender Fehler ist: Weil der Vorteil dieser XML-Struktur ja (nicht ganz unbeabsichtigt!) ist, dass man das Format mit einem "einfachen" XSL-Transformationsskript in ein anderes Dokumentformat umwandeln kann -- und zwar quasi ohne Einschränkungen (XHTML, LaTeX, PostScript, PDF, RTF) ... für jede Zielplattform optimal.
Aber durch diese Eigenart der Stilvorlagen ist das leider zumindest für die meisten auf SGML aufbauenden Formate (also alles in Richtung HTML und XML) unmöglich. Zumindest, wenn man Wert auf sauberes Markup legt und das tue ich.
Ich habe mal für eine Webseite simultan Inhalte als PDF und XHTML bereit gehalten, die Dokumentgrundlage war ODT. Eigentlich perfekt, könnte man denken. Aber nix da, es war ein Krampf.
Aber wenn ich das z.B. in ein HTML-Dokument transformieren möchte, dann erhalte ich Tag-Suppe. :-(
Für alles was nun mit konverteren zusammenhängt wie Du es jetzt beschreibst würde ich gleich Latex nehmen.
Arg. :-( LaTeX hat in meinem Fall drei Nachteile:
- Es ist grundsätzlich aufwendiger.
- Es gibt keinen guten Konverter nach HTML.
- Das Anwenden eigener Layouts ist nicht wirklich vorgesehen und in der momentanen Version ein Krampf.
Hinzu kommt, dass ich mich nur rudimentär mit LaTeX auskenne und zudem erstmal anfangen würde, Makropakete für mein Dokument zu schreiben, darauf habe ich nur begrenzt Bock. ;-)
Wenn ich mit solchen Textrahmen arbeite, muss ich trotz einer vorgefertigten Rahmen-Formatvorlage noch manuell nacharbeiten, um den Rahmen korrekt zu formatieren.
inwiefern konkret - Du kannst doch eine Rahmenvorlage erstellen
Ja, aber z.B. kann man dort die Verankerung ("als Zeichen") nicht einstellen. Und dass die Breite automatisch angepasst werden soll muss man beim Einfügen des Rahmens auch nochmal explizit auswählen, sonst wird das nicht übernommen.
Desweiteren bliebe das Problem, dass der Rahmen zu breit für die Seite wird, wenn ich links einen Abstand zwischen Rahmen und Inhalt einfüge.
Sorry, das verstehe ich nun überhaupt nicht.
Ich habe, Deinem Beispiel folgend, mal ein Bild gemacht:

(Quelle:
http://madrat.net/temp/beispiel.odt.zip)
Das Problem sollte hier sichtbar sein: Der Rahmen steht über den Seitenrand hinaus und ich weiß nicht, wie ich das ändern kann.
lg,
Konrad.
[quote="Stephan"][quote]Ich weiß, dass das bei den Listenvorlagen Standard ist aber ich finde es konzeptionell einfach furchtbar.[/quote]
Dann erkläre das bitte, ich bin hochgespannt. (Du hast "konzeptionell" gebraucht, nicht etwa 'unbequem zu bedienen' o.ä.) [/quote]
Gerne.
Zuersteinmal finde ich es "furchtbar", weil hier drei unterschiedliche Absätze benötigt werden, um einen zusammengehörenden Stil auszudrücken. Die Liste der Stilvorlagen ist so schon unübersichtlich genug, da muss man nicht noch drei Elemente pro Stilvorlage reinquetschen.
So. Wenn wir uns jetzt das ODT-Format unter der Haube anschauen, dann sehen wir, dass es sich um XML handelt -- also um eine Datenstruktur, die perfekt geeignet für eine hierarchische Ordnung ist. Und die wird hier einfach nicht ausgenutzt. Wenn schon so eine Krücke mit "erstes" bzw. "letztes Element" sein muss, wieso dann nicht, wie vom Format suggeriert, hierarchisch? Also folgendermaßen:
[code]<p:formatvorlage>
<special:first>...</special:first>
...
<special:last>...</special:last>
</p:formatvorlage>[/code]
Wieso das konzeptionell ein gravierender Fehler ist: Weil der Vorteil dieser XML-Struktur ja (nicht ganz unbeabsichtigt!) ist, dass man das Format mit einem "einfachen" XSL-Transformationsskript in ein anderes Dokumentformat umwandeln kann -- und zwar quasi ohne Einschränkungen (XHTML, LaTeX, PostScript, PDF, RTF) ... für jede Zielplattform optimal.
Aber durch diese Eigenart der Stilvorlagen ist das leider zumindest für die meisten auf SGML aufbauenden Formate (also alles in Richtung HTML und XML) unmöglich. Zumindest, wenn man Wert auf sauberes Markup legt und das tue ich.
Ich habe mal für eine Webseite simultan Inhalte als PDF und XHTML bereit gehalten, die Dokumentgrundlage war ODT. Eigentlich perfekt, könnte man denken. Aber nix da, es war ein Krampf.
[quote][quote]Aber wenn ich das z.B. in ein HTML-Dokument transformieren möchte, dann erhalte ich Tag-Suppe. :-( [/quote]
Für alles was nun mit konverteren zusammenhängt wie Du es jetzt beschreibst würde ich gleich Latex nehmen.[/quote]
Arg. :-( LaTeX hat in meinem Fall drei Nachteile:
- Es ist grundsätzlich aufwendiger.
- Es gibt keinen guten Konverter nach HTML.
- Das Anwenden eigener Layouts ist nicht wirklich vorgesehen und in der momentanen Version ein Krampf.
Hinzu kommt, dass ich mich nur rudimentär mit LaTeX auskenne und zudem erstmal anfangen würde, Makropakete für mein Dokument zu schreiben, darauf habe ich nur begrenzt Bock. ;-)
[quote][quote]Wenn ich mit solchen Textrahmen arbeite, muss ich trotz einer vorgefertigten Rahmen-Formatvorlage noch manuell nacharbeiten, um den Rahmen korrekt zu formatieren.[/quote]
inwiefern konkret - Du kannst doch eine Rahmenvorlage erstellen[/quote]
Ja, aber z.B. kann man dort die Verankerung ("als Zeichen") nicht einstellen. Und dass die Breite automatisch angepasst werden soll muss man beim Einfügen des Rahmens auch nochmal explizit auswählen, sonst wird das nicht übernommen.
[quote][quote]Desweiteren bliebe das Problem, dass der Rahmen zu breit für die Seite wird, wenn ich links einen Abstand zwischen Rahmen und Inhalt einfüge.[/quote]
Sorry, das verstehe ich nun überhaupt nicht.[/quote]
Ich habe, Deinem Beispiel folgend, mal ein Bild gemacht:
[img]http://madrat.net/temp/bildschirmfoto.png[/img]
(Quelle: http://madrat.net/temp/beispiel.odt.zip)
Das Problem sollte hier sichtbar sein: Der Rahmen steht über den Seitenrand hinaus und ich weiß nicht, wie ich das ändern kann.
lg,
Konrad.