![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
Hi,
ich arbeite mit LibreOffice und muss dort größere Dateien reinsetzen.
Nach einiger Zeit hat LibreOffice mit der Verarbeitung (Dateigröße)
erhebliche Probleme. Weiß jemand Rat? Gibt es eine Alternative neben
Verknüpfen und runterdrehen der Qualität?
BG Michael
Ich darf noch nachtragen:
Ich habe < 20 Folien und in der Mehrzahl Bilder drin. Die Dateigröße liegt
dann bei etwa 2 MB bis maximal 10 MB. Wenn ich die Datei dann mit
LibreOffice speichere, hängt sich das Programm gerne schon einmal auf; die
Datei - etwa 4 bis 5 MB - lässt sich dann kaum richtig öffnen. Das ist kein
sehr angenehmes Arbeitn.
Ich habe gerade festgestellt, dass ein Bild, das ich mit GIMP bearbeite
gerade mal 86 MB groß ist. GIMP lädt fix, speichert fix und arbeitet fix.
Mein System ist eigentlich leistungstechnisch ganz gut dabei, was aber
nicht verhindert, dass LO bei der obig umrissenen Präsentation ziemlich
ressourcen-fressend auftritt.
Weiß jemand Rat, hat jemand ähnliche Erfahrungen, vielleicht auch eine
Lösung parat?
Besten Gruß
Michael
Hallo Michael,
Ich habe gerade festgestellt, dass ein Bild, das ich mit GIMP
bearbeite gerade mal 86 MB groß ist. GIMP lädt fix, speichert fix und
arbeitet fix. Mein System ist eigentlich leistungstechnisch ganz gut
dabei, was aber nicht verhindert, dass LO bei der obig umrissenen
Präsentation ziemlich ressourcen-fressend auftritt.
die Bildgröße ist für Deine Zwecke völlig überdimensioniert.
Für Präsentationen auf dem Bildschirm reicht eine Dateigröße von etwa 300 kB (beim jpg-Format).
Am besten ist es, bei Gimp den Zoomfaktor auf 100% einzustellen und dann mit "Bild > Bild skalieren" die Bildbreite so einzustellen, dass die angezeigte Bildgröße mit der gewünschten Bildgröße in der Präsentation übereinstimmt; dann das Bild exportieren.
Es grüßt Dich
Karl-Heinrich
Hallo,
LibreOffice unterstützt ja die Suche nach und das Ersetzen von Formatvorlagen. Nur leider scheint sich das bisher auf Absatzvorlagen zu beschränken.
Tatsächlich ist es aus verschiedenen Gründen durchaus sinnvoll, auch Zeichenvorlagen (betont, stark betont) einzusetzen. Nun werden "betonte" Textstellen nicht durch die Suche nach kursivem Text gefunden. Klar, da das Betonen ja auch anders realisiert werden kann.
Aber leider scheint es in LO derzeit überhaupt keine Möglichkeit zu geben, nach betontem (oder mit einer anderen Zeichenformatvorlage formatierem) Text zu suchen. Entsprechend gilt dies fürs Ersetzen.
Sehe ich das richtig?
Ciao
André
Ich habe < 20 Folien und in der Mehrzahl Bilder drin. Die Dateigröße
liegt dann bei etwa 2 MB bis maximal 10 MB. Wenn ich die Datei dann
mit LibreOffice speichere, hängt sich das Programm gerne schon einmal
auf;
Ich würde hier vermuten, daß Windows vor Schreck ins Koma fällt. Was es
ja immer macht, wenn jemand von ihm nennenswert I/O verlangt.
Weiß jemand Rat, hat jemand ähnliche Erfahrungen, vielleicht auch eine
Lösung parat?
Ein *Betriebs*system benutzen, das I/O kann. Und das ein
brauchbares Dateisystem hat.
MfG,
Wolfgang
Hallo Michael,
Eine Lösung habe ich leider nicht, aber vielleicht kann ich helfen, das
Problem ein bisschen einzuengen. Leider sagst Du nicht, welche Version
von Libreoffice und welches Betriebssystem Du benutzt.
Ich arbeite auch regelmäßig mit einer mittlerweile ziemlich großen
Präsentation (ca. 270 Folien mit vielen Bildern, größtenteils im jpeg
Format, nicht verknüpft, Größe des odp files ca. 270 MB). Mit
Libreoffice 4.1.2 (und auch mit den Vorgängerversionen seit ca. einem
Jahr) habe ich keinerlei Probleme mit dieser Datei, weder beim Laden
noch beim Speichern. Beides dauert ca. 1-2 Minuten. Ich arbeite
normalerweise unter Linux, habe es aber gerade auch mal kurz unter
Windows 7 probiert, mit dem gleichen Ergebnis.
Tja, das ist leider alles was ich beitragen kann.
Beste Grüße
Markus
Hallo Michael,
ein Hinweise welche LO Version und welches Betriebssystem du einsetzt, wäre sehr wichtig!
Michael Reschke <reschke.michael@gmail.com> schrieb
Hi,
ich arbeite mit LibreOffice und muss dort größere Dateien reinsetzen.
Nach einiger Zeit hat LibreOffice mit der Verarbeitung (Dateigröße)
erhebliche Probleme. Weiß jemand Rat? Gibt es eine Alternative neben
Verknüpfen und runterdrehen der Qualität?
ohne Hinweis über die Größe der Bilder kann man auch wenig sagen.
Du solltest wissen, das JPG ein komprimiertes Format ist, welches beim Laden im Arbeitsspeicher dekomprimiert wird und dort mehr Ressourcen verbraucht als die Dateigröße.
Du könntest die Werte unter Extras > Optionen > LibreOffice > Arbeitsspeicher für den Grafikcache erhöhen.
Dein Vergleich in der 2. Mail bezgl. GIMP und LO ist unzutreffend. Das sind zwei unterschiedliche Anwendungen für unterschiedliche Aufgaben optimiert. Das ist wie Äpfeln mit Birnen vergleichen.
Hallo Wolfgang,
Wolfgang Keller <feliphil@gmx.net> schrieb
Ich würde hier vermuten, daß Windows vor Schreck ins Koma fällt. Was es
ja immer macht, wenn jemand von ihm nennenswert I/O verlangt.
Der TO hat von Windows doch gar nichts erwähnt???
Ein *Betriebs*system benutzen, das I/O kann. Und das ein
brauchbares Dateisystem hat.
Dieses Microsoft-Bashing ist Unsinn. Seit XP ist das Dateisystem von MS sehr stabil und was meinst du mit I/O? Jedes Betriebssystema kann das, sonst ist es kein Betriebssystem.
Und ja, ich habe Erfahrung mit Linux, solange bis sich das Linux infolge eines defekten Speicherriegels bis zum kompletten Datenverlust zerlegte, während bei einem parallelen Windows sich zwar Bluescreens einstellten, dieses nach Austausch des Speichers aber wieder reparieren lies.
Es ist auch in der Linux-Welt nicht alles Gold was glänzt!
Hallo Edgar,
Hallo Wolfgang,
Wolfgang Keller <feliphil@gmx.net> schrieb
Dieses Microsoft-Bashing ist Unsinn.
Es ist auch in der Linux-Welt nicht alles Gold was glänzt!
Völlig richtig, wir sollten hier nicht in eine OS - Diskussion abgleiten, das bringt nichts. Ich arbeite seit vielen Jahren mit Linux (90%) und Windows (10%) und betreue sowohl Windows wie auch (mehrheitlich) Linux-PC-User. Die Wahl des OS hängt immer sehr von den pers. Vorlieben und vor allem von der verwendeten (Fach-) Software ab. Es gibt (leider) kein OS was für jeden und alle "das Beste" ist.
Gruß, thoralf
Hallo Edgar,
mir geht es ähnlich wie Michael, daher werde ich versuchen, meine
Erlebnisse zu schildern:
Ich habe mit einem Dokument angefangen, dann folgende Optimierungen
vorgenommen: Abschalten der Anzeige der Bilder auf dem Schirm,
Vergrößern des Graphikcache auf das Maximum, 256 MB.
Die verwendeten Bilder sind zu ca. 90 % png, der Rest jpg; sie sind
ausschließlich als Verweis eingebunden. Von den Möglichkeiten zur
Bildbearbeitung nutze ich ausschließlich Breiten- bzw. Längenanpassung.
Da die Bilder aus einem Hochleistungs-Scanner stammen, liegt die
Dateigröße jeweils bei einigen MB.
Nachdem sich die Verwendung eines Dokumentes als Sackgasse
herausstellte, habe ich das Ganze in einzelne Kapitel zerlegt, je
Kapitel eine Datei. Jede Datei für sich macht keinen Streß, ABER:
Wenn ich anfange, das Global-Dokument mit Unter-Dokumenten zu füllen,
das globale Inhaltsverzeichnis zu aktualisieren und dann zu speichern,
dann passiert folgendes:
Die CPU-Last steigt auf deutlich mehr als 50%, ich habe ein 2-Kern CPU,
und dies für mehrere Minuten. Der Speicher wird meist mit 1,5 - 2 GB
genutzt, der Rest, insgesamt sind 8 GB verbaut, bleibt ungenutzt.
"Experimentell" habe ich die Anzahl der Unterdokumente ermittelt, die
problemlos verarbeitet werden können, danach bricht die Verarbeitung
reproduzierbar ab.
Mein persönlicher work-around: Im Globaldokument selbst verwende ich
römische Ziffern für die Seitennummerierung, das Inhaltsverzeichnis läßt
eine Bearbeitung zu. Da das Umschalten der Seitennummerierung sehr
einfach ist, verteile ich die Unterdokumente einfach auf (bislang) zwei
Globaldokumente und arbeite dann manuell nach. Elegant ist das nicht.
Ich hoffe, das war jetzt nicht zu lang!?!
Gruß, Klaus
PS.: LO 4.1.1.2; Windows 7 Pro, 64 Bit
Hallo,
Hallo Edgar,
mir geht es ähnlich wie Michael, daher werde ich versuchen, meine
Erlebnisse zu schildern:Ich habe mit einem Dokument angefangen, dann folgende Optimierungen
vorgenommen: Abschalten der Anzeige der Bilder auf dem Schirm,
Vergrößern des Graphikcache auf das Maximum, 256 MB.Die verwendeten Bilder sind zu ca. 90 % png, der Rest jpg; sie sind
ausschließlich als Verweis eingebunden. Von den Möglichkeiten zur
Bildbearbeitung nutze ich ausschließlich Breiten- bzw. Längenanpassung.
Da die Bilder aus einem Hochleistungs-Scanner stammen, liegt die
Dateigröße jeweils bei einigen MB.Nachdem sich die Verwendung eines Dokumentes als Sackgasse
herausstellte, habe ich das Ganze in einzelne Kapitel zerlegt, je
Kapitel eine Datei. Jede Datei für sich macht keinen Streß, ABER:Wenn ich anfange, das Global-Dokument mit Unter-Dokumenten zu füllen,
das globale Inhaltsverzeichnis zu aktualisieren und dann zu speichern,
dann passiert folgendes:Die CPU-Last steigt auf deutlich mehr als 50%, ich habe ein 2-Kern CPU,
und dies für mehrere Minuten. Der Speicher wird meist mit 1,5 - 2 GB
genutzt, der Rest, insgesamt sind 8 GB verbaut, bleibt ungenutzt."Experimentell" habe ich die Anzahl der Unterdokumente ermittelt, die
problemlos verarbeitet werden können, danach bricht die Verarbeitung
reproduzierbar ab.Mein persönlicher work-around: Im Globaldokument selbst verwende ich
römische Ziffern für die Seitennummerierung, das Inhaltsverzeichnis läßt
eine Bearbeitung zu. Da das Umschalten der Seitennummerierung sehr
einfach ist, verteile ich die Unterdokumente einfach auf (bislang) zwei
Globaldokumente und arbeite dann manuell nach. Elegant ist das nicht.
Ich würde so große Dokumente mit Scribus Layouten den Text aus einer .txt
Datei oder .odt einlesen.
Schreibprogramme sind halt für Briefe etc gemacht. Nicht für Zeitungen Bücher,
Diplomarbeiten oä.
Richtig gut wäre Latex aber das ist mir auch zu kompliziert für nur einmal.
Gruß
Sebastian
Hallo Klaus,
kbu <libreoffice@buechting.com> schrieb
Die verwendeten Bilder sind zu ca. 90 % png, der Rest jpg; sie sind
ausschließlich als Verweis eingebunden. Von den Möglichkeiten zur
Bildbearbeitung nutze ich ausschließlich Breiten- bzw. Längenanpassung.
Da die Bilder aus einem Hochleistungs-Scanner stammen, liegt die
Dateigröße jeweils bei einigen MB.
Es gibt jede Menge Software - auch kostenlose - die Bilder neben der Anzeige auch verkleinern können, z. B. IrvanView, wenn wir von Windows reden.
Aus meiner Sicht gibt es keinen, aber auch wirklich keinen einzigen Grund Bild mit mehreren MB einzubauen.
Meine ältere Digitalkamera mach 6 MP ich fotografiere seit Jahren mit 3 MP und habe bessere Bilder als mit zuletzte gekaufter und wieder zurückgegebener 12 MP-Kamera.
Der Megapixelwahn ist ein Unsinn. Hier wird dem Verbraucher mal wieder vorgegauckelt, dass mehr besser ist und am eigentlich wichtigen wird mehr und mehr eingespart, nämlich an lichtstarker und guter Optik.
Ich habe von meiner 3 MP Bilder hervorragende A3-Poster machen lassen.
Wenn man meint man muss das Machbare unbedingt ausreizend, dann orientiert man sich doch bitte am Ausgabegerät. Wenn der Drucker eben nicht mehr wie 1600x1600 Pixel kann, warum dann größere Bilder verwenden? Man schaue sich doch bitte mal eine Illustrierte an, dann kann man die Bildraster ja schon mit dem bloßen Auge erkennen.
Es gibt nur ein einziges Argument für Bilder im 2-stelligen MP-Bereich und der heisst Ausschnitt. Das funktioniert dann aber nur mit Highend-Digitalkameras! Sonst bekommt man nur Wischiwaschi-Bilder. Wenn ich einen Ausschnitt aus einem 20 MP-Bild ziehe hab ich unterm Strich wieder eine kleine Datei!!
Also kann mir keiner hier eine Story vom Pferd erzählen: "Ich hab ne 68 MB-Datei und die muss ich auch erhalten!" Wobei das ja schon eine RAW-Datei sein muss.
Die CPU-Last steigt auf deutlich mehr als 50%, ich habe ein 2-Kern CPU,
und dies für mehrere Minuten. Der Speicher wird meist mit 1,5 - 2 GB
genutzt, der Rest, insgesamt sind 8 GB verbaut, bleibt ungenutzt.
Ich bin kein Fachmann, aber 64-bit kann dein BS. LO ist jedoch eine 32 Bit-Anwendung. Daher kann LO nicht unmittelbar auf den kompletten Arbeitsspeicher zugreifen sondern gerade mal unterhalb 4 GB. Wenn die dann auch noch von anderen 32-Bit-Anwendungen in Beschlag genommen sind, läuft wieder alles über die Auslagerungsdatei. Da mag Linux _vielleicht_ intelligenter sein, weil es erstmal den kompletten Arbeitsspeicher verwendet, bevor es auslagert.
Ich hoffe, das war jetzt nicht zu lang!?!
Ich hoffe deine verwendeten Bilder sind kleiner als dein Mail =:->
Scherz! Nein, es ist ja gut wenn hier Tipps gepostet werden. Ich kann ja leider auch nicht wirklich weiterhelfen, weil ich so große Dateien nicht habe.
Aber wer in eine Bildschirmpräsentation - und was anderes ist IMPRESS ja nicht Bilder packt jenseits von 1024 Pixel Seiten- oder Längerbreite muss einfach auf die Nase fallen.
Hallo,
Hallo Edgar,
mir geht es ähnlich wie Michael, daher werde ich versuchen, meine
Erlebnisse zu schildern:Ich habe mit einem Dokument angefangen, dann folgende Optimierungen
vorgenommen: Abschalten der Anzeige der Bilder auf dem Schirm,
Vergrößern des Graphikcache auf das Maximum, 256 MB.Die verwendeten Bilder sind zu ca. 90 % png, der Rest jpg; sie sind
ausschließlich als Verweis eingebunden. Von den Möglichkeiten zur
Bildbearbeitung nutze ich ausschließlich Breiten- bzw. Längenanpassung.
Da die Bilder aus einem Hochleistungs-Scanner stammen, liegt die
Dateigröße jeweils bei einigen MB.Nachdem sich die Verwendung eines Dokumentes als Sackgasse
herausstellte, habe ich das Ganze in einzelne Kapitel zerlegt, je
Kapitel eine Datei. Jede Datei für sich macht keinen Streß, ABER:Wenn ich anfange, das Global-Dokument mit Unter-Dokumenten zu füllen,
das globale Inhaltsverzeichnis zu aktualisieren und dann zu speichern,
dann passiert folgendes:Die CPU-Last steigt auf deutlich mehr als 50%, ich habe ein 2-Kern CPU,
und dies für mehrere Minuten. Der Speicher wird meist mit 1,5 - 2 GB
genutzt, der Rest, insgesamt sind 8 GB verbaut, bleibt ungenutzt."Experimentell" habe ich die Anzahl der Unterdokumente ermittelt, die
problemlos verarbeitet werden können, danach bricht die Verarbeitung
reproduzierbar ab.Mein persönlicher work-around: Im Globaldokument selbst verwende ich
römische Ziffern für die Seitennummerierung, das Inhaltsverzeichnis läßt
eine Bearbeitung zu. Da das Umschalten der Seitennummerierung sehr
einfach ist, verteile ich die Unterdokumente einfach auf (bislang) zwei
Globaldokumente und arbeite dann manuell nach. Elegant ist das nicht.
Ich würde so große Dokumente mit Scribus Layouten den Text aus einer .txt
Datei oder .odt einlesen.
Schreibprogramme sind halt für Briefe etc gemacht. Nicht für Zeitungen Bücher,
Diplomarbeiten oä.
Richtig gut wäre Latex aber das ist mir auch zu kompliziert für nur einmal.
Gruß
Sebastian
Hallo zusammen,
also ich habe meine Abschlussarbeit mit OpenOffice.org geschrieben und war
damit sehr zufrieden und es lieft sehr gut durch.
Ich habe zwar noch passiv mitgelesen, mir fehlte aber die Zeit, aktiv etwas
beizusteuern.
Ich hatte die Hinweise hier beachtet und damit ging es dann, d. h. ich habe
deutlich kleinere Dateien verwendet.
Ich vermute den Fehler irgendwo im Parser, der das ODT-Dokument nach
Impress lädt. Aktuell liege ich mit der Dateigröße deutlich über dem, was
zuvor Probleme gemacht hatte und habe auch mehr Bilder eingebunden.
Einziger Unterschied ist, dass ich manuell für jedes Bild in Gimp die
Auflösung manuell heruntergeschraubt habe.
Wahrscheinlich kann LO nicht so gut mit Bilddateien ab 600 dpi umgehen,
wenn die dann in LO erst auf die von mir auf der Folie gewünschte
Dateigröße umgerechnet werden müssen.
Könnt ihr mit dieser Problembeschreibung etwas anfangen???
BG Michael
Moin, moin,
vielen Dank für Eure Antworten!
Zur Verwendung von LO auch für "mehrseitige" Dokumente: Robert hatte an
anderer Stelle auf die Handbücher verwiesen, die alle mit writer
erstellt werden, auch der Hinweis auf die Diplomarbeit mit OO.o -
grundsätzlich war die Auswahl von writer also richtig. (Ganz abgesehen
von den Ideen zur Gestaltung, die ich [schamlos] abgekupfert habe.)
Zu den eingebetteten png-Dateien:
Der Scanner arbeitet mit 400x400 dpi und liefert eine DIN A4-Seite
(etwas größer) als tif mit ca. 55MB. Parallel gibt es dazu jeweils ein
jpg mit ca. 1,6 MB (Platte) bzw. 14 MB (Speicher). Die png entstehen als
Ausschnitte aus den tif und nicht aus den jpg, weil der
Qualitätsunterschied im Ausdruck deutlich (!) zu sehen ist.
Offensichtlich gibt es nicht den "einen" Schalter, den ich umlegen muß,
ich werde etwas "spielen" und mich dann wieder melden.
Gruß, Klaus
Moin,
Michael Reschke <reschke.michael@gmail.com> schrieb
Ich vermute den Fehler irgendwo im Parser, der das ODT-Dokument nach
Impress lädt.
wie jetzt, du lädst ein Writer-Dokument in IMPRESS?
Oder meinst du ein ODP-Dokument?
Wahrscheinlich kann LO nicht so gut mit Bilddateien ab 600 dpi umgehen,
wenn die dann in LO erst auf die von mir auf der Folie gewünschte
Dateigröße umgerechnet werden müssen.
Was heisst das schon: "Kann nicht so gut umgehen ..."
Weißt du von welchen Datenmengen du bei 600 dpi (eigentlich ppi) sprichst?
Eine Linie von 2,54 cm Länge wird dabei in 600 Punkte zerlegt. Klingt nicht viel! Aber jeder jeder Punkt einer 24-Bit-Farbtiefe (True Color) wird in 3 Farben dargestellt Rot, Grün, Blau = RGB mit jeweils 8 Byte (3x8=24) das bedeutet in Zahlen 256 x 256 x 256 > 16 Millionen Farben.
Somit ergibt ein Bild von der Größe 10 x 15 cm ca. 8,4 Mill. Bildpunkte x 3 Byte
ergibt etwa 25 Mill. Bildpunkte. Das heisst, die Farben müssen errechnet werden, die Größe muss errechnet werden und auf die unterschiedlichen Monitorgrößen skaliert werden. Dieses bedarf einer hohen Speicher- und Rechenkapazität. Jedes kleine Scrollen bedeutet Neuberrechnung.
Hier noch ein Link für den Interessierten über Bildgrößen und Farbtiefe bei der Berechnung von Bildern: http://www.handelswissen.net/data/branchen/Fotobranche/Foto-Spezialwissen/Verfahren/Fotos_digitalisieren/dpi_und_Bildgroesse.php
Wenn man also sagt, LO kann damit nicht gut umgehen, tut man LO unrecht. Wenn ich eine Kiste mit leeren Wasserflaschen locker in einer Hand trage, kann ich nicht sagen, dass meine Frau, weil sie ein Kasten mit vollen Flaschen, mit beiden Händen und einer gewissen Mühe trägt, nicht geeignet ist eine Wasserkiste zu tragen 
Aber wie schon ausgeführt, bei JPG-Bilder beachten, die werden im Speicher dekomprimiert und nehmen mehr Platz im Arbeitspeicher als auf der Festplatte ein.
Für mich ist das geschilderte kein Problem von LO sondern von Hard- und Thinkware
odp meinte ich - statt ODF spreche ich vereinzelt noch von ODT - habe ich
noch nicht entlinkt in meiner Thinkware...
GIMP muss auf meinem Rechner aktuell mit sehr viel größeren Dateimengen
umgehen und kommt damit gut zurecht, d. h. ich sehe den Fehler aktuell eher
bei LO als vor dem Rechner.
Im Kern müsste eigentlich GIMP vor dem identischen Problem stehen, löst es
dann aber wohl besser. Ich hatte vermutet - aber anscheinend nicht
ausreichend verständlich gemacht, denn bei der Fehleranalyse liegen wir
nicht weit auseinander - dass LO mit dem Umrechnen des Bildes in hoher
Auflösung in ein anzeigefähiges Bild ins Straucheln gerät. Aus meiner Sicht
müssten die Programmierer hier noch einmal ran und eine clevere Lösung
finden, denn mit der bereits implementierten "Präsentation
komprimieren"-Funktion allein kommt man hier nicht weiter...
BG Michael
Hallo,
Michael Reschke <reschke.michael@gmail.com> schrieb
GIMP muss auf meinem Rechner aktuell mit sehr viel größeren Dateimengen
umgehen und kommt damit gut zurecht, d. h. ich sehe den Fehler aktuell eher
bei LO als vor dem Rechner.
Gimp hat aber auch eine andere Aufgabe als LO, kannst du doch gar nicht miteinander vergleichen.
Im Kern müsste eigentlich GIMP vor dem identischen Problem stehen, löst es
dann aber wohl besser. Ich hatte vermutet - aber anscheinend nicht
ausreichend verständlich gemacht, denn bei der Fehleranalyse liegen wir
nicht weit auseinander - dass LO mit dem Umrechnen des Bildes in hoher
Auflösung in ein anzeigefähiges Bild ins Straucheln gerät.
Mein Gott, man kann mit einem Mähdrescher auch auf der Straße von A nach B kommen, aber schneller geht es mit einem Auto. Mit dem kannst du aber kein Korn ernten.
Du lädst doch auch nicht eine Vielzahl von Bilder in den Gimp und baust dort Folien und Text mit Übergängen und PiPaPo ... Das kann der Gimp nämlich nicht. Warum kann der Gimp so was denn nicht? Muss man doch mal den Programmierern ...
Irgendwo muss man doch mal realistisch bleiben. LibreOffice ist eine Büro-(Büro ist die Übersetzung für Office) Software, weder ein Bildbearbeitungsprogramm noch ein spezialisiertes DTP-Programm.
Wenn es unbedingt 600 ppi Bilder sein sollen und DTP Anforderungen, dann braucht man halt einen Mac, Adobe und viel, viel Geld.
Hallo,
gibt es in LibreOffice eine Möglichkeit, nach Zeichenformatvorlagen (statt nur Absatzformatvorlagen) zu suchen und diese zu ersetzen?
Ciao
André
Hallo André,
gibt es in LibreOffice eine Möglichkeit, nach Zeichenformatvorlagen
(statt nur Absatzformatvorlagen) zu suchen und diese zu ersetzen?
ich hab diese Möglichkeit auch schon vermisst. Ich hab dazu einen bereits relativ alten Verbesserungsvorschlag in Bugzilla gefunden:
https://bugs.freedesktop.org/show_bug.cgi?id=34390
Der Vorschlag hat dort bereits die Wichtigkeit "High". Man könnte den Vorschlag ev. in die "Vote for Enhancement"-Liste aufnehmen. Vielleicht lässt sich die Realisierung damit etwas beschleunigen.
Im Bug-Report gibt es auch einen Hinweis auf eine LibreOffice-Erweiterung, die eine Suche nach Zeichenformatvorlagen können soll:
http://extensions.libreoffice.org/extension-center/alternative-dialog-find-replace-for-writer
Wenn Du Lust hast, kannst Du die Erweiterung ja mal ausprobieren und berichten.
Grüße
Harald