nenem
Anmeldungsdatum: 9. Juni 2006
Beiträge: 946
|
Hallo zusammen, leider habe ich LO 6.0.7.3 einen Bug entdeckt, der für mich sehr ärgerlich ist, weil ich die Funktion oft nutze: Beim Abspeichern von Writer-Dokumenten mit Tabellen und der Nutzung von "Autoformat", werden die Umrandungen und Linien elimiert. Das Problem wurde mit mit LO 6.3.0.1 reproduziert. Mit LO 4.2.8.2 (Ubuntu 14.04) und LO 5.1.6.2 (Ubuntu 16.04) tritt es nicht auf. Nachgestellt werden kann es mit wenigen Handgriffen: Writer-Dokument anlegen → Tabelle einfügen (2-3 Spalten und einige Zeilen genügen) → Tabelle → Autoformat: irgendeine Tabelle mit eingefärbten Zeilen → abspeichern im html-Format → im Browser aufrufen Gemeldet ist der Bug in der entsprechenden LO-Mailingliste. Falls er behoben wird, muss ich notgedrungen die dann reparierte ppa-Version installieren. Bis dahin benötige ich eine provisorische Lösung. Einige Ansätze habe ich (z.B. Installation von Ubuntu 16.04 in virtueller Maschine oder auf gesonderter, externer Festplatte, Weiterarbeit mit einem Rechner, auf dem noch Ubuntu 14.04 installiert ist, bis zur Lösung des Problems und erst dann Neuinstallation von 18.04). Befriedigend aber ist die Situation nicht. Deshalb meine Frage hier: Hat jemand eine Idee für einen Workaround, mit dem sich der Fehler "händisch" korrigieren lässt? Viele Grüße nenem
|
Frieder108
Anmeldungsdatum: 7. März 2010
Beiträge: 8989
|
Moin, ich nutze unter 18.04 das LO 6.2.5 aus dem "stable-PPA" - ich häng mal ein Bild mit deiner "Anleitung an → für mich schaut das .html im FF eigentlich genau so aus, wie das Original .odt in Libreoffice. Aber vllt. meinst du auch was ganz anderes und ich habe es nur nicht richtig verstanden. ☺ Grüßle, Frieder
- Bilder
|
nenem
(Themenstarter)
Anmeldungsdatum: 9. Juni 2006
Beiträge: 946
|
Doch, hast Du richtig verstanden - nur bei Deinem eigenen Beispiel den Unterschied nicht gesehen 😉 Dein Screenshot von der Browserdarstellung (links) zeigt doch deutlich, dass die Linien und Umrandungen von der LO-Darstellung (rechts) verschwunden sind. Mach den Test mal mit 3 Spalten und mehr Zeilen (und evtl. mit einer anderen Autoformat-Vorlage, wie z.B. "Braun"), dann erkennst Du den Unterschied deutlicher. Viele Grüße nenem
|
Frieder108
Anmeldungsdatum: 7. März 2010
Beiträge: 8989
|
ah ok, ja, hast recht - jetzt seh ich, was du meinst. Dann betrachte meinen Beitrag als Bestätigung des Bugs auch für LO 6.2.5 → eine Lösung dazu weiß ich leider auch nicht. ☹
|
umbhaki
Supporter
Anmeldungsdatum: 30. Mai 2010
Beiträge: 2522
Wohnort: Düren/Rhld
|
Hier LibreOffice 6.3.0.3 mit der Extension Writer2xhtml. Folgendes habe ich mit einer kleinen Tabelle in einem Writer-Dokument namens „Klamotten.odt“ ausprobiert: (1) Gespeichert mit Speichern unter … und HTML-Dokument ausgewählt. Da erscheint ein Warnhinweis, der sich anschließend auch bewahrheitet → es tritt der von dir beschriebene Fehler auf (Klamotten1.html) (2) Gespeichert über Exportieren… und hier das Format »XHTML« ausgewählt. Die Rahmenlinien sind vorhanden (Klamotten2.html). (3) Gespeichert über Exportieren… und jetzt das Format »HTML 5 [writer2xhtml]« ausgewählt. Die Rahmenlinien sind ebenfalls vorhanden (Klamotten5.html). Die Wege (1) und (2) sind ohne die erwähnte Extension machbar, das ist „Serienzubehör“ von LibreOffice. Weg (3) erfordert die oben erwähnte Extension, die dann auch noch einige Einstellmöglichkeiten in petto hat. Möglicherweise genügt aber Weg (2) bereits für dich. Siehe Anhänge.
- Klamotten.odt (13.6 KiB)
- Download Klamotten.odt
- Klamotten1.html (10.7 KiB)
- Download Klamotten1.html
- Klamotten2.html (12.6 KiB)
- Download Klamotten2.html
- Klamotten5.html (9.7 KiB)
- Download Klamotten5.html
|
nenem
(Themenstarter)
Anmeldungsdatum: 9. Juni 2006
Beiträge: 946
|
Danke für die Hinweise. Zu (1): Das ist der Staus Quo - also fehlerhafte Erstellung der html-Datei. Zu (2): Machbar mit einer neu erstellten Tabelle, weil sie "Laborbedingungen" entspricht. Ich aber habe eigene html-Vorlagen im oth-Format - und bei denen funktioniert es nicht: Die Funktion Exportieren als wird gar nicht erst angeboten - nur Exportieren. Und die wiederum enthält kein html-Format (auch nicht XHTML). Abgesehen davon: Hast Du Dir bei Deiner eigenen Beispieldatei Klamotten2,html mal den Quelltext angesehen? Ziemlich wirres Zeug für mich. Da ich nach dem Generieren von html-Seiten anschließend immer die Quelltexte bearbeiten muss, ist diese Option ausgeschlossen. Etwas besser sieht es aus bei (3) - aber nicht viel besser: Auch dieser Quelltext ist sehr unübersichtlich. Sowohl bei (2) als auch bei (3) hätte ich irgendwann - wenn der Bug behoben ist - viel zu tun, um wieder Seiten mit besseren Quelltexten zu erstellen. Übrigens ist der Bug inzwischen eindeutig ausgemacht. Beim Vergleich zwischen einer korrekten Umsetzung (LO 4) mit einer fehlerhaften (LO 6) ist erkennbar, dass die von LO 6 mit zusätzlichem Quelltext durchsetzt ist. Ausgangsbedingungen des Vergleichs: Writer-Dokument mit einer Tabelle, die 3 Spalten und 10 Zeilen hat, Autoformat: "Braun". Nach dem Abspeichern als html-Dokument findet sich insgesamt 30x der Ausdruck style="background: xxx" - also genau so oft, wie es bei diesem Beispiel Zellen gibt: 3x style="background: #663300", 9x style="background: #996633" und 18x style="background: #ffcc99". Nachdem alle gelöscht sind, stellt sich die Seite auch im Browser korrekt dar. Der Workaround wäre also, genau diese Löschungen mit einem Texteditor vorzunehmen. Ziemlich aufwändig, aber machbar. Ich hoffe nur, dass der Bug so bald wie möglich behoben wird.
|
gueba
Anmeldungsdatum: 12. Juni 2008
Beiträge: 335
|
Also Fakt ist, dass nur (2) fehlerfrei validiert (auch unter LO 6.0.7.3)
Die Unleserlichkeit resultiert nur aus dem Fehlen von Zeilenumbrüchen. Einmal in den //wiki.ubuntuusers.de/Webeditoren/#XML-Copy-Editor: geladen, mit –>XML –>Druckaufbereitung formatiert ergibt schönen Quelltext. Im Dateidialog "Exportieren" wird sehr wohl die Option "XHTML (.html;xhtml)" angeboten.
Möglicherweise sind auch deine html-Vorlagen fehlerhaft (veraltet). (3) ist zwar fehlerbehaftet, was hier unübersichtlich sein soll, erschließt sich mir nicht. (1) ist voller Fehler, da wie du ja bemerkt hast, das style-Attribut doppelt angewendet wird. Ein bißchen "Search & Replace" in z.B. Geany erledigt das aber relativ schnell.
Da ich nach dem Generieren von html-Seiten anschließend immer die Quelltexte bearbeiten muss, ist diese Option ausgeschlossen.
Das verstehe ich nicht. Warum erstellst du Seiten in Office, generierst daraus html und musst dieses dann noch bearbeiten?
|
nenem
(Themenstarter)
Anmeldungsdatum: 9. Juni 2006
Beiträge: 946
|
gueba schrieb: Also Fakt ist, dass nur (2) fehlerfrei validiert (auch unter LO 6.0.7.3)
Die Unleserlichkeit resultiert nur aus dem Fehlen von Zeilenumbrüchen. Einmal in den //wiki.ubuntuusers.de/Webeditoren/#XML-Copy-Editor: geladen,
Der Link enthält nichts - bzw. nur Fehlender Artikel Edit: Nur nebenbei: Ich war auf der Suche nach einem Workaround bis zur Behebung des Bugs - und nicht nach einer ganz anderen Methode, Webseiten zu generieren: https://wiki.selfhtml.org/wiki/XHTML und https://wiki.selfhtml.org/wiki/HTML/Unterschiede_von_HTML_zu_XHTML
mit –>XML –>Druckaufbereitung formatiert ergibt schönen Quelltext. Im Dateidialog "Exportieren" wird sehr wohl die Option "XHTML (.html;xhtml)" angeboten.
Lustig, dass Du weißt, was ich sehe 😉 Öffne ich eine meiner hmtl-Vorlagen und will sie nach Bearbeitung als html-Writer-Dokument exportieren, gibt es keine Option "XHTML (.html;xhtml)". Die finde ich nur bei einem neu erstellten Dokument.
Möglicherweise sind auch deine html-Vorlagen fehlerhaft (veraltet).
Alt ja, aber fehlerhaft? Warum sollten sie fehlerhaft sein? Ist letztlich auch müßig: Das ganze Export-Thema spielt ja ohnehin nur eine Rolle, weil es derzeit beim Abspeichern einer Datei mit Tabelle und Autoformat diesen Bug gibt.
(3) ist zwar fehlerbehaftet, was hier unübersichtlich sein soll, erschließt sich mir nicht. (1) ist voller Fehler, da wie du ja bemerkt hast, das style-Attribut doppelt angewendet wird. Ein bißchen "Search & Replace" in z.B. Geany erledigt das aber relativ schnell.
Ja, ich habe es in des Tests mit Pluma erledigt. Ist halt unangenehm, dass ich wegen des LO-Bugs ständig Extraarbeit habe,
Da ich nach dem Generieren von html-Seiten anschließend immer die Quelltexte bearbeiten muss, ist diese Option ausgeschlossen.
Das verstehe ich nicht. Warum erstellst du Seiten in Office, generierst daraus html und musst dieses dann noch bearbeiten?
Ganz einfach: weil Quelltexte hinein sollen, die LO nicht generiert (z.B. Meta-Tags) - ohne dass sie mir anschließend durch den Generator zerschossen werden. Das ist mit LO-Bordmitteln nicht zu machen - war es bisher jedenfalls nicht. So, wie ich es bisher sehe, ist das Editieren der hmtl-Datei und Entfernen der genannten Begriffe offenbar der einzige Workaround. Schade, ich hatte gehofft, dass das Problem durch Bearbeiten/Korrigieren einer Datei aus der Welt zu schaffen ist - also quasi durch "händische Bugbeseitigung".
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Der Link, den gueba meinte war: Webeditoren (Abschnitt „XML-Copy-Editor“) Ich kann das auch nachstellen und die doppelten Style-Einträge scheinen wirklich das Problem zu sein. Ich weiß nun nicht, wie deine Arbeitsweise aussieht, aber man könnte das mit einem Einzeiler lösen. Entfernt aber ALLE Einträge dieser Art! sed -i 's/style="background: #......" //g' DATEINAME
|
nenem
(Themenstarter)
Anmeldungsdatum: 9. Juni 2006
Beiträge: 946
|
ChickenLipsRfun2eat schrieb: Der Link, den gueba meinte war: Webeditoren (Abschnitt „XML-Copy-Editor“)
Ach so.. Naja, wie gesagt: Ich will derzeit bei der Erstellung von Webseiten keine ganz andere Richtung einschlagen - was beim Umsatteln auf XHMTL aber der Fall wäre.
Ich kann das auch nachstellen und die doppelten Style-Einträge scheinen wirklich das Problem zu sein.
Ja, sind es definitiv - ein Fehler/Bug in LO 6 beim Generieren von html-Seiten. Ich warte auf Behebung des Problems. Wenn es tatsächlich geschehen sollte, deinstalliere ich die LO-Version aus den Paketquellen und installiere die ohne Bug als ppa. Mache ich ungern, so etwas, aber mir dürfte nichts anderes übrigbleiben, denn eine neuere Version wird wohl nicht in die Paketquellen (von Ubuntu 18.04) kommen.
Ich weiß nun nicht, wie deine Arbeitsweise aussieht, aber man könnte das mit einem Einzeiler lösen. Entfernt aber ALLE Einträge dieser Art! sed -i 's/style="background: #......" //g' DATEINAME
Mit sed habe ich schon gearbeitet - allerdings zielgerichtet, um ein klar umrissenes Problem zu lösen. Ist auch schon wieder 1-2 Jahre her. Kann also nicht behaupten, dass ich im Umgang damit fit genug bin. Soweit ich mich erinnere, ist der Einzeiler ja nicht alles und vorher per Kommandozeile ein Navigieren bis in das richtige Verzeichnis hinein nötig. Mal sehen... Evtl. vergleiche ich mal, was schneller geht. BTW: Tatsächlich müssen alle Einträge dieser Art weg.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Das kommt ein wenig auf deine Arbeitsweise an. Es gäbe die Möglichkeit den Befehl in einen Alias zu verpacken, ein Script unter ~/bin abzulegen, einen Kontextmenü-Eintrag für den Dateimanager zu erstellen, das ganze auf komplette Verzeichnisstrukturen anzuwenden (z.B. mit find), uvm. Zur sed-Zeile: Die ersetzt alle (global, das kleine g am Ende) Vorkommen von style="background: #......" (wobei die Punkte Platzhalter sind) durch nichts, also löscht die betreffenden Elemente raus. Das -i bewirkt, dass die Änderungen direkt in die Datei geschrieben werden, die unter DATEINAME angegeben wurde. Man könnte den Suchausdruck hübscher schreiben, und auf Hex-Werte begrenzen, aber für mich reicht das so ☺
|
gueba
Anmeldungsdatum: 12. Juni 2008
Beiträge: 335
|
Der Link, den gueba meinte war: Webeditoren (Abschnitt „XML-Copy-Editor“)
gut erkannt, ich gelobe Besserung.
|
hakel
Anmeldungsdatum: 13. August 2009
Beiträge: 23336
|
Das kommt ein wenig auf deine Arbeitsweise an.
Sehe ich auch so ... Bei mir hat Libre in der Vergangenheit meinen ganzen Code regelmäßig "zertrümmert", und mit jedem Release kam etwas Neues hinzu. Irgendwann gab es dann mal einen Riesenbug, dann hatte ich die Nase voll. Ich erzeuge jetzt eine völlig "nackte" Tabelle mit Libre und lagere das Layout komplett in css aus, bzw. versuche es nachzubilden. Inzwischen habe ich mir allerdings so einen "Baukasten" zugelegt, um die Arbeit zu delegieren.
|
gueba
Anmeldungsdatum: 12. Juni 2008
Beiträge: 335
|
Wenn du mit dem Export nach XHTML leben kannst, ginge Folgendes:
Vorlage.oth öffnen - bearbeiten Export nach fertige_Seite.odt fertigeSeite.odt öffnen Export nach fertigeSeite.html
Du hättest dann zumindest valides xhtml für die Zeit bis der Bug gefixt ist und könntest diese nachträglich in html speichern.
|
Rorohiko
Anmeldungsdatum: 7. August 2007
Beiträge: 286
|
Hallo nenem! Ich habe Deinen Beitrag gelesen und mit der veröffentlichten LO Version: 6.3.0 (6.3.0.4) nachvollzogen und wenn ich es richtig verstanden habe, kommt daß von Dir gewünschte Ergebis dabei heraus. Glück auf! Rorohiko
- Mist.html (10.0 KiB)
- Download Mist.html
|