Re: [de-users] Steuerung von Seitenumbrüchen
Hallo Andreas, Der Parameter Einfügen Seite, Position Davor ist auch für die Absatzvorlage Überschrift 1 gesetzt, die ja immer auf einer neuen Seite beginnen soll. Das kann ich aus der Absatzvorlage wegnehmen, das Verhalten beim Umbruch von OOo ändert sich jedoch nicht. Genau das scheint mir aber das Problem zu sein. Du hast einerseits einen (leeren) Absatz eingefügt, der auf einer neuen Seite beginnen soll und andererseits folgt auf diesen leeren Absatz eine Überschrift, die wiederum auf einer neuen Seite beginnen soll. Ich würde zunächst mal diesen leeren Absatz löschen, den brauchst du nicht. Wie gesagt, wenn ich in der Absatzvorlage: Überschrift 1 unter Textfluss - Umbrüche die Option Einfügen... Seite deaktiviere, purzelt zwar der gesamte Seitenumbruch durcheinander (es hat also eine Wirkung), die unerwünschten Leerseiten bekomme ich dann aber trotzdem. Beispiel: * Kapitel 1 endet auf Seite 7 (rechte Seite) * Kapitel 2 beginnt auf Seite 8 (linke Seite) Kapitel 2 soll nun auf der _rechten_ Seite beginnen, was es nach Änderung der Definition der Seitenvorlage nicht tut. Also gehe ich zum Ende von Seite 7, wähle Umbruch einfügen, Seitenumbruch, Vorlage: Rechte Seite. Damit bekomme ich: * Seite 9, leer, bis auf Kopf- und Fußzeilen; Seitenvorlage: rechte Seite. Im Kolumnentitel stehen die letzten Kapitelüberschriften von Kapitel 1. * Seite 10, Beginn des Kapitels 2, Seitenvorlage: linke Seite (!). Im Kolumnentitel stehen weiterhin die Kapitelüberschriften von Kapitel 1, die zuletzt auf Seite 7 valide waren (aber das ist eine andere Baustelle) Die hier genannten Seitenzahlen sind keine Tippfehler, sondern das, was im Kolumnentitel steht. Wie die zustandekommen, sieht man ein paar Minuten später in der Seitenvorschau (Buchansicht): * Doppelseite 6-7: Kapitel 1.4, beginnt auf S. 6, endet auf S. 7. * Doppelseite 8-9: Seite 8 ist eine automatisch eingefügte [leere Seite], Seite 9 ist die echte leere Seite, die durch den manuellen Seitenumbruch generiert wurde (mit Kopf- und Fußzeilen). * Doppelseite 10-11: Auf Seite 10 (links) beginnen Kapitel 2 und Unterkapitel 2.1 Also neuer Versuch; diesmal füge ich am Ende von Seite 7 (linke Seite) mit Umbruch einfügen, Seitenumbruch, Vorlage: Linke Seite wieder einen Seitenumbruch ein. Damit bekomme ich diesmal: * Seite 8, leer, bis auf Kopf- und Fußzeilen; Seitenvorlage: linke Seite. Im Kolumnentitel stehen die letzten Kapitelüberschriften von Kapitel 1. * Seite 10, Beginn des Kapitels 2, Seitenvorlage: linke Seite (!). Im Kolumnentitel stehen weiterhin die Kapitelüberschriften von Kapitel 1. Seitenvorschau/Buchansicht: * Doppelseite 6-7: Kapitel 1.4, beginnt auf S. 6, endet auf S. 7. * Doppelseite 8-9: Seite 8 ist diesmal die echte leere Seite, die durch den manuellen Seitenumbruch generiert wurde (mit Kopf- und Fußzeilen), Seite 9 ist dagegen eine automatisch eingefügte [leere Seite]. * Doppelseite 10-11: Auf Seite 10 (links) beginnen Kapitel 2 und Unterkapitel 2.1 Machmal klappt es, nach einer linken Seite mit einem manuellem Seitenumbruch eine linke (Leer-) Seite einzufügen, damit das nächste Kapitel dann wirklich rechts weitergeht. Damit bekomme ich zwar eine Häufung von Leerseiten und die Verzeichnisse gehen jedesmal zum Teufel, aber dann stimmt wenigstens der Seitenumbruch. Wenn ich den Seitenumbruch aus der Absatzvorlage für Überschrift 1 entferne, scheint das nicht mehr zu funktionieren. (Die Verzeichnisse sind übrigens die dritte Baustelle; da ich mit einer Konkordanzdatei arbeite, kann ich das Stichwortverzeichnis nicht aktualisieren; ich muß immer zuerst sämtliche Markierungen manuell aus dem Dokument entfernen, da OOo sonst bei jedem Aktualisieren neue Verzeichniseinträge anlegt und nicht prüft, ob bereits welche vorhanden sind; das Dokument wächst sonst bei jdem Aktualisierungsvorgang um 100-150 kB und die (doppelten, dreifachen) Verzeichniseinträge lassen sich nicht mehr bearbeiten. Die vierte Großbaustelle ist die Einbindung von Textrahmen bzw. Abbildungen, bei der es ja immer heißt, sie wäre im OOo stabil (was bei mir nicht der Fall war) und den Seitenumbruch bei jedem Öffnen des Dokuments an einer weiteren Stelle durcheinanderpurzeln ließen. Diese Kumulation (Seitenumbruch - Stichwortverzeichnis - Abbildungen/Textrahmen) von Veränderungen an mehren Stellen war höllisch). Viel Erfolg Andreas Danke ;) Die Arbeit ist aber mit all den Leerseiten und Umbruchfehlern abgegeben. Ich versuche momentan nur noch alles das zu verstehen, wozu während der Bearbeitungszeit des Themas keine Zeit war. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Steuerung von Seitenumbrüchen
Hallo Robert, Mich würde interessieren, was bei Dir auf der neu eingeführten leeren Seite und auf der Seite steht in der Du als Folgeseite erst mit dem Inhalt beginnst. Der (eventuell unbeabsichtigte) Umbruch müsste eigentlich in dem ersten Absatz der Seite 2 (Linke Seite) sichtbar sein. Hier: Absatz - Textfluss. OOo Writer kennt ja diese virtuellen leeren Seiten, die es automatisch einfügt, um einen zweiseitigen Satzspiegel aufzufüllen; die meine ich aber nicht. Was OOo einfügt sind vollkommen normale Seiten mit Kopf- und Fußzeilen, in denen der Seitenzähler ebenfalls normal hochgezählt wird. Diese Leerseite nach einem manuell eingefügten Seitenumbruch hat dann bspw. die Seitennummer 1 und die Folgeseite, auf der der eigentliche Text beginnt/weitergeht, die Seitennummer 2. Das passiert auch bei einseitigen Seitenvorlagen (z.B. Seitenvorlage Standard, Folgevorlage Standard). OK, aber bleiben wir bei zweiseitigem Layout, mit den Seitenvorlagen Linke Seite und Rechte Seite (jeweils Folgevorlage voneinander). Einfügen eines manuellen Seitenumbruchs, Rechte Seite. Ich bin auf der neu eingefügten Leerseite. Wenn ich hier Steuerzeichen anzeigen lasse (falls es das ist, was du meinst), befindet sich auf der Leerseite mit der Seitenvorlage Rechte Seite anstelle des Textes eben genau ein Absatzzeichen (Absatzmarke, Alinea). Wenn ich den Cursor davor positioniere und dann Absatz - Textfluss aufrufe, steht in der Dialogbox: * Einfügen Seite, Position Davor * Mit Seitenvorlage: Rechte Seite, Seitennummer 0. Der Parameter Einfügen Seite, Position Davor ist auch für die Absatzvorlage Überschrift 1 gesetzt, die ja immer auf einer neuen Seite beginnen soll. Das kann ich aus der Absatzvorlage wegnehmen, das Verhalten beim Umbruch von OOo ändert sich jedoch nicht. Die nächste Seite, in der der Text weitergeht (und auf der ein neues Kapitel beginnt), hat nun die Seitenvorlage Linke Seite und eben genau _nicht_ die gewünschte Rechte Seite. Leider ist das alles etwas schwer zu beschreiben ;-/ MfG -asb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Steuerung von Seitenumbrüchen
Hallo, ich verstehe einfach nicht, wie ich in OOo Seitenumbrüche gezielt steuern kann. Laut Dokumentation gibt es dazu zwei Möglichkeiten, zum einen (a) das Binden eines Seitenumbruchs an eine Absatzvorlage, zum anderen (b) das Einfügen manueller Seitenumbrüche. Beides funktioniert für mich nicht. (ad a) Ein Absatzformat (z.B. Überschrift 1) kann, soweit ich das verstehe, immer nur an _genau_ eine Seitenvorlage gebunden werden (z.B. Rechte Seite). Brauche ich innerhalb des Dokuments an einer anderen Stelle (z.B. im Anhang) einen Seitenumbruch auf eine _andere_ Seitenvorlage, muß ich ein neues (zusätzliches) Absatzformat definieren; das bringt jedoch Chaos ins Inhaltsverzeichnis und zieht einen Rattenschwanz von Folgeproblemen mit sich, wenn man das zu fixen versucht. (ad b) Das Einfügen manueller Seitenumbrüche ist entweder vollkommen buggy, oder ich verstehe überhaupt nicht, wie es funktionieren soll. Beispiel: Wenn ich auf einer Seite ix (röm. numeriert, Seitenvorlage Verzeichnis) über * Einfügen/Manueller Umbruch/Seitenumbruch, * Vorlage Rechte Seite, * Seitennummer ändern auf 1, einen manuellen Seitenumbruch mit Wechsel der Seitenvorlage einfügen möchte, produziert OOo eine _Leerseite_ (und zwar eine _echte_). Diese Leerseite hat dann das Seitenformat Rechte Seite und die Seitennummer 1; Text und neues Kapitel, die auf der _rechten_ Seiten mit der Seitennummer 1 beginnen sollten, beginnen nun auf der _linken_ Seite (Seitenvorlage: Linke Seite) und haben die Seitennummer 2. Ich habe jetzt einen vollen Tag mit Herumtüfteln verbracht und bekomme es einfach nicht hin: Ein neues Kapitel soll auf der _rechten_ Seite beginnen, und die erste Seite des ersten Kapitels soll die Seitennummer 1 bekommen. Wie gesagt, die Variante (a) ist aus verschiedenen Gründen keine echte Option. Warum produziert OOo diese Leerseiten?? Irgendwelche Vorschläge? Danke mfG, -asb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Suche nach daß findet dass
Hi, wenn ich in einem Text on OOo Writer 2.4.0-dev (WinXP SP2) nach dem String daß suche, werden mir alle Fundstellen von dass angezeigt. Eine gezielte Suche nach daß (ohne dass) ist nicht möglich. Soll das so sein, oder ist das ein Bug, oder kann man das irgendwo konfigurieren? Dankge, -asb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Speicherdauer, Aktualisierungsdauer, Arbeitsgeschwindigkeit
Hi, ist es eigentlich normal, dass OOo Writer auf einem Core2Duo zwei bis drei Minuten zum Speichern eines 300-Seiten-Dokuments braucht und bei Extras/Aktualisieren/Alle Verzeichnisse den Rechner für eine geschlagene Viertelstunde (!) lahmlegt (100% Auslastung eines CPU-Kerns über die gesamte Verarbeitungsdauer)? Zumindest bei mir ist das neu, seitdem ich einen Index via Konkordanzdatei eingefügt habe; vorher dauerte das Speichern und selbst Extras/Aktualisieren/Alles aktualisieren nur Sekunden. Ebenfalls scheinbar korrelierend mit der Konkordanzdatei (auch vorher gab es schon einen kleinen Stichwortindex mit manuellen Einträgen) hat sich das Arbeitstempo von OOo Writer auch dramatisch reduziert; Tippen und Cursorbewegungen erfolgen mit Verzögerung à la TTY-Terminal in den 1980er Jahren, Ausschneiden/Einfügen setzt immer eine Bedenkpause voraus; flüssiges Arbeiten ist schlichtweg unmöglich geworden. Wovon hängt das ab, und kann man es irgendwie umgehen/beschleunigen? Plattform: WinXP, OOo-dev 2.4.0 (SRC680_M241; ja, dev muß leider sein) Danke MfG -asb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Writer: Stichwortverzeichnis mit Konkordanzdatei
Hi, könnte es sein, dass OOo Writer ab dem Zeitpunkt, wo eine Konkordanzdatei genutzt wird, bei jeder Aktualisierung (Speicherung?) des Dokuments für alle Einträge in der Konkordanzdatei einen _neuen_ (also _zusätzlichen_) Verzeichniseintrag in den Text schreibt? Sprich: Zehnmal aktualisieren des Dokuments = zehn Verzeichniseinträge auf dem Stichwort?? Falls ja: Gibt es eine Möglichkeit, ein Dokument von solchen redundanten Verzeichniseinträgen zu säubern (am besten Tabula rasa, alle Einträge für Stichwortverzeichnis wegputzen)? Danke mfG -asb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Writer: Verzeichniseinträge nicht bearbeit bar
Hi, so langsam beginne ich an meinem Verstand zu zweifeln; ich bilde mir ein, dass ich früher in OOo Writer Verzeichniseinträge _bearbeiten_ konnte (Anzeigen mit Ansicht/Markierungen, dann mit rechter Maustaste auf einen entsprechenden Eintag klicken, dann Objektmenü Verzeichniseintrag). M.E. habe ich so früher eine Dialogbox bekommen, in der es einen Löschen-Button gab; außerdem waren da Pfeil-Buttons ( und ), mit denen man zwischen den Markierungen vor- und zurückblättern konnte. All diese Funktionen gibt es jetzt bei dem o.g. Menü nicht mehr; die erscheinende Dialogbox heißt Verzeichnismarkierungen und besteht aus der Angabe Verzeichnis: Stichwortverzeichnis; darunter folgt Eintrag als scrollbare Listbox. Rechts daneben gibt es zwei Buttons, OK und Abbrechen, sonst nichts. Und wie lösche ich jetzt fehlerhafte oder unerwünschte Verzeichniseinträge?? Plattform: WinXP, OOo-dev 2.4.0 (SRC680_M241; ja, dev muß leider sein) Danke mfG, -asb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] OOo Writer zerstört Tabllenstr uktur und löscht Inhalte
Hallo Raphael, Hast du vielleicht ein Dokument, dass du an den issue anhängen kannst, dies würde helfen. Ich habe im Issue Tracker jetzt ein Dokument angehängt und Dir ein Testdokument per Mail geschickt. Vielen Dank, -asb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] OOo Writer zerstört Tabllenstru ktur und löscht Inhalte
Josef Latt wrote: Dir ist bewußt, daß Du eine Developerversion nutzt. Ja, muß ich leider wegen eines anderen kritischen Fehlers, der erst in OOo 2.4 repariert sein wird (Issue 82902). OOo 2.3.1 hat das Problem mit Tabellen auch noch nicht bzw. nicht mehr, dafür ist da aber noch Issue 82902 virulent. Abgesehen davon kann ich, voraussetzend, daß ich den Issue richtig interpretiert habe, den Fehler nicht nachvollziehen. Ich benutze seit ein paar Wochen OOo-Dev2.3 m235 Snapshot, weil da Issue 82902 korrigiert ist und bisher keine Probleme auftraten; ich habe auch nicht wirklich Lust, neben einer Magisterarbeit einen permanenten Updatezirkus von Entwicklerversionen mitzumachen, wenn es nicht ganz dringend nötig ist. Ich vermute nämlich mal, dass sich die Snapshots nicht unbedingt von Version zu Version besserentwickeln, sondern auch mal neue Fehler durch das Korrigieren alter produzieren (so wie dieses Tabellenproblem). Laut aktuellem Eintrag von mru im Issue Tracker ist das Problem mit Tabellen aber seit 680m237 repariert; ich lade daher gerade [1] und [2] herunter, in der Hoffnung, dass das die richtigen Pakete sind und nicht noch mehr Ärger bescheren. OOo 2.3.1 und OOo 680m241 jeweils unter WIndows XP Sp2. *knock on wood* Danke für den Hinweis auf den (hoffentlich) funktionierende 680m241, MfG -Agon [1] http://ftp-1.gwdg.de/pub/openoffice/developer/SRC680_m241/OOo-Dev_SRC680_m241_Win32Intel_install_en-US.exe [2] http://ftp-1.gwdg.de/pub/openoffice/developer/SRC680_m241/OOo-Dev_SRC680_m241_Win32Intel_langpack_de.exe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] OOo Writer zerstört Tabllenstruktur und lö scht Inhalte
Hallo, bei mir ist es jetzt bereits wiederholt vorgekommen, dass OOO Writer die Tabellenstruktur beim Speichern zerstört und dabei die Inhalte aus den Tabellenfeldern löscht. Ich hatte das Problem am 19.12. als Bug gemeldet (Issue 84731, [1]), seitdem ist dort der Status unconfirmed gelistet; jetzt ist der Fehler erneut aufgetreten und lässt sich bei mir auch hübsch reproduzieren: Ein halbwegs komplexes Tabellenraster anlegen, Felder mit Inhalt füllen, dann einzelne Tabellenreihen und Zellen verbinden, speichern, Dokument schließen, Dokument öffnen - und weg ist die Tabellenstruktur mitsamt den Inhalten. In content.xml finden sich dann noch Strukturrudimente wie ... table:table-row table:table-cell table:style-name=Tabelle33.A1 table:number-rows- spanned=65535 office:value-type=string text:p text:style-name=Standard/ /table:table-cell table:table-cell table:style-name=Tabelle33.A1 table:number-rows- spanned=65520 office:value-type=string text:p text:style-name=Standard/ /table:table-cell /table:table-row table:table-row ... und auch dort sind die Inhalte verschwunden (= gelöscht). Sind momentan gravierende Probleme mit Tabellen in OOo Writer 2.x bekannt, und gibt es Workarounds, oder sollte man in OOo lieber ganz auf Tabellen verzichten? Danke, -asb [1] http://qa.openoffice.org/issues/show_bug.cgi?id=84731 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Download von OOo-Dev2.3 m235 Snapshot
Hi, herzlichen Dank für die Aufschlüsselung der OOo-Entwicklungsbäume. SRC680_m23x = fortlaufende Entwicklung - neue Features, kann instabil sein, nicht für die tägliche produktive Arbeit. So richtig beruhigend klingt es allerdings nicht, wenn ich einen fatalen Bug in OOo nur durch Verwendung einer nicht für die tägliche produktive Arbeit geeigneten Version umgehen kann - gerade, wenn es um eine Magisterarbeit geht. Anyway, den OOo-Dev2.3 m235 Snapshot habe ich heruntergeladen und nach einer mittleren Deinstallationsorgie installiert; die zuvor installierten Extensions und Tastatur-Remappings gingen dabei leider flöten, ich kann jetzt aber seit rund zwei Wochen unbelästigt von korrumpierten Dateien schreiben; außer einigen spürbaren Warteschleifen bei Zeilenumbrüchen und den fehlenden Extensions kann ich mit dem OOo-Dev2.3 m235 Snapshot in etwa so wie mit einem normalen OOo arbeiten, außer den üblichen Bugs aus den regulären Releases fallen bei dem Snapshot jedenfalls keine besonderen Störungen auf. Ich habe in der Zwischenzeit nicht mehr in die ODT-Dateien geschaut, ob es immer noch Encoding-Kumulationen gibt, aber die Probleme mit nicht mehr öffenbaren Dateien und Programmabstürzen scheinen beseitigt zu sein. Daher von mir nur dieses Feedback aus Benutzer-Perspektive: M.E. spricht nichts dagegen, den Code auf die Öffentlichkeit loszulassen. Nochmal vielen Dank auch an die Entwickler für das Fixen dieses groben Bugs! MfG -Agon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Writer: Mehrere Inhaltsverzeichniseinträge i n einer Zeile
Hallo, Inhaltsverzeichnisse von OOo Writer sehen in etwa immer folgendermaßen aus: Überschrift 1 Seite Überschrift 1.1 ... Seite Überschrift 1.2 ... Seite Ich versuche nun, folgende Struktur hinzubekommen: Überschrift 1 Seite Überschrift 1.1 ... Seite Überschrift 1.2.1 (Seite), Überschrift 1.2.2 (Seite), Überschrift 1.2.3 (Seite), Überschrift 1.2.4 (Seite) Überschrift 1.3 ... Seite In einer Zeile sollen also mehrere Überschriften einer Ebene nacheinander aufgeführt werden; bisher habe ich aber weder eine entsprechende Anleitung gefunden, noch ist es mir gelungen, so ein Layut zusammenzuklicken. Beispiel: Bei einer Definition von Verzeichnis - Einträge mit E# - E - (#) bekomme ich den Zeilenumbruch nach der Seitennummer nicht weg. Mache ich da etwas falsch, oder geht das in OOo gar nicht? Danke MmfG -Agon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Download von OOo-Dev2.3 m235 Snapshot
Hallo Liste, kann mir jemand verraten, ob und wo ich ein OOo-Dev2.3 m235 Snapshot in installierbarer Form herunterladen kann? OOo 2.3.0 und OOo-Dev 2.3 Developer Snapshot (build OOG680_m8) von [1], also m.E. die aktuellste Dev-Version, die ein Endanwender herunterladen und installieren kann, haben gravierende Fehler, die ein Öffnen und Bearbeiten meiner Dokumente verhindern (Issue 83466, [2] und weitere; Absturz von OOo beim Öffnen des Dokuments; Absturz von OOo bei Zeilenumbrüchen; Korruption des ODT-Dateiformats mit der Folge von nicht öffenbaren Dokumenten). In [2] steht: You could also check, if this still happens in OO 2.4 dev build; there a large fix for such problems has been introduced by issue 81146. Daher habe ich vor ein paar Tagen den OOo-Dev 2.3 Developer Snapshot (build OOG680_m8) von [1] heruntergeladen, den ich für den OO 2.4 dev build hielt, der die Fehler aber nicht behebt; dazu sagt jetzt [2] nach meiner won't fix-Meldung: Of course it is not fixed in the OOG build... it is the 2.3.1 release and target of this issue is OO 2.4. Try this link for SRC680m235 build [3] Anscheinend ist OOo 2.3.1 keine Testversion für OOo 2.4; ich habe keine Ahnung, was der Unterschied zwischen OOG680_m8 und SRC680m235 ist, jedenfalls klingt SRC* und die Notiz Sources can be received from cvs by tag SRC680_m235 von [3] für mich nach Quelltext pur und nicht nach installierbarer Anwendung. Jedenfalls finde ich auf [3] keinen Download-Link für eine installierbare OOo-Version. Eigentlich lautet die Frage daher wohl, ob es irgendwo eine OOo-Version außer des für März 2008 angekündigten OOo 2.4 gibt, mit der ich _jetzt_ und _heute_ meine Dokumente öffnen und bearbeiten kann. Und nein, ich studiere nicht Informatik, und nein, ich habe keine Entwicklungsumgebung installiert, mit der ich mal eben SRC680_m235 aus dem CVS kompilieren könnte (falls das die Antwort sein sollte). Danke mfG -Agon [1] http://download.openoffice.org/680/index.html?intcmp=1232 [2] http://www.openoffice.org/issues/show_bug.cgi?id=83466 [3] http://development.openoffice.org/releases/2.3.m235_snapshot.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Umstieg FrameMaker - OOo
Nora Etukudo wrote: Du planst von einem McLaren-Mercedes auf einen Rettungs-Hubschrauber umzusteigen? Ein interessanter Vergleich; nein, ich überlege, von OOo wieder _zurück_ zu FM zu wechseln, was ich bis vor zwei Jahren benutzt hatte. Nachdem damals klarer wurde, dass es bei FM u.a. keine Beweglichkeit in Richtung Linux geben würde (Frame ist ein traditionelles *nix-Programm, und es gab um 2000/2001 sogar eine Linux-Betaversion), habe ich mich dann auf das OOo-Experiment eingelassen und die Entwicklung von Frame nicht mehr weiterverfolgt (andere Gründe waren u.a. die horrend teuren Upgrades und die nachwuchsfeindliche Academic Licensing-Politik in Deutschland, aber das ist hier off topic). Hintergrund meiner Frage war, ob es mittlerweile Gründe gibt, FM den Rücken zu kehren - beispielsweise, wenn das neue Datenformat instabil oder Extensions dadurch inkompatibel geworden wären. Letzteres habe ich gerade ausprobiert; der Outliner Enhance von Sandybrook läuft unter FM8 nicht mehr, und die Entwickler haben ein Update für QI 2008 in Aussicht gestellt - zu spät für mich. Ein weiterer Nachteil von Frame ist, dass es bisher keinerlei Unterstützung für Open Document bietet, man muss also über Zwischenformate oder Clipboard importieren, oder auf eigene Faust mit XML herumbasteln. Obwohl ich mit keinem der folgenden Programme je gearbeitet habe, erscheint mir ein Umstieg von Framemaker auf Scribus naheliegender: Scribus ist ein Programm à la Page Maker oder Quark X-Press und primär für Seitengestaltung (also hübsch bebilderte Einzelseiten) gedacht; Frame ist dagegen für (Massen-) Textsatz, Datenbankanbindung und strukturiertes Texten mit Schweinereien wie SGML konzipiert, und darüber hinaus auch durchaus tauglich als Textverarbeitung - Seitengestaltungsprogramme dagegen nicht, jedenfalls habe ich noch nichts derartiges in den Fingern gehabt. Zwischen Frame und OOo gibt es eine ganze Menge konzeptionelle Überschneidungen, m.E. jedenfalls mehr als zwischen Winword und Frame bzw. Winword und OOo; wer mit Frame gearbeitet hat, wird i.d.R. sehr leicht mit OOo klarkommen. Der Unterschied ist nur, dass Dinge wie Rahmenvorlagen oder Speicherformate bei Frame wirklich funktionieren (bzw. in FM 5.x und 6.x funktioniert haben), während ich bei OOo seit nunmehr knapp vie Wochen nur noch damit beschäftigt bin, Bugs manuell auszubügeln oder zerschredderte Dateien nachzubauen und auf baldige Bugfixes zu hoffen. Daher wüsste ich halt gerne von eventuellen Umsteigern von FM auf OOo, welche Gründe es für einen Umstieg gegeben haben könnte, beispielsweise ob die Software heute nicht mehr so stabil ist, wie sie es einmal war etc. (sowas erfährt man meist am besten von Deseteuren ;) MfG -Agon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Umstieg FrameMaker - OOo
Hallo, gibt es hier zufällig jemanden, der von Adobe FrameMaker auf OpenOffice.org umgestiegen ist? Wie verlief der Wechsel? Welche Gründe gab es? MfG -asb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Rahmenvorlage aktualisieren
Agon S. Buchholz wrote: ich versuche gerade, eine Rahmenvorlage (Marginalie) in OpenOffice.org Writer 2.3.0, deutsche Version, Windows XP SP-2, zu verändern; sie soll prinzipiell einfach nur einen Zentimeter breiter werden und dafür einen Zentimeter weiter links beginnen (also bspw. im Dialog Typ: Breite statt 2,00 cm jetzt 3,00 cm und Typ: Position: Horizontal: Von links statt 15,00 cm nun 14,00 cm). Unter Verwalten ist in der Dialogbox Autom. aktualisieren markiert. Die Änderung der Rahmenvorlage wirkt sich jedoch nicht auf die entsprechenden Rahmen im Dokument aus; sie bleiben einfach an dem alten Position (15 cm von links) und haben weiterhin eine Breite von 2,00 cm. [...] Fall es jemanden interessiert: Das Problem (Issue 83468) steht jetzt im Bug Tracker als Closed, da es als identisch mit Issue 72114 vom 29. November 2006 [1] identifiziert wurde, zu dem es bisher keine Lösung bzw. keinen Workaround gibt. Issue 72114 wiederum ist identisch/ähnlich mit Issue 45501 vom 19. März 2005 [2], und dazu gibt es weitere Verwandte (Issue 45499 und Issue 19850 vom 21. September 2003, der als accepted bezeichnet wird). Zu keinem dieser Fehler ist unter Resolution eine Lösung oder ein Workaround angegeben. Der drei bis vie Jahre alte Fehler scheint also nicht besonders weit oben auf der Prioritätenliste zu stehen, man wird sich also auch weiterhin damit arrangieren müssen, dass Rahmenvorlagen in OOo nicht konsistent funktionieren. MfG -Agon [1] http://qa.openoffice.org/issues/show_bug.cgi?id=72114 [2] http://qa.openoffice.org/issues/show_bug.cgi?id=45501 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] OOo Writer stirbt nach Öffnen von ODT-Datei
Hallo Liste, nach dem Bug im Speichermechanismus von OOo Writer 2.3.0 von vorletzter Woche, der dazu führte, dass OOo die ODT-Datei so codierte, dass OOo sie nicht mehr öffnen konnte (Issue 82902, [1]), habe ich jetzt einen neuen Bug: OOo hängt sich beim Öffnen der Datei komplett auf; das ist bei mit reproduzierbar unter WinXP und Ubuntu. Ich habe dazu einen neuen Bug eingereicht (Issue 83466, [2], bisher noch Unconfirmed); da der Bugtracker momentan nicht erreichbar ist und einige Entwickler ja hier mitlesen, mache ich _hier_ noch ein paar Ergänzungen, die mir inzwischen aufgefallen sind. Wenn der Bugtracker wieder funktioniert, werde ich dort ggf. auch noch einen Querverweis zwischen Issue 82902 und Issue 83466 ergänzen; möglicherweise gibt es einen Zusammenhang, da es sich um ein Derivat desselben Dokuments (Magisterarbeit) handelt. Zu Issue 82902 (OOo korrumpiert ODT-Datei) hatte Andreas (ama) ein paar Hinweise gegeben, was intern passiert: In content.xml und styles.xml scheinen bestimmte Strings falsch kodiert zu werden; dadurch kumulieren (interne) Zeichenfolgen wie _5f und _20 zu Konstrukten wie _5f_5f_5f oder _20_20_20. Tatsächlich fand ich diese _5f in der content.xml meines ODT-Dokuments an 16.376 Stellen. Dieser Bug ist mittlerweile Confirmed und jetzt auch Fixed, was wohl bedeutet, dass ein funktionierender Patch existiert, der in das nächste Release (OOo 2.4) einfliessen wird; das erscheint frühestens im März 2008 und nützt mir daher nichts (Abgabetermin: Februar 2008). Ich habe daher nach den Anleitungen von Andreas unter [1] entsprechende Korrekturen in content.xml vorgenommen (in meiner styles.xml findet sich keiner der genannten Strings, und in content.xml gibt es nur Kumulationen von _5f, nicht jedoch von _20). Am 2.11. führte ich an der content.xml einer noch von OOo öffenbaren ODT-Datei quasi als Wartungsarbeiten die besagten 16.376 Ersetzungen durch (die zweite beschädigte Datei ließ sich dadurch nicht retten; s.u.); nach den 16.376 Ersetzungen von _5f_5f durch _5f war keine Veränderung erkennbar, sprich: das Dokument sah aus wie vorher und ließ sich problemlos öffnen und bearbeiten. Die ODT-Datei, die seit gestern (8.11.) OOo unter WinXP und Ubuntu komplett abschiesst, ist ein Derivat dieser möglicherweise kaputtreparierten korrumierten ODT-Datei (= dritte korrupte ODT-Datei binnen drei Wochen). Ich habe in dieser zerschossenen Datei erneut eine Kumulation dieses _5f-Strings gefunden, wieder 8188+4096+2048+1024+512+256+128+64+32+16+8+4 (= 16.376) Ersetzungen nach dem obigen Schema durchgeführt und content.xml in das ODT/ZIP-Archiv zurückgeschrieben. Wohlgemerkt, diese Kumulation von 16.376 Duplikationen des Strings _5f entstand binnen _einer_ Woche - in dem Ausgangsdokument vom 2.11. hatte ich ja bereits 16.376 Ersetzungen durchgeführt und damit _jegliche_ Dopplungen beseitigt. Bezüglich des neuen Bugs (Issue 83466, [2]) ist nun anzumerken, dass die besagte _zweite_ Ersetzung des _5f-Strings _keinerlei_ Abhilfe schafft. _Sowohl_ die ODT-Datei _mit_ als auch die _ohne_ diese Stingverdopplung in der content.xml schiesst OOo ab. Es handelt sich daher m.E. um einen _neuen_ Bug, der zwar möglicherweise mit Issue 82902 in Verbindung stehen und/oder durch die o.g. Fixes verursacht werden könnte, nichtsdestotrotz ist es ein anderer Fehler. Das zweite rekonstruierte Dokument vom 2.11. (= Derivat der letzten öffenbaren Dateiversion vom 31.10.) konnte ich wieder knapp eine Woche lang problemlos bearbeiten; die Abstürze/Deadlocks/Aufhänger von OOo (nähere Beschreibung unter [2]) traten erstmals auf, nachdem ich (a) ein knappes Dutzend (= 10) Überschriften im Navigator umbenannt und (b) eine Handvoll (= 6) Abbildungen in einem Tabellenraster eingefügt hatte. Das sind jedenfalls die Operationen, die _direkt_ und mehrfach zum Aufhängen von OOo führten. Möglicherweise ebenfalls überfordert könnte OOo mit Tabellenüberschriften sein, die um 90° rotiert sind (seit 1.11. im Dokument). @mru, mba und ama: Ich kann wieder anbieten, die vermutlich defekte ODT-Datei per E-Mail zur Verfügung zu stellen. Damit die Verwirrung nicht ausufert, abschließend noch eine kurze Übersicht: * 22.06.2007 - Anlegen des Dokuments * 23.10.2007 - ERSTE korrupte ODT-Datei - diese Version hat mba * 24.10.2007 - Issue 82902, [1] * 25.10.2007 - Weiterarbeiten mit der letzten öffenbaren Dateiversion vom 17.10., manuelle Rekonstruktion der zwischenzweit- lichen Änderungen, da bisher keine Anleitung zur Reparatur vorliegt * 01.11.2007 - ZWEITE korrupte ODT-Datei * 01.11.2007 - Weiterarbeiten mit der letzten öffenbaren Dateiversion vom 31.10., manuelle Rekonstruktion der zwischenzweit- lichen Änderungen, danach Fixes wie oben beschrieben nach Anleitung von ama zu Issue 82902 * 08.11.2007 - DRITTE korrupte ODT-Datei (Öffnen des Dokuments schießt OOo komplett ab) * 08.11.2007 - Issue 83466, [2] MfG -Agon [1]
[de-users] Rahmenvorlage aktualisieren
Hallo, ich versuche gerade, eine Rahmenvorlage (Marginalie) in OpenOffice.org Writer 2.3.0, deutsche Version, Windows XP SP-2, zu verändern; sie soll prinzipiell einfach nur einen Zentimeter breiter werden und dafür einen Zentimeter weiter links beginnen (also bspw. im Dialog Typ: Breite statt 2,00 cm jetzt 3,00 cm und Typ: Position: Horizontal: Von links statt 15,00 cm nun 14,00 cm). Unter Verwalten ist in der Dialogbox Autom. aktualisieren markiert. Die Änderung der Rahmenvorlage wirkt sich jedoch nicht auf die entsprechenden Rahmen im Dokument aus; sie bleiben einfach an dem alten Position (15 cm von links) und haben weiterhin eine Breite von 2,00 cm. Im Objektmenü des Rahmens (rechts Maustaste) habe ich nun versucht, die Formatierung des Rahmens zu ändern; das funktioniert, wirkt sich aber nur auf genau diesen Rahmen aus; dann habe ich unter Formatvorlagen, Neue Vorlage aus Selektion, Vorlage aktualisieren angewählt; auch dies wirkt sich nicht auf die anderen Rahmenvorlagen aus. Nun kann ich jeden Textrahmen mit der Vorlage Marginalie manuel markieren und dann *erneut* die Rahmenvorlage Marginalie zuweisen; das wirkt sich nun *teilweise* auf den Textrahmen aus: er verrückt, wie gewünscht, einen Zentimeter nach links, bleibt aber 2,00 cm breit. Und ja, die o.g. Formatierungen wurden in die Rahmenvorlage Marginale übernommen, jedenfalls steht dort 3,00 cm breit an Position 14,00 cm. Nun müsste ich also jeden Rahmen mit der Vorlage Marginalie manuel neu formatieren, um die Änderungen ins Dokument zu bringen. Soweit ich das Konzept von Vorlagen begreife, besteht ihr Sinn doch eben darin, eine einheitliche Formatierung zu gewährleisten, indem sich Änderungen der Vorlage eben auf alle Objekte auswirken, die mit eben dieser Vorlage formatiert sind. Was mache ich also falsch? Danke mfG, -asb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Und noch einmal: Formatfehler in Teildokument content.xml
Mathias Bauer wrote: Es könnte allerdings sein, dass das reparierte Dokument später irgendwann wieder Ausfallerscheinungen zeigt, wenn du nicht alles erwischt hast. Nicht nur das fiktive reparierte Dokument kann Ausfallerscheinungen zeigen, sondern auch meine manuell rekonstruierte Fassung auf der Basis der letzten von OOo Writer ladbaren Version zeigt solche Ausfallerscheinungen: Die Datei ist nun schon wieder korrumpiert worden; der Fehler lautet diesmal: Formatfehler in Teildokument content.xml an Position 9032,324(Zeile,Spalte) in der Datei entdeckt. OpenOffice.org Writer 2.3.0, deutsche Version, Windows XP SP-2, hat das Dokument zuletzt am 23.10.2007 zerstört, also vor ziemlich genau einer Woche; einen Tag habe ich dann mit der (ergebnislosen) Suche nach einer Reparaturanleitung und technischen Reparaturversuchen an dem Dokument verbraten, am 25. habe ich dann einen weiteren Tag damit verbracht, die Änderungen manuell aus der XML-Datei herauszuangeln und in die letzte von OOo ladbare Fassung vom 17.10. einzufügen; so konnte ich wenigstens einen großen Teil der Änderungen wieder rekonstruieren. Nach nunmehr einer Woche und rund 32 Teilversionen hat OOo das Dokument erneut zerstört; ich müsste jetzt wieder auf die letzte ladbare Version zurückgehen und erneut etwa einen Tag damit verbringen, die Änderungen aus dem Gedächtnis zu rekonstruieren bzw. aus content.xml herauszufischen. Das kann ich vielleicht noch einmal machen, aber nicht jede Woche, zumal meine Nerven ob des Zeitverlusts mittlerweile zunehmend blank liegen. Daher die (absolut ernstgemeinte) Frage an die Listenteilnehmer: Macht es für mich noch Sinn, angesichts dieser offensichtlich massiven Instabilität des OOo-Dateiformats mit OpenOffice.org 2.3 weiterzuarbeiten? Issue 82902 [1] hat im Bug Tracker noch immer den Status: UNCONFIRMED, es ist also nicht ersichtlich, ob überhaupt jemand an dem Fehler arbeitet oder ein Bugfix absehbar ist. Ich bin momentan ausgesprochen ratlos, da mich der Wechsel zu einer bewährten Software natürlich auch wieder enorm Zeit kosten würde, weil ich dort sämtliche Formatierungen und Formatvorlagen erst nachbauen und den Text dann Stück für Stück in die andere Software hineinkopieren müsste. Andererseits macht mich die Aussicht, beim eventuellen Weiterarbeiten mit OpenOffice.org Writer jede Woche mindestens einen Tag für Reparaturarbeiten verbraten zu müssen, mehr als nervös... :-( Danke für jegliche Tipps mfG -asb [1] http://qa.openoffice.org/issues/show_bug.cgi?id=82902 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Und wieder: Formatfehler in Teildokument content.xml
Mathias Bauer wrote: Das hat sich als ein altbekanntes Problem entpuppt, das an anderer Stelle schon erkannt und gefixt wurde (in der 2.3). Dein Dokument scheint ja nun zu zeigen, dass es in der 2.3 noch immer Fälle gibt, wo es auftritt. Mit dem von dir eingesandten Dokument sollten wir dem auf die Spur kommen. Ich könnte auch eine Reparatur anbieten, sofern gewünscht. Sozusagen als Service für das Einsenden. :-) Vielen Dank, aber wie halt meistens in solchen Fällen ist auch dieses Dokument zeitkritisch, daher habe ich den heutigen Tag über versucht, die veränderten Stellen aus content.xml mit Diff-Tools und nach Gedächtnis herauszufischen, diese in letzte funktionierende Version wieder einzubauen und dann an der Arbeit weitergeschrieben. Mit einer reparierten Fassung könnte ich jetzt noch prüfen, was ich dabei übersehen habe (was natürlich auch nicht schlecht wäre ;) Etwas wichtiger wäre mir grundsätzlich, eine Handreichungzu bekommen, wie ich den Fehler ggf. selbst reparieren kann; beim Googeln habe ich da einige haarsträubende Fälle gefunden, beispielsweise solche, wo das Dokument kurz vor Abgabe einer Examensarbeit zerschrotet wurde, und das würde ich natürlich sehr gerne vermeiden. Alle Reparaturanleitungen, die ich bisher gefunden habe, beziehen sich jedoch auf einen leicht nachvollziehbaren Fall (wie die Ersetzung von office durch ofice in [1]), oder versackten eben ergebnislos. Vielleicht gibt es eine solche generische Anleitung ja auch schon irgendwo, oder kann der Laie den Unicode-Krams in den XML-Dateien eher sowieso nicht reparieren? Noch grundsätzlicher wäre mir *viel* wichtiger, dass das Laden und Speichern von OOo so stabil wie das von Microsoft Word wird, dass also beispielsweise ein Dokument mit kleinen Fehlern von OOo repariert werden kann, oder dass der Parser intelligent genug wird, das Format zu validieren und ggf. zu korrigieren oder wenigstens irgendwie fehlertoleranter zu handhaben. Ich finde es jedenfalls nicht besonders prickelnd, wenn das Laden eines OOo-Dokuments anscheinend wegen eines gekippten Bits oder Bytes komplett scheitern kann - denn das kann, selbst wenn OOo das Dokument nicht selbst beschädigt, immer mal passieren (fehlerhafter Datenträger, Bitkipper bei der Übertragung über Mail/Web/Internet etc.). Nochmal Danke mfG -Agon [1] http://www.ooo-portal.de/index.php?module=pnForumfunc=viewtopictopic=3900highlight=formatfehler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Und wieder: Formatfehler in Teildokument content.xml
Michael Höhne wrote: Bezogen auf deine Fehlermeldung: Dein Programm hat dann wohl den Start 0xxx einer Unicode-Codierung gefunden und erwartet nun 3 Bytes mit der Struktur 10xx. Offenbar ist das letzte Byte aber nicht korrekt. Das könntest du mit einem Hex-Editor überprüfen. Wenn du mir ein Programm sagst, das zuverlässig an eine Spalte 728384 springen kann, dann könnte ich das tatsächlich versuchen ;-/ Wenn ich content.xml mit Ultraedit öffne und an das Dokumentende (also das Ende von Zeile 2) springe, dann sagt mir die Statusleiste: Zeile: 2, Spalte 54174, C und U8-UNI. Ultraedit bietet ansonsten nur die Funktion Gehe zu Zeile/Seite, nicht jedoch so etwas wie Gehe zu Spalte. Wenn ich mit der Suchfunktion nach dem String suchen lasse, den Validome ausgespuckt hat, dann bekomme ich Dutzende von Ergebnissen, so komme ich also auch nicht sicher an die angegebene Spalte. Abgesehen davon wüsste ich selbst dann nicht wirklich, was ich machen könnte; im Hex-Modus sieht bspw. die Stelle .A.1 folgendermaßen aus: 00 41 00 31. Weit und breit beginnt davor und dahinter nichts mit 11 11 0x oder 10 xx. Ich weiß ja nicht einmal, ob die von Validome angegebene Position überhaupt fehlerhaft ist und was OOo erwarten würde. Aber wie gesagt, ich habe leider absolut keine Ahnung davon, wie ich einen Unicode-Text mit einem Hex-Editor bearbeite. MfG -asb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Und wieder: Formatfehler in Teildokument content.xml
Hallo, jetzt hat es mich auch erwischt: Simples Dokument von OOo Writer, keine Grafikeinbindung, kein Computerabsturz etc.; Dokument gespeichert, OOo beendet, Dokument ein paar Stunden später wieder geöffnet - Fehlermeldung: Formatfehler in Teildokument content.xml an Position 2,728380(Teile,Spalte) in der Datei entdeckt. Wie anscheinend üblich, bietet OOo keinerlei Reparatur- oder Rettungsoptionen an für das Dokument, das es gerade mit der anscheinend bekanntermaßen schädlichen Standardeinstellung XML-Format auf Größe optimieren kaputt gemacht hat. Vor ein paar Wochen hatte hier schon einmal jemand eine ähnliche Fehlermeldung und als Antwort den Reparaturtipp [1] erhalten. Entsprechend habe ich das Dokument nun von Validome überprüfen lassen und folgende Fehler erhalten: (a) Dateiname: content.xml Spalte: 1335 Fehler: Die Deklaration des Elementes 'office:document-content' kann nicht gefunden werden. Fehlerstelle: ...ma-instance office:version=1.0office:scripts/office:font-face-decl office:version=1.0 (b) Dateiname: content.xml Spalte: 728384 Fehler: Ungültiges Byte 4 einer 4-byte UTF-8-Sequenz. Fehlerstelle: ...cell table:style-name=Tabelle16.A1 office:value-type=stringtext:p t Laut [1] schreibt OOo wohl grundsätzlich ungültige Deklarationen, weshalb man (a) ignorieren soll. Bei (b) ist als fehlerhaft die letzte 1 deklariert in table:style-name=Tabelle16.A1 Kann mir jemand verraten, was hier ein gültiger Wert sein bzw. was Ungültiges Byte 4 einer 4-byte UTF-8-Sequenz bedeuten könnte? MfG -asb [1] http://www.ooo-portal.de/index.php?module=pnForumfunc=viewtopictopic=3900highlight=formatfehler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Buch mit Writer: gerade/ungerade Kopfzeilen
Hallo Matthias, Die Kopfzeile soll auf den linken Seiten linksbündig starten und auf den rechten Seiten rechtsbündig. Der Inhalt der Kopfzeile soll auf der linken Seite die Kapitelüberschrift sein und rechts eine Überschriftsebene darunter. Wenn ein Kapitel auf einer rechten Seite beginnt wird diese Seite oft anders behandelt. Der Inhalt der Kopfzeilen startet erst ab Seite 10. Ich glaube, das ist ein ganz ähnliches Problem wie das, nach dem ich gestern gefragt hatte (siehe [1]). M.E. hat OOo Writer einen Bug in den Feldfunktionen für Kapitelnummer und -name; zumindest bei mir werden die entsprechenden Felder für Ebene 2 reproduzierbar falsch ausgelesen bei einem Kapitelwechsel auf Gliederungsebene 1 und damit bei einem Seitenwechsel. Kannst Du mal nachschauen, ob das bei deinem zweiseitgen Layout auch immer dann auftaucht, wenn auf der rechten Seite ein neues Kapitel beginnt? Bei den Folgeseiten funktioniert es bei mir jedenfalls mit der Felddefinition aus [1] MfG -Agon [1] Betreff Writer: Programm-/Benutzer-Fehlfunktion bei lebenden Kopfzeilen und Seitenvorlagen? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Writer: Programm-/Benutzer-Fehlfunktion bei lebenden Kopfzeilen und Seitenvorlagen?
Hi, nach gut einem Monat OOo Writer scheitere ich an lebenden Kopfzeilen und Seitenvorlagen; vielleicht sind das Bugs, vielleicht verstehe ich aber auch einfach nicht, wie's richtig gemacht werden soll. (a) Lebende Kopfzeilen ...sollen aussehen wie die Bezeichnung sagt, also bspw. [Kap-# 1]. [Kap-Titel 1] - [Kap-# 2]. [Kap-Titel 2] [Seite-#] (Sprich: Kapitelnummer erste Ebene, Kapiteltitel erste Ebene, Trennzeichen, Kapitelnummer zweite Ebene, Kapiteltitel zweite Ebene; formatiert ist das durch eine kleine Tabelle, der Kapitelblock linksbündig, die Seitennummer rechtsbündig, das hält auch eventuelle überlange Kapiteltitel zusammen). Das kann man scheinbar leicht zusammenklicken mit den Feldbefehlen: * [Kap-# 1] = Feldtyp: Kapitel; Format: Kapitelnummer ohne Trennzeichen; Ebene: 1 * [Kap-Titel 1] = Feldtyp: Kapitel; Format: Kapitelname; Ebene: 1 * [Kap-# 2] und [Kap-Titel 2] entsprechend, nur jeweils für Ebene 2. In der Praxis sieht das dann aber so aus, dass - sehr unsystematisch wirkend - in den Kopfzeilen sowohl manchmal [Kap-# 1]. [Kap-Titel 1] - [Kap-# 1]. [Kap-Titel 1] zu finden als auch und manchmal das gewünschte [Kap-# 1]. [Kap-Titel 1] - [Kap-# 2]. [Kap-Titel 2]; alles bezogen jeweils auf Seiten, in denen mindestens beide Verzeichnisebenen existieren. Soweit ich das sehe, tritt das falsche Auslesen der Kapitel-Felder immer am Anfang eines neuen Kapitels auf Ebene 1 und damit nach einem Seitenumbruch auf. Bug oder Benutzerfehler? (b) Seitenvorlagen Scheinbar auch ganz simpel, in der Praxis jedoch nicht lösbar für mich: Ein paar Seiten ohne Fuß-/Kopfzeilen, denn eventuell ein paar Seiten mit alternativen Kopf-/Fußzeilen und schließlich der restliche Salm mit regulären Fußzeilen - als prinzipiell ein Aufbau, wie ihn viele Dokumente Brief haben. Seitenlayout einseitig oder Links/Rechts ist erstmal egal. Die Umsetzung scheint auch hier wieder einfach, OOo Writer hat standardmäßig alle notwendigen Seitenvorlagen: * Erste Seite für ebendiese (Titel etc., ohne Kopf-/Fußzeilen) * Verzeichnis für ebendiese (entweder ohne Kopf-/Fußzeilen oder mit alternativen Kopf-/Fußzeilen) und * Standard für den restlichen Salm (mit Kopf-/Fußzeilen) Folgevorlage von Erste Seite ist Verzeichnis, dessen Folgevorlage ist Standard; überall außer bei Standard ist in der Seitenvorlage im Reiter Kopfzeile die Checkbox Kopfzeile einschalten weggeklickt. Zugewiesen habe ich die Seitenvorlagen, indem ich zu der entsprechenden Seite gehe und dann in den Formatvorlagen (F11) auf die entsprechende Seitenvorlage doppelklicke. Trotzdem haben die Seiten mit der Seitenvorlage Verzeichnis noch immer Kopfzeilen; springe ich dann von Seite [irgendwo] zur ersten Seite, die die Seitenvorlage Erste Seite haben sollte, springt die Markierung in den Formatvorlagen auf irgendwas, z.B. Verzeichnis. Erstreckt sich ein Inhaltsverzeichnis über mehr als eine Seite, haben die Folgeseiten plötzlich die Vorlage Standard. Weise ich der zweiten Verzeichnisseite das Seitenformat Verzeichnis zu, hat die erste Seite des Verzeichnisses plötzlich wieder das Seitenformat Standard (nach Markierung in den Formatvorlagen bzw. Angabe in der Statusleiste). Falls die Seitenvorlagen nicht bis zur Definition einer anderen Vorlage sondern nur für _genau_ eine Seite gelten sollten, habe ich versucht, als Folgevorlage von Verzeichnis wieder Verzeichnis einzustellen und dann einen manuellen Seitenumbruch einzufügen (Menü Einfügen/ Umbruch einfügen/ Seitenumbruch/ Vorlage: Standard). Das führt jedoch zu einer Leerseite nach dem Verzeichnis (Kapitel erste Ebene beginnen sowieso auf einer neuen Seite) mit der Seitenvorlage Standard (also mit Kopfzeile), ist also auch nicht wirklich schön. Da ich mir nicht vorstellen kann, dass OOo bei so einer Grundfunktionen einen Bug haben soll, wäre also die Frage, was ich verkehrt mache ;-/ Danke mfG -Agon PS: Dank an Lars und Mathias für die Hinweise zu Tastenkürzeln und Querverweisen. Für meinen Bedarf umgestrickte Shortcuts, die sich stärker an den Konventionen der Microsoft-Welt orientieren, habe ich unter [1] veröffentlicht. Falls Interesse an einem vollständigen alternativen Shortcut-Layout bestehen sollte, einfach dort posten. [1] http://www.kefk.org/portal/projekte/ooo-writer/0.2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Umsteigerprobleme: Tastenkürzel, Symbolleiste n, Querverweise
Hallo, hier ist wieder mal einer, der einen Umstieg auf OOo versucht ;) In den letzten Tagen bin ich auf drei Probleme gestoßen, die ich weder durch Googeln noch durch das Archiv dieser Mailingliste lösen konnte; ich verwende den Writer aus OOo 2.1 unter Windows XP. Ad 1) Symbolleisten Ich benutze beim Schreiben überwiegend Tastenküzel und würde daher gerne sukzessive diejenigen Symbolleisten _dauerhaft_ loswerden, die ich ohnehin nicht benutze. Das betrifft momentan vor allem die Leiste Standard, die ich also abgerupft und geschlossen habe (via Symbolleiste schließen bzw. [x]-Button auf der Symbolleiste). Die Leiste poppt nun aber _jedesmal_ auf, wenn ich in einen Absatz mit einer anderen Formatvorlage (Fließtext, Überschrift, Kopfzeile usw.) gehe - also praktisch ununterbrochen. Bei kontextsensitiven Symbolleisten (Tabellen, Überschriften etc.) macht das ja vielleicht Sinn, nicht jedoch bei Symbolleisten, die ich eigentlich explizit weggemacht habe. Mit der Zeit nervt das ungemein, da die recht große Leiste ziemlich viel Text verdeckt. Frage: Ist das einfach ein Bug in OOo 2.1, oder gibt es irgendwo eine Möglichkeit, die bestimmte Symbolleisten _dauerhaft_ abzuschalten? Ad 2) Tastenkürzel Die Tastenkürzel von Microsoft-Programmen finde ich größtenteils sinnvoll, jedenfalls bin ich sie beim Blindschreiben so gewohnt, dass ich sie gerne beibehalten würde; wenn das nicht geht, hätte ich gerne zumindest äquivalente Tastenkürzel, aber ich weiß natürlich nicht, wie weit sich OOo überhaupt an die CUA-/SAA-Standards halten möchte. Jedenfalls habe ich bisher weder einen Kompatibilitätsmodus oder eine (nach-) ladbare, Office-kompatible Tastenbelegung gefunden, noch eine Möglichkeit entdeckt, mir die Tasten selbst zu belegen. Ein Beispiel: In allen MS-Office-Programmen springt man mit Ctrl+Pfeiltaste absatzweise; in OOo _verschiebe_ ich damit einen kompletten Absatz. Das bringt mir nichts, weil ich häufiger im Text springe als ganze Absätze durch die Gegend schubse. Wenn ich in Tastaturbfehle für Textdokumente in der Online-Hilfe nichts übersehen habe, gibt es in OOo überhaupt kein absatzweises Springen. Auch unter Extras/Anpassen/Tastatur finde ich keine entsprechende Funktion, die ich auf die Testen mappen könnte (allerdings kann ich einige Einträge in dem Dialogfenster Anpassen nicht so recht lesen, weil die Boxen für Bereich und Funktion so winzig sind, dass man ständig vertikal scrollen muß). Frage: Hat jemand vielleicht schon eine MS-Office-kompatible Tastaturbelegung nachgebaut? Wenn nicht: Wie kann ich die fehlenden Tastenkürzel selbst nachrüsten, die unter Extras/Anpassen/Tastatur nicht aufgeliestet sind (daher hilft mir auch beispielsweise [2] nich tso recht)? Ad 3) Querverweise (a) Ich habe jetzt mehrfach versucht, in einer Fußnote einen Querverweis einzufügen, wobei mir mehrfach der Writer abgeschmiert ist. Ist das ein bekannter Bug oder nur Zufall? (b) Zweitens blicke ich anscheinend durch das OOo-Konzept hinter den Querverweisen noch nicht so recht durch; sehe ich das richtig, dass beispielsweise Überschriften bzw. Kapitel nicht automatisch als Verweisziele zur Verfügung stehen, sondern ich grundsätzlich immer _jedes_ Verweisziel erst manuell deklarieren muß, bevor ich einen Verweis darauf setzen kann? Merci! MfG -asb P.S. Kurz zum Hintergrund: Früher (90er Jahre) habe ich auf verschiedenen Plattforemen mit WordPerfect gearbeitet, bin dann an WPWin verzweifelt (ständige Programmabstürze und beschädigte Dokumente) und dann zu Word und FrameMaker gewechselt (Windows). Mit der Kombination war ich zwar annähernd absolut zufrieden (keine Abstürze, keine beschädigten Dokumente, toller Funktionsumfang, intuitive Bedienung), da es aber beides für zukunfträchtige Betriebssysteme nicht gibt, quäle ich mich jetzt mit OOo. OpenOffice habe ich zwar von Anfang an immer wieder ausprobiert, es gab aber immer zu vieles, was für mich nicht funktioniert hat; daher habe ich aus Zeitdruck und/oder Bequemlichkeit wieder meine gewohnten (bewährten, zuverlässigen) Programme verwendet. Da für mich über kurz oder lang ein kompletter Wechsel zu GNU/Linux ansteht, will ich jetzt versuchen, mich mit OOo anzufreunden. OpenOffice.org soll dabei eher Word als Frame ersetzen, wobei mir allerdings einige Elemente von OOo aus Frame bekannt vorkommen ;) [1] http://www.ooowiki.de/KonkordanzDatei [2] http://www.ooowiki.de/TastaturAnpassen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
