[de-discuss] Re: [de-discuss] LO 6.0.7.3: Unerwünschte Formatierungen von "Autoformat" bei Writer-Tabellen
Hallo Rainer, nun, ich kein Entwickler, kann Dir aber evt. ein wenig Licht in die Sache bringen - ohne einen "Königsweg" zu wissen: Historisch war "Autoformat" an sich eine "Krücke", das Format für jede einzelne Zelle wurde hart - also direkt - auf die zu formatierende Zelle übertragen eben entsprechend der definierten Autoformat-Vorlage. Danach gab es keine Verbindung mehr zu der ursprünglichen Vorlage. Gewünscht wurde seit langen auch für Tabellen ein "Vorlagensystem"- ähnlich wie für Absatz - und Zeichenvorlagen. Also, durch ändern der Vorlage würde sich die damit formatierte Tabelle automatisch ändern. Das ganze wurde im Rahmen eines Google Code of Summer Projektes realisiert, jedoch nicht beendet. Es fehlten noch irgendwelche Dialoge und über die Funktionsweisen des Codes kann ich wenig sagen. Zunächst wurde einfach das System des Autoformats übernommen - ohne Möglichkeiten der Änderung oder Hinzufügung. Der Code ist nun im System, wahrscheinlich auch aktiv - und führt zu den Phänomenen. Das heisst: Wenn Du eine Tabelle mit Autoformat formatiert hast (also jetzt mit einer Tabellenvorlage) so überschreibt diese die harte (direkte) Formatierung. Hab jetzt nicht geschaut, ob der Dialog zum Ändern einer Tabellenvorlage schon realisiert ist - wenn nicht, gibt es keine Möglichkeit die Tabellenvorlage zu ändern. Dann passiert genau das, was Du feststellt. Ist also mit Sicherheit ein Bug, da die (benötigten) Funktionen nicht vorhanden sind, wann und wie das gelöst wird?? keine Ahnung. Viele Grüße Thomas Am 24.08.2019 um 08:58 schrieb Rainer: [..] -- Liste abmelden mit E-Mail an: discuss+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/discuss/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-discuss] Re: [de-discuss] LO 6.0.7.3: Unerwünschte Formatierungen von "Autoformat" bei Writer-Tabellen
Hallo Thomas, Am Sat, 24 Aug 2019 11:39:07 +0200 schrieb Thomas Krumbein : > > Historisch war "Autoformat" an sich eine "Krücke", das Format für > jede einzelne Zelle wurde hart - also direkt - auf die zu > formatierende Zelle übertragen eben entsprechend der definierten > Autoformat-Vorlage. Danach gab es keine Verbindung mehr zu der > ursprünglichen Vorlage. > > Gewünscht wurde seit langen auch für Tabellen ein "Vorlagensystem"- > ähnlich wie für Absatz - und Zeichenvorlagen. Also, durch ändern der > Vorlage würde sich die damit formatierte Tabelle automatisch ändern. > > Das ganze wurde im Rahmen eines Google Code of Summer Projektes > realisiert, jedoch nicht beendet. Es fehlten noch irgendwelche > Dialoge und über die Funktionsweisen des Codes kann ich wenig sagen. > Zunächst wurde einfach das System des Autoformats übernommen - ohne > Möglichkeiten der Änderung oder Hinzufügung. Der Code ist nun im > System, wahrscheinlich auch aktiv - und führt zu den Phänomenen. > > Das heisst: Wenn Du eine Tabelle mit Autoformat formatiert hast (also > jetzt mit einer Tabellenvorlage) so überschreibt diese die harte > (direkte) Formatierung. Hab jetzt nicht geschaut, ob der Dialog zum > Ändern einer Tabellenvorlage schon realisiert ist - wenn nicht, gibt > es keine Möglichkeit die Tabellenvorlage zu ändern. Dann passiert > genau das, was Du feststellt. > Im Prinzip kann ich Deine Erklärung nachvollziehen. Sie ergibt - bezogen auf die Illustrationen auch Sinn. An einem Punkt aber geht das Problem darüber hinaus, und kann IMO so nicht mehr erklärt werden. In meinem Fall handelt es sich nämlich um eine selbst erstellte Vorlage, die ich Autoformat hinzugefügt habe. Der gesamten Tabelle ist eine bestimmte Schriftart und den Zeilen abwechselnd 2 Hintergrundfarben zugewiesen - mehr nicht. Sie enthält ausdrücklich keinerlei Kopf- und/oder Summenzeilen. Meine Definitionen aber werden so nicht übernommen, sondern in Bezug auf Kopf- und letzte Zeilen (und vermutlich auch auf wenigstens rechte Spalten) durch andere ersetzt. Schon mit LO4.x stellte sich mir die Frage, wieso im Moment des Hinzufügens die Vorlage nicht so bleibt, wie ich sie erstellt habe, sondern erster und letzter Zeile nun Formate aufgezwungen werden. Weil ich das Ergebnis durch einen simplen Tausch der Bearbeitungsschritte wieder zurechtbiegen konnte, bin ich der Sache nicht weiter nachgegangen. In der jetzigen LO-Version allerdings hat sich das Problem verschärft: Die Schritte zu tauschen reicht jetzt nicht mehr: Selbst nach Betätigung der Funktion zwingt Autoformat ersten und letzten Zeilen die neue Rolle auf. Mir scheint, dass die Funktion in irgendeiner Weise aktiv bleibt. Ich kann natürlich nicht in die Vorstellungswelten von Entwicklern "eintauchen", aber offenbar gehen sie davon aus, dass alle, die mit Writer-Tabellen arbeiten, sie für Rechenvorgänge benötigen. Kurzum: Autoformat verändert den Charakter selbst erstellter Tabellen auf unerwünschte Weise (bzw. kann es tun, wenn in Zeilen oder Spalten keine Summenrechnungen, Überschriften, o.ä. beabsichtigt sind). > Ist also mit Sicherheit ein Bug, da die (benötigten) Funktionen nicht > vorhanden sind, wann und wie das gelöst wird?? keine Ahnung. > Hmm, falls es auch andere als Bug bewerten, würde ich gern darum bitten, dass jemand ihn meldet. Mit meinem Englisch bekomme ich es nicht vernünftig hin. Viele Grüße Rainer -- Liste abmelden mit E-Mail an: discuss+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/discuss/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-discuss] LO 6.0.7.3: Unerwünschte Formatierungen von "Autoformat" bei Writer-Tabellen
Hallo Rainer, Rainer schrieb am 24-Aug-19 um 08:58: [..] Weiß jemand Näheres über die Gründe, warum "Autoformat" von LO-Generation zu LO-Generation wie beschrieben entwickelt wird - ob es also so gewollt oder doch ein Bug war/ist? Das ganze geht auf ein GSoC Projekt von 2016 zurück https://wiki.documentfoundation.org/Development/GSoC/Successfully_Implemented_Ideas#Table_styles Es ist damals aber nicht wirklich fertig geworden. So werden beispielsweise immer noch eigene Templates binär kodiert in der Datei autotbl.fmt abgelegt und einige wichtige Dinge sind überhaupt nicht implementiert. Hintergrund war, dass "Autoformat" schon seit StarOffice Zeiten so implementiert war, dass das Format beim Zuweisen als direkte Formatierung auf die Tabelle geschrieben wurde und die Datei keine Information über das Template enthielt. Zeilen/Spalten wurden beim Einfügen/Löschen nicht automatisch angepasst. Ein anderer Benutzer konnte keine weitere Tabelle mit dem gleichen Format anlegen. Gegenüber der ursprünglichen Situation ist die jetzige Lösung wirklich ein Fortschritt. Aber es fehlen Leute, die das ganze weiterführen. Ein paar Hintergrundinformationen: Im Dateiformat gibt es die Möglichkeit, ein Tabellentemplate zu definieren. Es enthält die Zell-Formatierungs-Definitionen für erste Zeile, letzte Zeile, ungerade Zeile, erste Spalte, letzte Spalte, ungerade Spalte und für Zellen sonst, sowie für den Tabellenhintergrund. Bei der Tabelle selbst steht dann als Attribute, welches Template benutzt werden soll. Dabei ist es theoretisch möglich nur einzelne Aspekte des Templates zu benutzen. Das ist aber nicht implementiert. Genausowenig ist implementiert, dass der Benutzer direkten Zugriff auf die im Template referenzierten Zell-Formate hat. Außerdem fehlt die Implementierung, ein in der Datei vorhandenes Template zu exportieren. In dieser Situation gibt es z.Zt. keine Möglichkeit, loszuwerden, dass die letzte Zeile besonders behandelt wird. In deinem Fall würde ich daher gar nichts in dieser Richtung probieren, sondern einfach die letzte Zeile leer lassen und auf Zeilenhöhe 0cm setzen. Mit freundlichen Grüßen Regina -- Liste abmelden mit E-Mail an: discuss+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/discuss/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
[de-discuss] Probleme mit dem Calc-Funktion Zufallsbereich seit der Version 6.2
Hallo zusammen, das Verhalten der Calc-Funktion Zufallsbereich() hat sich seit der Version 6.2 geändert. Mit jeder Aktualisierung (F9 oder Änderung einer Zelle) werden nun die Zahlen in Zufallsbereich geändert. Zuvor war es so, dass man Strg-Umschalt-F9 drücken musste, um eine Änderung zu erzwingen. Das alte Verhalten ist viel viel brauchbarer, da man damit phantastische Lernprogramme erstellen kann (siehe auch www.meudela.de) Ich bitte darum, dass das alte Verhalten in zukünftigen Versionen wieder eingestellt wird. Die ursprüngliche Version stellt für mich und meine Lernenden ein unglaublicher Vorteil gegenüber Excel dar, was mit Calc bis Version 6.1 realisiert werden konnte ist mit Excel kaum möglich. Kann mir jemand mich in meinem Anliegen unterstützen, ich bin neu hier, was muss man da anstellen? Viele Grüße Joachim Kreutzer -- Liste abmelden mit E-Mail an: discuss+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/discuss/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-discuss] Probleme mit dem Calc-Funktion Zufallsbereich seit der Version 6.2
Hallo Joachim, > > das Verhalten der Calc-Funktion Zufallsbereich() hat sich seit der > Version 6.2 geändert. Mit jeder Aktualisierung (F9 oder Änderung einer > Zelle) werden nun die Zahlen in Zufallsbereich geändert. Zuvor war es > so, dass man Strg-Umschalt-F9 drücken musste, um eine Änderung zu > erzwingen. Das alte Verhalten ist viel viel brauchbarer, da man damit > phantastische Lernprogramme erstellen kann (siehe auch www.meudela.de) Da musst Du Dich im Bugtracker für stark machen. Das ist extra geändert worden, weil das bisherige Verhalten für andere nicht nachvollziehbar war: https://bugs.documentfoundation.org/show_bug.cgi?id=102257 > Kann mir jemand mich in meinem Anliegen unterstützen, ich bin neu hier, > was muss man da anstellen? Melde einen Bug. Schreibe genau, warum Du das bisherige Verhalten brauchst. Ich weiß nicht, an welcher Stelle in LO festgelegt wird, welche Funktionen mit Recalculate (F9) und welche nur mit Recalculate hard (Strg-Umschalt-F9) ausgelöst werden. Im Moment hilft Dir das natürlich nicht. Da heißt es bloß, für die spezielle Anwendung weiterhin LO 6.1 zu nutzen. Gruß Robert -- Homepage: http://robert.familiegrosskopf.de LibreOffice Community: http://robert.familiegrosskopf.de/map_3 -- Liste abmelden mit E-Mail an: discuss+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/discuss/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-discuss] Probleme mit dem Calc-Funktion Zufallsbereich seit der Version 6.2
Hallo Joachim, Am 24.08.2019 um 17:21 schrieb Robert Großkopf: > Hallo Joachim, >> >> das Verhalten der Calc-Funktion Zufallsbereich() hat sich seit der >> Version 6.2 geändert. Mit jeder Aktualisierung (F9 oder Änderung einer >> Zelle) werden nun die Zahlen in Zufallsbereich geändert. Zuvor war es >> so, dass man Strg-Umschalt-F9 drücken musste, um eine Änderung zu >> erzwingen. Das alte Verhalten ist viel viel brauchbarer, da man damit >> phantastische Lernprogramme erstellen kann (siehe auch www.meudela.de) > > Da musst Du Dich im Bugtracker für stark machen. Das ist extra geändert > worden, weil das bisherige Verhalten für andere nicht nachvollziehbar war: > https://bugs.documentfoundation.org/show_bug.cgi?id=102257 > >> Kann mir jemand mich in meinem Anliegen unterstützen, ich bin neu hier, >> was muss man da anstellen? > > Melde einen Bug. Schreibe genau, warum Du das bisherige Verhalten > brauchst. Ich weiß nicht, an welcher Stelle in LO festgelegt wird, > welche Funktionen mit Recalculate (F9) und welche nur mit Recalculate > hard (Strg-Umschalt-F9) ausgelöst werden. > > Im Moment hilft Dir das natürlich nicht. Da heißt es bloß, für die > spezielle Anwendung weiterhin LO 6.1 zu nutzen. auf den genannten Bug Report bin ich auch gestoßen. Ich bin skeptisch, dass die Änderung wieder rückgängig zu machen ist. Ich bin jetzt nicht tiefer in Deine Aufgaben eingestiegen, aber vielleicht hilft es Dir, in dem Du die Funktion "Automatisch berechnen" abschaltest. Du findest diese Funktion über das Menü wie folgt (bei Ver. 6.3.0): Daten > Berechnen > Automatisch berechnen Soweit ich das sehe, wird diese Einstellung auch in eine geänderte Datei übernommen. Grüße Harald K. -- LibreOffice - Die Freiheit nehm' ich mir! - www.libreoffice.de -- Liste abmelden mit E-Mail an: discuss+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/discuss/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-discuss] LO 6.0.7.3: Unerwünschte Formatierungen von "Autoformat" bei Writer-Tabellen
Hallo Regina, Am Sat, 24 Aug 2019 15:02:57 +0200 schrieb Regina Henschel : > > Rainer schrieb am 24-Aug-19 um 08:58: > [..] > > > > Weiß jemand Näheres über die Gründe, warum "Autoformat" von > > LO-Generation zu LO-Generation wie beschrieben entwickelt wird - ob > > es also so gewollt oder doch ein Bug war/ist? > > Das ganze geht auf ein GSoC Projekt von 2016 zurück > https://wiki.documentfoundation.org/Development/GSoC/Successfully_Implemented_Ideas#Table_styles > Es ist damals aber nicht wirklich fertig geworden. So werden > beispielsweise immer noch eigene Templates binär kodiert in der Datei > autotbl.fmt abgelegt und einige wichtige Dinge sind überhaupt nicht > implementiert. > Offen gestanden: Dies "Eingemachte" überfordert mich - ebenso, wie die Erklärung der Hintergründe: > Hintergrund war, dass "Autoformat" schon seit StarOffice Zeiten so > implementiert war, dass das Format beim Zuweisen als direkte > Formatierung auf die Tabelle geschrieben wurde und die Datei keine > Information über das Template enthielt. Zeilen/Spalten wurden beim > Einfügen/Löschen nicht automatisch angepasst. Ein anderer Benutzer > konnte keine weitere Tabelle mit dem gleichen Format anlegen. > > Gegenüber der ursprünglichen Situation ist die jetzige Lösung > wirklich ein Fortschritt. Aber es fehlen Leute, die das ganze > weiterführen. > Das kommt IMO auf die Perspektive an (also auf das, was mit einer Tabelle und Autoformat beabsichtigt ist). > Ein paar Hintergrundinformationen: > Im Dateiformat gibt es die Möglichkeit, ein Tabellentemplate zu > definieren. Es enthält die Zell-Formatierungs-Definitionen für erste > Zeile, letzte Zeile, ungerade Zeile, erste Spalte, letzte Spalte, > ungerade Spalte und für Zellen sonst, sowie für den > Tabellenhintergrund. > Genau das ist aber doch das Problem: Für mich als Anwender gibt es die Möglichkeit nicht - selbst dann nicht, wenn sich die Zell-Formatierungsdefinitionen für erste, letzte, ungerade Zeile und Spalte von den anderen nicht unterscheiden (bzw. wenn ich diese alle nicht gesondert formatieren will). > Bei der Tabelle selbst steht dann als Attribute, welches Template > benutzt werden soll. Dabei ist es theoretisch möglich nur einzelne > Aspekte des Templates zu benutzen. Das ist aber nicht implementiert. > Genausowenig ist implementiert, dass der Benutzer direkten Zugriff > auf die im Template referenzierten Zell-Formate hat. Außerdem fehlt > die Implementierung, ein in der Datei vorhandenes Template zu > exportieren. > Da muss ich schon wieder passen :-( Template bedeutet Dokument-Vorlage - und diese habe ich selbst erstellt - ohne einzelnen Zeilen und/der Spalten besondere Attribute zuzuweisen (außer Hintergrundfarben). Dieses "Template" benutze ich. In "Autoformat" hatte ich hinzugefügt, dass bei Betätigung in einem Fall nur eine andere Schrift verwendet wird und in einem anderen Fall zusätzlich eine andere Schriftfarbe in der rechten Spalte. > > In dieser Situation gibt es z.Zt. keine Möglichkeit, loszuwerden, > dass die letzte Zeile besonders behandelt wird. Jein - durch den von mir beschriebenen Workaround schon: Zeile markieren und nochmals "Autoformat" anstoßen. Dann bekommt sie wieder die Hintergrundfarbe einer ersten Zeile. > In deinem Fall würde ich daher gar nichts in dieser Richtung > probieren, sondern einfach die letzte Zeile leer lassen und auf > Zeilenhöhe 0cm setzen. > Dieser Weg ist ausgeschlossen. Beide, von mir selbst erstellte Vorlagen (oth) sind in punkto Zeilenanzahl so üppig bemessen, dass die in 99% aller Fälle ausreichen, die - aus einer Writer-Tabelle (odt) kopierten - Inhalte aufzunehmen (meistens sind dann noch ein paar leere Zeilen vorhanden, die gelöscht werden müssen). Nur weiß ich vorher nicht, ob der dann letzten Zeile die Hintergrundfarbe (von 2, sich abwechselnden) zugewiesen wird, die ohnehin "dran" ist. Wenn es zutrifft, bleibt es dabei, wenn nicht, muss sie geändert werden. Natürlich könnte ich bei der Löschung jeweils eine leere bestehen lassen, so dass sich der Vorgang nicht auf die Farbe der vorletzten - also der letzten sichtbaren auswirkt. Aber das funktioniert leider nicht, wie ich durch einen Versuch gesehen habe: Eine Zeilenhöhe < 0,01cm ist nicht möglich und damit eine sichtbare letzte Zeile in jedem Fall vorhanden. Abgesehen davon sollte mir Autoformat ursprünglich mal die Arbeit erleichtern und den Workflow beschleunigen (tat es anfänglich auch). Inzwischen geht es aber genau in die entgegengesetzte Richtung, und ich ahne, dass ich mich in nicht ferner Zukunft von diesem Werkzeug verabschieden muss. Zusammen mit dem Bug beim Abspeichern im html-Format (ein anderes, kürzlich von mir aufgeworfenes Thema in der Liste), der händische Korrekturen erfordert, wird mir der Aufwand langsam zu groß, auf diesem Weg zu fertigen html-Seiten zu kommen (zu viele Fallen/Stolpersteine). Viele Grüße Rainer -- Liste abmelden mit E-Mail an: discuss+unsubscr...@de.libreoffice.org Probleme? https://de.
Re: [de-discuss] LO 6.0.7.3: Unerwünschte Formatierungen von "Autoformat" bei Writer-Tabellen
Hallo Rainer, Rainer schrieb am 24-Aug-19 um 19:31: [..] Offen gestanden: Dies "Eingemachte" überfordert mich - ebenso, wie die Erklärung der Hintergründe: Es reicht auch die Kurzform: Man wollte eine Verbesserung gegenüber dem fast 20 Jahre altem Verfahren, ist aber nicht fertig geworden. [..] Template bedeutet Dokument-Vorlage - und diese habe ich selbst erstellt > - ohne einzelnen Zeilen und/der Spalten besondere Attribute zuzuweisen (außer Hintergrundfarben). Dieses "Template" benutze ich. In "Autoformat" hatte ich hinzugefügt, dass bei Betätigung in einem Fall nur eine andere Schrift verwendet wird und in einem anderen Fall zusätzlich eine andere Schriftfarbe in der rechten Spalte. In dieser Situation gibt es z.Zt. keine Möglichkeit, loszuwerden, dass die letzte Zeile besonders behandelt wird. Jein - durch den von mir beschriebenen Workaround schon: Zeile markieren und nochmals "Autoformat" anstoßen. Dann bekommt sie wieder die Hintergrundfarbe einer ersten Zeile. Es ist aber immernoch eine letzte Zeile und wird damit vom Zeilenfarbwechsel ausgeschlossen. In deinem Fall würde ich daher gar nichts in dieser Richtung probieren, sondern einfach die letzte Zeile leer lassen und auf Zeilenhöhe 0cm setzen. Dieser Weg ist ausgeschlossen. Beide, von mir selbst erstellte Vorlagen (oth) sind in punkto Zeilenanzahl so üppig bemessen, dass die in 99% aller Fälle ausreichen, die - aus einer Writer-Tabelle (odt) kopierten - Inhalte aufzunehmen (meistens sind dann noch ein paar leere Zeilen vorhanden, die gelöscht werden müssen). Nur weiß ich vorher nicht, ob der dann letzten Zeile die Hintergrundfarbe (von 2, sich abwechselnden) zugewiesen wird, die ohnehin "dran" ist. Wenn es zutrifft, bleibt es dabei, wenn nicht, muss sie geändert werden. Natürlich könnte ich bei der Löschung jeweils eine leere bestehen lassen, so dass sich der Vorgang nicht auf die Farbe der vorletzten - also der letzten sichtbaren auswirkt. Aber das funktioniert leider nicht, wie ich durch einen Versuch gesehen habe: Eine Zeilenhöhe < 0,01cm ist nicht möglich und damit eine sichtbare letzte Zeile in jedem Fall vorhanden. Du befindeste dich aber schon in Writer und nicht in Calc? Du markierst die letzte Zeile, dann Tabelle > Größe > Zeilenhöhe. Du nimmst das Häckchen bei "dynamisch anpassen" heraus, lässt Höhe auf 0cm. Ok. Abgesehen davon sollte mir Autoformat ursprünglich mal die Arbeit erleichtern und den Workflow beschleunigen (tat es anfänglich auch). Inzwischen geht es aber genau in die entgegengesetzte Richtung, und ich ahne, dass ich mich in nicht ferner Zukunft von diesem Werkzeug verabschieden muss. Zusammen mit dem Bug beim Abspeichern im html-Format (ein anderes, kürzlich von mir aufgeworfenes Thema in der Liste), der händische Korrekturen erfordert, wird mir der Aufwand langsam zu groß, auf diesem Weg zu fertigen html-Seiten zu kommen (zu viele Fallen/Stolpersteine). Für HTML ist das wirklich nicht geeignet. Mit freundlichen Grüßen Regina -- Liste abmelden mit E-Mail an: discuss+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/discuss/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
