Hatte die 2008er in einer Promo kostenlos bekommen und dann für 30,-€ auf die 2010 geupgradet. Nutze es ausschließlich wegen der Wörterbücher - blöd nur, dass man die unter Windows separat nutzen kann, was unter Linux nicht möglich ist. Allein durch die Nichtunterstützung der Open Document Formate ein No-Go.
Nichtmal MS Office 2003, 2007, 2010 ist untereinander richtig kompatibel. Wenn man mit doc-Formaten arbeitet, muss man paar Inkompatibilitäten immer in Kauf nehmen, selbst wenn man eine Version von MS verwendet.
Besser als Libre Office auf jeden Fall, aber ich warte noch dass Kingsoft Office 2012 endlich für Linux erscheint, dann hat man einen vollwertigen Ersatz für MS Office dank guter chinesischer Kopierarbeit.
das ist es, für Libre/Open Office gibt es ein Latex-Plugin, einen Formeleditor, man kann ebenfalls Vektorgrafiken laden und als letzte Möglichkeiten auch Bitmapgrafiken aus einem externen Formeleditor.
Bei Softmaker ist nur die letzte Möglichkeit und damit die mit der schlechtesten Qualität möglich. Und das ist schade. Ich erwähne das, wo ich auch immer kann. Nicht um Softmaker zu schaden, sondern um für diesen Punkt um Nachbesserung zu hoffen. Es hat ja auch beim Open Office Dateiformat (bisher aber nur teilweise) funktioniert. Also hoffe ich auch auf den Formelsatz.
Von da-real-lala am Do, 15. November 2012 um 17:49 #
Word 2000 ist schneller, sieht in Wine genauso hässlich aus, hat mehr Features und ist kompatibler mit MS Formaten. Ich glaube man könnte es aufm Flohmarkt auch für weniger Geld finden. Wenn ich schon meine Seele verkaufe, dann soll wenigstens alles auch funktionieren.
Läuft leider nicht mit 64Bit, sondern nur im 32Bit-Kompatiblitätsmodus
# rpm -ivh softmaker-office-trial-2012-671.x86_64.rpm Fehler: Fehlgeschlagende Abhängigkeiten: libX11.so.6 wird benötigt von softmaker-office-2012-671.i386 libXext.so.6 wird benötigt von softmaker-office-2012-671.i386 libXmu.so.6 wird benötigt von softmaker-office-2012-671.i386 libXrender.so.1 wird benötigt von softmaker-office-2012-671.i386 libc.so.6 wird benötigt von softmaker-office-2012-671.i386 libc.so.6(GLIBC_2.0) wird benötigt von softmaker-office-2012-671.i386 libc.so.6(GLIBC_2.1) wird benötigt von softmaker-office-2012-671.i386 libc.so.6(GLIBC_2.1.3) wird benötigt von softmaker-office-2012-671.i386 libc.so.6(GLIBC_2.2) wird benötigt von softmaker-office-2012-671.i386 libdl.so.2 wird benötigt von softmaker-office-2012-671.i386 libdl.so.2(GLIBC_2.0) wird benötigt von softmaker-office-2012-671.i386 libdl.so.2(GLIBC_2.1) wird benötigt von softmaker-office-2012-671.i386 libm.so.6 wird benötigt von softmaker-office-2012-671.i386 libm.so.6(GLIBC_2.0) wird benötigt von softmaker-office-2012-671.i386 libstdc++.so.6 wird benötigt von softmaker-office-2012-671.i386
Na und? MS Office (und einige andere Windows-Programme) ist auch immer noch 32-bittig. Solange dadurch keine handfesten Nachteile entstehen, ist es doch egal, ob eine Anwendung nativ auf 64 Bit läuft, oder?
Von Jürgen Sauer am Fr, 16. November 2012 um 10:45 #
So egal ist es nicht!
Nicht jeder möchte eine Schatten 32-Bit Version alled shared objekte haben. Diese Schatten Versionen in 32bit sind a) fehler trächtig b) überflüssig c) balast im negativem sinne d) resourcen / cpu / ram / strom fressend e) kosten zusätzelichen Plattenplatz (auf ssd Installtionen sehr teuer)
und alles nur weil ein Entwicklerteam zu blöd ist die Software sauber zu schreiben. Mit einem saubereremund qualtitativ hochstehendem Quellcode ist es egal ob man ein 32Bit oder 64Bit make anwirft. Nicht gerade Vertrauenserweckend.
Schlimmer wäre es, falls es nur Faulheit geschuldet ist, dass kein 64-Bit Build existiert... dann wäre das nur eine Marketingblase ...
Findest du nicht, dass die Nachteile ein wenig an den Haaren herbeigezogen sind. Streng genommen ist es sogar so, dass ab einer gewissen Größe sich die Nachteile (bedingt durch die 32Bit-Architektur) sogar relativieren. Wie dem auch sei... Eine neue Idee für unsere allwöchentliche Umfrage ist geboren
Imho bringen 64Bit bei einem Office-Paket keine ernsten Vorteile:
32Bit versus 64Bit machen in erster Linie einen breiteren Speicherbus aus. D.h. mit 64Bit kannst Du Speicher oberhalb der 2, bzw 4GB Grenze direkt ansprechen.
Den angeblichen Performance-Gewinne hast du nur durch mehr direkt ansprechbaren Speicher, sowie größerer Speicherregister - welche mehr Daten in einem Schwung verarbeiten können.
Nur wie oft werde ich ernsthaft Dokumente bearbeiten die mehr als 2GB Arbeitsspeicher belegen? Bei welcher Office-Funktion soll 64Bit optimierter Programmcode spürbar mehr Performance bringen als bei einer 32Bit Variante?
>> a) fehler trächtig Wieso sollte das vorhandensein von 32Bit Code fehler trächtig sein?
>> b) überflüssig Solang es 32Bit Software gibt nicht.
>> d) resourcen / cpu / ram / strom fressend Bullshitt - KDE/Gnome/Firefox/OpenOffice brauchen als Einzelapplikationen schon weit aus mehr CPU-Power als der Unterschied zwischen einem 32Bit compilat einer OfficeVersion und dem 64Bit compilat.
64Bit-Software belegt je int, float usw doppelt soviel Speicher als eine 32Bit Software.
2GB Ram kosten keine 25EUR
Mir wäre neu das "spürbar" mehr CPU-Power benötigt wird, wenn eine Applikation ine einem 64Bit-System im 32Bit Modus läuft. Mit spürbar mein ich Verzögerungen überhalb von 0,1s. Strom fressend halte ich auch für quatsch - der Arbeitsspeicher wird gerade unter GNU/Linux sonst andersweitig genutzt. Das durch 32Bit-Software in einem 64Bit OS ein höhrer Stromverbrauch spürbar (>2%) ist halte ich für eine gewagte Theorie - insbesondere wenn Du auf SSDs setzt.
>> e) kosten zusätzelichen Plattenplatz (auf ssd Installtionen sehr teuer) Selbst kleine SSDs mit 32GB Speicherplatz dürften ausreichend sein um eine GNU/Linux-Distro problemlos unterzubringen. Wenn Dir der Speicherplatz "SO" teuer erscheint, frage ich mich warum Du nicht auf eine klassische HDD setzt, da kannst Du viel mehr Geld sparen. Auch kannst Du viel "wertvollen" Speicherplatz freigebeben indem Du nicht benötigte Manuals, Beispielprogramme und BeispielConfigs löscht.
hat schon mal jemand versucht Tabellen von einer Anwendung in die andere zu übertragen?
Ich erzeuge und berechne Tabellen i.d.R. in einer Tabellenkalkulation, das finde ich normal. Aber danach benötige ich die Tabellen in der Textverarbeitung innerhalb eines Aufsatzes und nicht als Anhang, genau so in der Präsentation. Das ist unter Softmaker noch schlechter gelöst als unter LibreOffice.
Ansonsten ist das Programm der Renner, doch Open/Libre Office ist auch auf meinem Rechner schnell genug.
Fehlende Kompatibiliät zu Open/Libre Office, kein Formeleditor und eingeschränkte Kompatibilität bei Tabellen bei Übertragung zwischen den verschiedenen Programmteilen der gleichen Office Suit, das ist wirklich eine Beschränkung für mich. Also werde ich wohl doch bei Libre Office bleiben.
"So konnte die Anwendung beispielsweise normale Microsoft Office-Dokumente, ohne komplizierte Konstrukte, fast zu 100% korrekt wiedergeben und..."
Fast 100% bedeutet in der Praxis so gut wie nie! Denn diese "einfachen" Strukturen sind nun mal nicht im Berufsleben anzutreffen.
Umso wichtiger ODF gesetzlich vorzuschreiben.
Hatte die 2008er in einer Promo kostenlos bekommen und dann für 30,-€ auf die 2010 geupgradet. Nutze es ausschließlich wegen der Wörterbücher - blöd nur, dass man die unter Windows separat nutzen kann, was unter Linux nicht möglich ist.
Allein durch die Nichtunterstützung der Open Document Formate ein No-Go.
Nichtmal MS Office 2003, 2007, 2010 ist untereinander richtig kompatibel. Wenn man mit doc-Formaten arbeitet, muss man paar Inkompatibilitäten immer in Kauf nehmen, selbst wenn man eine Version von MS verwendet.
Besser als Libre Office auf jeden Fall, aber ich warte noch dass Kingsoft Office 2012 endlich für Linux erscheint, dann hat man einen vollwertigen Ersatz für MS Office dank guter chinesischer Kopierarbeit.
"... auf jeden Fall, ..."
Das Urteil ist wohl etwas übertrieben positiv.
TextMaker unterstützt unter Linux keinen Formelsatz, ein riesen Manko.
Formeln setzt der geneigte Linuxer mit LaTeX.
Dann kann ich aber Softmake gleich ganz weglassen.
Und wie bekomme ich eine in Latex gesetzte Formel in die Textverarbeitung oder die Präsentation?
Ich kenne nur den Weg über eine Bitmap-Grafik. Kennst du da einen besseren Weg?
VG Max
fuer libreoffice impress gibts ein latex plugin, wo du direkt tex formeln eingeben und spaeter bearbeiten kannst in deiner praesentation
das ist es, für Libre/Open Office gibt es ein Latex-Plugin, einen Formeleditor, man kann ebenfalls Vektorgrafiken laden und als letzte Möglichkeiten auch Bitmapgrafiken aus einem externen Formeleditor.
Bei Softmaker ist nur die letzte Möglichkeit und damit die mit der schlechtesten Qualität möglich. Und das ist schade.
Ich erwähne das, wo ich auch immer kann. Nicht um Softmaker zu schaden, sondern um für diesen Punkt um Nachbesserung zu hoffen. Es hat ja auch beim Open Office Dateiformat (bisher aber nur teilweise) funktioniert. Also hoffe ich auch auf den Formelsatz.
VG Max
Word 2000 ist schneller, sieht in Wine genauso hässlich aus, hat mehr Features und ist kompatibler mit MS Formaten. Ich glaube man könnte es aufm Flohmarkt auch für weniger Geld finden. Wenn ich schon meine Seele verkaufe, dann soll wenigstens alles auch funktionieren.
Die Screenshots sind Word 2007 nicht 2010
Danke für den Hinweis. Wurde korrigiert.
Cheers,
demon
Läuft leider nicht mit 64Bit, sondern nur im 32Bit-Kompatiblitätsmodus
# rpm -ivh softmaker-office-trial-2012-671.x86_64.rpm
Fehler: Fehlgeschlagende Abhängigkeiten:
libX11.so.6 wird benötigt von softmaker-office-2012-671.i386
libXext.so.6 wird benötigt von softmaker-office-2012-671.i386
libXmu.so.6 wird benötigt von softmaker-office-2012-671.i386
libXrender.so.1 wird benötigt von softmaker-office-2012-671.i386
libc.so.6 wird benötigt von softmaker-office-2012-671.i386
libc.so.6(GLIBC_2.0) wird benötigt von softmaker-office-2012-671.i386
libc.so.6(GLIBC_2.1) wird benötigt von softmaker-office-2012-671.i386
libc.so.6(GLIBC_2.1.3) wird benötigt von softmaker-office-2012-671.i386
libc.so.6(GLIBC_2.2) wird benötigt von softmaker-office-2012-671.i386
libdl.so.2 wird benötigt von softmaker-office-2012-671.i386
libdl.so.2(GLIBC_2.0) wird benötigt von softmaker-office-2012-671.i386
libdl.so.2(GLIBC_2.1) wird benötigt von softmaker-office-2012-671.i386
libm.so.6 wird benötigt von softmaker-office-2012-671.i386
libm.so.6(GLIBC_2.0) wird benötigt von softmaker-office-2012-671.i386
libstdc++.so.6 wird benötigt von softmaker-office-2012-671.i386
Ich halte das auch für ein Fake. Das das so'n Fake ist steht im Kleingedruckten. Pfui!
Na und? MS Office (und einige andere Windows-Programme) ist auch immer noch 32-bittig. Solange dadurch keine handfesten Nachteile entstehen, ist es doch egal, ob eine Anwendung nativ auf 64 Bit läuft, oder?
Grueße
Ignatz
So egal ist es nicht!
Nicht jeder möchte eine Schatten 32-Bit Version alled shared objekte haben.
Diese Schatten Versionen in 32bit sind
a) fehler trächtig
b) überflüssig
c) balast im negativem sinne
d) resourcen / cpu / ram / strom fressend
e) kosten zusätzelichen Plattenplatz (auf ssd Installtionen sehr teuer)
und alles nur weil ein Entwicklerteam zu blöd ist die Software sauber zu schreiben. Mit einem saubereremund qualtitativ hochstehendem Quellcode ist es egal ob man ein 32Bit oder 64Bit make anwirft.
Nicht gerade Vertrauenserweckend.
Schlimmer wäre es, falls es nur Faulheit geschuldet ist, dass kein 64-Bit Build existiert... dann wäre das nur eine Marketingblase ...
Jürgen
Findest du nicht, dass die Nachteile ein wenig an den Haaren herbeigezogen sind. Streng genommen ist es sogar so, dass ab einer gewissen Größe sich die Nachteile (bedingt durch die 32Bit-Architektur) sogar relativieren. Wie dem auch sei... Eine neue Idee für unsere allwöchentliche Umfrage ist geboren
Cheers,
demon
Stimmt, an die Shared Objects hab ich nicht gedacht.
Grueße
Ignatz
Imho bringen 64Bit bei einem Office-Paket keine ernsten Vorteile:
32Bit versus 64Bit machen in erster Linie einen breiteren Speicherbus aus.
D.h. mit 64Bit kannst Du Speicher oberhalb der 2, bzw 4GB Grenze direkt ansprechen.
Den angeblichen Performance-Gewinne hast du nur durch mehr direkt ansprechbaren Speicher, sowie größerer Speicherregister - welche mehr Daten in einem Schwung verarbeiten können.
Nur wie oft werde ich ernsthaft Dokumente bearbeiten die mehr als 2GB Arbeitsspeicher belegen? Bei welcher Office-Funktion soll 64Bit optimierter Programmcode spürbar mehr Performance bringen als bei einer 32Bit Variante?
>> a) fehler trächtig
Wieso sollte das vorhandensein von 32Bit Code fehler trächtig sein?
>> b) überflüssig
Solang es 32Bit Software gibt nicht.
>> d) resourcen / cpu / ram / strom fressend
Bullshitt - KDE/Gnome/Firefox/OpenOffice brauchen als Einzelapplikationen schon weit aus mehr CPU-Power als der Unterschied zwischen einem 32Bit compilat einer OfficeVersion und dem 64Bit compilat.
64Bit-Software belegt je int, float usw doppelt soviel Speicher als eine 32Bit Software.
2GB Ram kosten keine 25EUR
Mir wäre neu das "spürbar" mehr CPU-Power benötigt wird, wenn eine Applikation ine einem 64Bit-System im 32Bit Modus läuft. Mit spürbar mein ich Verzögerungen überhalb von 0,1s.
Strom fressend halte ich auch für quatsch - der Arbeitsspeicher wird gerade unter GNU/Linux sonst andersweitig genutzt. Das durch 32Bit-Software in einem 64Bit OS ein höhrer Stromverbrauch spürbar (>2%) ist halte ich für eine gewagte Theorie - insbesondere wenn Du auf SSDs setzt.
>> e) kosten zusätzelichen Plattenplatz (auf ssd Installtionen sehr teuer)
Selbst kleine SSDs mit 32GB Speicherplatz dürften ausreichend sein um eine GNU/Linux-Distro problemlos unterzubringen. Wenn Dir der Speicherplatz "SO" teuer erscheint, frage ich mich warum Du nicht auf eine klassische HDD setzt, da kannst Du viel mehr Geld sparen.
Auch kannst Du viel "wertvollen" Speicherplatz freigebeben indem Du nicht benötigte Manuals, Beispielprogramme und BeispielConfigs löscht.
Moin,
hat schon mal jemand versucht Tabellen von einer Anwendung in die andere zu übertragen?
Ich erzeuge und berechne Tabellen i.d.R. in einer Tabellenkalkulation, das finde ich normal.
Aber danach benötige ich die Tabellen in der Textverarbeitung innerhalb eines Aufsatzes und nicht als Anhang, genau so in der Präsentation. Das ist unter Softmaker noch schlechter gelöst als unter LibreOffice.
Ansonsten ist das Programm der Renner, doch Open/Libre Office ist auch auf meinem Rechner schnell genug.
Fehlende Kompatibiliät zu Open/Libre Office, kein Formeleditor und eingeschränkte Kompatibilität bei Tabellen bei Übertragung zwischen den verschiedenen Programmteilen der gleichen Office Suit, das ist wirklich eine Beschränkung für mich. Also werde ich wohl doch bei Libre Office bleiben.
VG Max