Naja, ich hätte es zu diesem Zeitpunkt noch nicht erwartet. Das offiziell von Microsoft und dann noch BSD-Lizenz! Lasst es euch auf der Zunge zergehen!!!
Die werden den Filter schon so designen, dass beim Export nach ODF die gesamte Formatierung zerschossen wird und sie sich danach hinstellen können um mit geschwellter Brust ein fröhliches "seht ihr, wir haben doch gesagt, dass das Format nichts taugt" zu intonieren ;)
OT: Nichtsdestotrotz gefällt mir das neue Office richtig gut. Die Bedienung ist klasse. Den Schritt hätte OO.org2 schon wagen sollen. Jetzt stehen sie wieder als die größen Nachahmer ohne eigene Ideen da.
Das denke ich auch, wird aber auch für MS auf lange Sicht nicht gut gehen, v.a. wenn due EU ein Äuglein drauf hällt und da es BSD Lizenz ist darf jeder draufgucken und sieht ja wo da gemurkst wurde.
MS hat dies nur auf Druck hin gemacht, da es sonst Add-ins von Drittanbietern geben würde und genau das wird passieren, wenn MS die Formatierungen mit den Eigenen Tools zerschießt.
> Nichtsdestotrotz gefällt mir das neue Office richtig > gut. Die Bedienung ist klasse. Den Schritt hätte > OO.org2 schon wagen sollen. Jetzt stehen sie wieder > als die größen Nachahmer ohne eigene Ideen da.
Wer hatte denn zuerst ein XML-basiertes Dateiformat?
wenn MS aber ihr format bei ISO eingereicht haben,muessen sie sich bereit erklaert haben die patente nicht diskriminierend und fair zu lizensieren oder so. (wie hiess das? RAND?)
Das bedeutet ja nicht mehr, als das sie wenn ihnen mal die Lust vergeht selbst weiter zu arbeiten, es jemand anders machen soll. Die Aktion ist positiv zu bewerten, aber mehr schon nicht.
>Das offiziell von Microsoft und dann noch BSD-Lizenz! Also erst mal ist das Ding in C# (für Windows) programmiert ob das ohne anpassung wirklich in mono läuft? Dürfte man das jetzt nach C portieren und unter die GPL stellen??
Von Christian Richter am Do, 6. Juli 2006 um 15:08 #
Hi!
Also so sehr ich doch für Plattformunabhängigkeit bin, in diesem Fall ist das wirklich unnötig. Das ganze ist doch ein Plugin für MS-Office, wenn ich den Artikel richtig verstanden habe. Und das läuft doch sowieso nur unter Windows. Oder willst Du MS-Office unter Wine starten, um dann per Export-Filter ODT-Dateien zu erzeugen, die mit OpenOffice etc. nativ zu öffnen sind? Das wäre glaube ich etwas umständlich.
Trotzdem habe ich noch so meine Zweifel, was die korrekte Funktion dieses Exporters angeht. Es gibt ja genügend Beispiele. Visio (ich weiß, ist ursprünglich nicht von MS, wurde aber gekauft und von ihnen weiterentwickelt) exportiert theoretisch (!) auch nach SVG. Praktisch kommt aber nur Schrott dabei heraus.
Visio ist schrott nimm Dia (gibts auch für Windows) Ich dachte eigentlich daran den Konverter ganz ohne Word zu verwenden, so dass z.b. mswd2odf meinedatei.doc mir die doofe word datei unter linux umwandelt ohne das ich ein ganzes office dafür starten muss, odf wäre eben praktischer wegen thumbnails und volltextsuche. Natürlich geht das auch über OO oder abiword, aber kleiner und feiner wäre halt besser. Es gab da glaub ich mal was, aber leider lief das nie so richtig.
> Das ganze ist doch ein Plugin für MS-Office, wenn ich den Artikel richtig verstanden habe. Und das läuft doch sowieso nur unter Windows.
Wenn man sich die Quellen mal anguckt, wird der Groesste Teil der Konvertierungsarbeit über XSLT geleistet und ist als solches nicht an die Windows- oder .NET-Plattform gebunden.
Der Artikel stimmt so übrigens nicht. Aktuell ist lediglich Code vorhanden um ODT (OASIS OpenDocumentText) in OOX (MS OpenXML) zu konvertieren und nicht umgekehrt. Bin mal gespannt, wann und ob überhaupt Quellen für die Konvertierung von OOX nach ODT vorliegen wird.
keine Konkurrenz, da »Open XML und ODF für verschiedene Anforderungen entwickelt wurden«
ich hau mich weg. Soll doch wohl beides zur Speicherung von Office-Dokumenten beutzt werden. Ok, Open XML mag etwas schneller zu parsen sein, weil es keinen mixed content erlaubt, aber ansich finde ich diese Aussage sehr witzig.
Wieso? ODF wurde mit der Anforderung entwickelt, möglichst viele Produkte zu haben, die es implementieren. OpenXML wurde mit der Anforderung entwickelt, die Kunden von MS Office weiter an das Produkt MS Office zu binden.
MS hisst die weiße Fahne. Hätte zwar nicht gedacht, daß es schon so früh passiert, aber egal. Daß ausgerechnet MS für Ihr "Brot-und-Butter" Geschäft mit OSS arbeitet, ist echt der Hammer. Damit wird es in Zukunft möglich sein, ODF-Dokumente zu lesen und zu schreiben und damit entfällt ein Update auf neuere MS-Office Versionen, es sei denn man sucht eine neue GUI. Vielleicht wird man auch bald OpenXML mit OpenOffice lesen und schreiben können...
sind wir von Microsoft ja schon gewohnt. Besonders lustig finde ich die Tatsache, das Microsoft sich der Sache nicht selbst annimmt, sondern dies wieder mal von externen Dienstleistern machen lässt. (Zugegeben, hier ist auch viel Know-how bei der Entschwurbelung der MS-Office-Formate vorhanden). Die BSD-Lizenz für den Konverter, naja... Da Microsoft den Konverter ja in das eigene Office-Paket einbauen will, andererseits auch unbezahlte Mitarbeiter gelockt werden sollen, ist das wohl ein Kompromiss.
Mich beschleicht aber wieder mal der Verdacht, dass es sich mal wieder nur um einen Marketingschachzug handelt, und der Konverter, wenn man genug Leute vom Wechsel zu OpenOffice.org abgehalten hat, ganz schnell wieder unwirksam gemacht wird, indem Microsoft mal wieder einige propietäre "Verbesserungen" an ihrem Office-Paket vornimmt, die dann natürlich nur das eigene Office-Paket nach ODF konvertieren kann.
Könnte man natürlich abschließend noch die Frage stellen: Was ist mit Metro? In der Versenkung verschwunden?
> Besonders lustig finde ich die Tatsache, das Microsoft > sich der Sache nicht selbst annimmt, sondern dies wieder > mal von externen Dienstleistern machen lässt.
Tja, wenn man sich einen Dienstleister leisten kann, dann leistet man sich halt hier und da einen Besonders lustig finde ich übrigens, dass Du das lustig findest. Gewisse andere Betriebssystemhersteller lassen nämlich auch vieles von externen "Dienstleistern" erledigen, bezahlen diese "Dienstleister" aber nicht mal dafür.
> Die BSD-Lizenz für den Konverter, naja... Da Microsoft den > Konverter ja in das eigene Office-Paket einbauen will, > andererseits auch unbezahlte Mitarbeiter gelockt werden > sollen, ist das wohl ein Kompromiss.
Die BSD-Lizenz dient nicht dazu, "unbezahlte Mitarbeiter" zu "locken" (dieses Vorgehen pflegen Linux-Distributoren und nicht Microsoft), sowas hat ein Konzern mit einem zweistelligen Milliardenbetrag in der Portokasse nämlich gar nicht nötig.
Von FS2004 -> Schrott am Di, 11. Juli 2006 um 20:11 #
> Die BSD-Lizenz dient nicht dazu, "unbezahlte Mitarbeiter" zu "locken" (dieses Vorgehen pflegen > Linux-Distributoren und nicht Microsoft), sowas hat ein Konzern mit einem zweistelligen Milliardenbetrag > in der Portokasse nämlich gar nicht nötig.
LOL. Also ohne Addons von Drittanbietern ist der Microsoft Flight Simulator absoluter Schrott und nicht zu gebrauchen. Insbesondere was die Flugzeuge und deren Simulierung anbelangt.
> Mich beschleicht aber wieder mal der Verdacht, dass es sich mal wieder nur um einen Marketingschachzug handelt ..
meiner meinung kommt die offizelle unterstützung aufgrund des drucks diverser behörden. für MS ist es vor allem wichtig marktanteile zu halten. auf den ersten blick war es deshalb sinnvoll ODF nicht zu unterstützt, damit hätte man die mirgation nach OOo oder anderen ODF-kompatiblen programmen nur erleichtert. bei den aktuellen marktanteilen ist es sinnvoller zu anderen programmen inkompatibel zu sein. wie man in den vergangenen wochen aber gelesen hat, streben viele behörden aus unterschiedlichsten teilen der welt an offene formate zu verwenden. teilweise will man ODF sogar zum einzigen format machen, über welches behörden dokumente austauschen. würde MS office also nicht mit ODF zurecht kommen, würde es schon mal bei den behörden schon mal nicht zum einsatz kommen. leute die mit diesen behörden dokumenten austauschen müssen wären noch gezwungen OOo zumindest zusätzlich zu installieren. was aber unter umständen auch den ein oder anderen anwender veranlassen könnte gleich ganz umzusteigen.
kurz gesagt: durch die aktuellen entwicklungen ist es für MS wohl das kleinere übel ODF zu unterstützten.
> Besonders lustig finde ich die Tatsache, das Microsoft sich der Sache nicht selbst > annimmt, sondern dies wieder mal von externen Dienstleistern machen lässt.
Ich denke, das war Microsoft einfach zu heiß. Der Quellcode soll ja offen sein, d.h. man muss sich schon ein wenig Mühe geben, um sich nicht zu blamieren. Ob da die MS-Code-Knechte schon drauf eingestellt sind, wage ich zu bezweifeln.
Will MS sich damit nicht aus der Strafe rauswringen? Da können die doch sagen: Seht her, EU, wir haben eure Auflagen erfüllt. Dass das nicht stimmt, weis ja wohl jedes Kind.
Ausserdem bin ich der Meinung des Vorposters, dass MS eigene proprietäre Erweiterungen einbaut, die das ganze wieder unbrauchbar machen. Nee, weis schon warum ich kein MS benutze.
> Ausserdem bin ich der Meinung des Vorposters, dass MS eigene > proprietäre Erweiterungen einbaut, die das ganze wieder > unbrauchbar machen.
Aber das macht doch nichts. Schließlich ist es OpenSource, also kann jeder diese proprietären Erweiterungen, die Deiner "Meinung" nach eingebaut werden, direkt im Quelltext ausfindig machen und selbst entfernen.
Wohl kaum. Die BSDL erlaubt Microsoft ja nun gerade wieder, in die fertig kompilierte Version einige Extras und "Verbesserungen" einzubauen, die im BSDLed-Quellcode auf sourceforge nicht zu sehen sein werden. Eine sehr raffinierte Methode embrace & extend zu verschleiern.
So einfach ist die Sache in diesem Fall für MS nun auch wieder nicht :
1. ODF ist ein standardisiertes ISO-Format, d.h. anders als HTML, das man nach Belieben verwässern konnte, darf MS den ODF-Standard nicht einfach verwässern und inkompatibel machen. Ein Format das nicht mehr kompatibel ist zum ISO-Standard, darf nicht mehr ISO-konform beworben werden und bei entsprechender Gesetzeslage nicht mehr eingesetzt werden (z.B. in Behörden, usw.).
2. Die Tools die MS gerade entwickelt, stehen alle unter einer BSD-Lizenz. Jeder kann also die Tools nehmen und verbessern. Wenn MS sich entschliesst ein inkompatibles ODF-Format zu erstellen, bedient sich halt jemand an den BSD-Quellen der Tools und macht einen wieder-kompatiblen Fork auf.
Ich glaube der einzige Grund warum MS jetzt kleinbei gibt, ist folgender :
Wenn ein Land dazu entschliesst für die behördliche Kommunikation nur noch ISO-konforme Dokumentenformate zu erlauben, würde sich MS sehr schnell selbst in Abseits manövrieren, wenn sie kein entsprechendes Produkt anbieten würden. Wenn ein Staat mal so etwas vorgeschrieben hat, müssen sich auch alle Firmen die Staatsaufträge wollen, daran halten. Und diese arbeiten mit anderen Firmen zusammen, usw.
Wer behauptet denn das ein ISO-konformes Dateiformat den Austausch von Dokumenten zwischen unterschiedlichen Programmen erlaubt?
Man versuche mal ein etwas komplizierteres ODF Dokument das in OO erstellt wurde mit Koffice zu öffnen. Das erkennt man gar nicht mehr wieder ;-)
Ein mit MS-Office erstelltes Dokument wird sich nur mit erhebliche Abstriche mit OO öffnen lassen. Ich vermute einmal so ähnlich wie OO heute schon MS-Word Dokumente öffnen und darstellen kann.
Oder glaubt jemand das OO plötzlich Visual-Basic Macros verstehen und verarbeiten kann?
ODF ist eine tolle Sache, aber es ist nicht die Lösung allen Übels im Officebereich!
Da kann ich dir nur zustimmen. So viel erstklassige Software, aber untereinander kompatibel von der Sicht des Nutzers sind sie nicht. Leider fuehrt ein auch das wieder in eine Monokultur im Office-Bereich. Zwei Anwendungen die einen fast problemlosen Austausch ermoeglichen sollten sind dann StarOffice und OpenOffice.org und das ist dann schon fast sinnlos. Sobald hier massive Probleme auftauchen werden sich die "Entscheider" fragen was nun das kleinere Uebel ist. Schliesslich ist AUCH EINES der Ziele der Erhalt von Informationen. Die Loesung ist recht einfach, Firmen/Organisationen usw. die OpenOffice.org, KOffice oder eine andere freie (-> bzgl. komerziell und Lizenz) sollten Projekte finanziell unterstuetzen, zumal ein Grossteil der Kosten entfaellt, so dass bespielsweise Entwickler motiviert oder sogar eingestellt werden koennen die Stabilitaet und Funktionsumfang ausbauen. Aber solche eine Kultur zu erwarten ist wohl blauaugig. Wie viele oss-Nutzer haben jemals etwas beigetragen. Es ist traurigerweise die Minderheit.
> Man versuche mal ein etwas komplizierteres ODF Dokument das in OO erstellt wurde mit Koffice zu öffnen. Abwarten. Mit jeder neuen Version werden die beiden kompatibler und immer mehr Software taucht auf, die den Umgang mit OD beherrscht.
> Oder glaubt jemand das OO plötzlich Visual-Basic Macros verstehen und verarbeiten kann? Hat Novel da nicht vor kurzem einen größeren commit in OOo gelandet um die VB(A)-Unterstützung weiter auszubauen?
> ODF ist eine tolle Sache, aber es ist nicht die Lösung allen Übels im Officebereich! Jedenfalls nicht, solange es nicht möglich ist damit Kaffee zu kochen
> Abwarten. Mit jeder neuen Version werden die beiden kompatibler und immer mehr Software taucht auf, die den Umgang mit OD beherrscht.
Ja, mag sein, ich wünsche es mir auf jedenfall sehnlichst. Nur werden die Programme immer einen unterschiedlichen Funktionsumfang haben, deshalb wird Programm A eine beliebige Datei anders (oder fehlerhaft oder lückenhaft) als Programm B darstellen
> Hat Novel da nicht vor kurzem einen größeren commit in OOo gelandet um die VB(A)-Unterstützung weiter auszubauen?önnen. Stimmt, aber die Unterstützung ist trotzdem minimal. Und ohne Nacharbeiten läuft fast nichts. Diese Erweiterungen sind nicht dafür gedacht mal eben ein Visual Basic Macro abzuspielen. Wie ich es verstanden habe ist nicht geplant den gesamten Umfang von VBA nutzbar zu machen. Meiner persönlichen Erfahrung nach liegt OO im Bereich Makros Jahre bis Jahrzehnte hinter MS-Office.
> Nur werden die Programme immer einen unterschiedlichen Funktionsumfang haben, deshalb wird Programm A eine beliebige Datei anders (oder fehlerhaft oder lückenhaft) als Programm B darstellen
Eine beliebige Datei? Komisch nur, daß ich hier bereits heute einige dutzend ODTs rumfliegen habe, die sich ohne Probleme zwischen Abiword, KWord und OOo-writer austauschen lassen. Mit zunehmender Zeit dürften wohle auch die Unterschiede schwinden. Jene Tags die nicht zu den Grundfunktionalitäten (MUST, REQUIRED, SHOULD und RECOMMEDED) gehört mag in Anwendungen lückenhaft oder überhaupt nicht implementiert sein (jedenfalls solange kein Bedarf besteht), mindert die Editier- und Verarbeitbarkeit jedoch nicht. Schließlich werden nicht implementierte Tags einfach iggnoriert und beim zurückschreiben wieder übernommen.
> Meiner persönlichen Erfahrung nach liegt OO im Bereich Makros Jahre bis Jahrzehnte hinter MS-Office.
Im Bereich propitäre MS VBA-Makros sicherlich. Bei Java und Python hat OOo gegenüber MS-Office wohl Jahre bis Jahrzente Vorsprung
Du hast recht, das Wort beliebig ist fehl am Platze. Was ich eigentlich sagen wollte ist das kompliziertere Dokumente große Probleme machen könnten.
In Sachen Editierbarkeit muss ich dir allerdings wiedersprechen. Ein Dokument das nur teilweise angezeigt werden kann ist selbstverständlich nicht Editierbar. Es sei denn man hat das große Glück das genau der nicht dargestellte Bereich völlig unwichtig ist. In der Praxis kommt so etwas allerdings nicht allzu häufig vor. Die Qualitätssicherung in Firmen wird einem auch den Kopf abreißen :-)
Beispiel: Gebrauchsanweisung zur Haltung von Würgeschlangen. Würgeschlangen essen keine Menschen. (Nun der nicht darstellbare Bereich) Es sei denn sie haben großen Hunger!
Könnte zu Problemen mit der werten (Ex)Kundschaft führen ;-)
Im Endeffekt muss man sich doch wieder auf ein bestimmtes Programm einigen.
> In Sachen Editierbarkeit muss ich dir allerdings wiedersprechen. Ein Dokument das nur teilweise angezeigt werden kann ist selbstverständlich nicht Editierbar. Jaein. Sicherlich werden umfangreiche Dokumente mit Formularmasken hinter denen eine ausgefeilte Geschäftslogik steckt, auf absehbarer Zeit wohl stets an genau einem Programm und ggf. sogar an genau eine Version einies Programmes gebunden sein. Der größte Teil an im Internet zu findenden Dokumenten nutzt jedoch gerade mal wenige Prozente der Gesamtfunktionalität die beispielsweise durch einen Word-Processor zur Verfügung gestellt werden. Diese Grundfunktionalität wird ohne Zweifel entsprechend abgedeckt und ist damit transportabel. Um dein schönes Beispiel aufzugreifen: Der Verfasser des "(Nun der nicht darstellbare Bereich)" müßte eben jenen Absatz schon in einer Weise eingebracht haben (z.B. durch einen dynamischen onload-StarBasic-hock oder durch Einbettung von OLE), die nicht durch OpenDocument abgedeckt wird und genau das soll mit der Stanardisierung ja vermieden werden. Die Geschichte von HTML und der Kompatibilität der Browser zeigt hier wohl relativ gut, was möglich ist. Sicherlich gibt es immer den einen oder den anderen Browser, der die eine oder die andere Seite anders darstellt. Komplett fehlerhafte/andere Darstellungen von Inhalten bei betrachten derselben Seite mit z.B. Opera und ff sind jedoch eine Seltenheit. Mit dem Resultat, daß der Anwender die Wahl hat, welchen Browser er den zu nutzen wünscht.
Embrace und extend ist vorbei. Nicht einmal Microsoft kann es sich noch leisten einen ODF Exportfilter zu schreiben der nicht-Standardkonformes ODF schreibt.
Denn diejenigen die ODF einsetzen werden, werden natürlich in ihren Ausschreibungen hineinschreiben: Bürosoftware die die Dateiformate des ISO 26300 Standards sowohl lesend als auch schreibend unterstützt.
Wenn dann MS Office keine ISO 26300 -konforme Dateien schreiben kann fällt es automatisch aus, selbst wenns gratis wäre.
Nönö, das Nebengleis auf dem MS Office bisher unterwegs war nähert sich sehr schnell dem nächsten großen Verschubbahnhof, von wo aus man in alle Richtungen gelangen kann.
Genauso sehe ich das auch. Microsofts primäres Ziel (wie auch das jedes anderen Unternehmens) ist eine hervorragende Marktposition. Die geschlossenen Dateiformate waren ein probates Mittel, die Marktposition zu halten, solange es ging. Jetzt, wo das nicht mehr geht und auch keiner das "Ausweichprodukt" möchte, ist man prompt in der Lage, sein Fähnchen in den Wind zu halten und bietet einen Filter an, ohne dabei sein Gesicht zu verlieren.
Und was machen wir? Wir haben mit OpenDocument ein Format, das genau den Ansprüchen gerecht wird, die wir uns immer gewünscht haben. Darüber sollte man sich freuen und auch Microsoft willkommenheissen, wenn sie sich mit ins Boot setzen.
Man wartet ein bisschen, baut dann irgendwelche Erweiterungen in und muss diese dank BSD nicht mehr freigeben. Der User ist auf ein fertiges Binary angewiesen, denn aus dem Sourcecode kann er ja keinen vollständigen Konverter mehr erzeugen, und ohne dieses kann dann eben die nächste Version von Open XML nicht mehr 100% konvertiert werden. Da 90% der User sowieso Office haben bleiben sie dann doch lieber bei Open XML, der Konvertierungsaufwand bleibt an den Nutzern anderer Office-Pakete hängen, und die müssen sich am Ende dann ein "Nimm doch auch Microsoft Office und speichers in OpenXML, dein ODF kommt hier immer so kaputt ausm Konverter" anhören.
Also alles wie vorher, nur mit OpenXML statt XLS und DOC. Danke Microsoft. Ihr wisst schon warum ihr nicht einfach einen normalen Importfilter liefert.
Ich denke die Spezifikation von OpenXML sind frei zugänglich? Also würden prop. Versionen nicht viel bringen. Ich glaube MS möchte nur ein Zeh in der Tür gehalten und kein Gesichtsverlust erleiden.
Andererseits könnten ja auch andere Programme(z.B. OpenOffice) diesen Konverter benutzen, was ja vielleicht gar nicht so schlecht ist.
Es beschleicht mich das ungute Gefühl, dass Microsoft das Produnkt deshalb von einer anderen Firma entwickeln lässen, damit nicht negative auf sie zurückfallen kann (was auch immer).
Word-Dokumente werden niemals zur Zufriedenheit der Anwender nach ODF exportiert werden können. Das MS-Office-Format ist intern ein zusammengeschusterter Sauhaufen sondergleichen, der nur mit vielen Einschränkungen in andere Formate zu konvertieren ist (gerade bei komplexeren Dateien mit Tabellen, Fußnoten, Bildern,...) Der Import wird hingegen zu 100% Standard-konform ablaufen.
Somit werden viele bisherige .doc-Verwender den Export einmal testen, aber aufgrund mangelnder Zufriedenheit gleich wieder ad acta legen. Wobei im typischen Büro ohnehin die Endung .doc als Synonym für Textverarbeitung steht und so gut wie niemand weiß, dass es überhaupt andere Dateiformate gibt. Wobei eingehende Dokumente im ODF-Format ja kein Problem darstellen werden - der Import wird ja zu 100% klappen.
Fazit: vielleicht ändert sich was in der Verwaltung von Massachusetts, aber das war's auch schon. Der Einbau des ODF-Imports wird die Marktposition von MS zementieren, da auch künftig kein MS-Office-Anwender (egal welche Version) ein Problem bei Import von ODF bekommen wird.
> Word-Dokumente werden niemals zur Zufriedenheit der Anwender nach ODF exportiert werden können Das kann sich MS nicht erlauben. Glücklicherweise wird in der Industrie nach ISO-Standards gefragt. Ein halbfunktionierender Exportfilter wäre kontraproduktiv für die Marktposition von MS Office.
> Der Einbau des ODF-Imports wird die Marktposition von MS zementieren Wo ist denn dann noch das Problem, wenn jeder mit MS Office meine ODFs lesen und ändern kann? Wenn MS Office diese Anforderungen erfüllt und nebenbei ein gutes Office ist, dann haben sie sich das Geld verdient, das man ihnen bezahlt.
....mal auf DOSisch formuliert, jetzt glaubt schon Microsoft, komische Möchtegernstandards hätten Zukunft!!-:) Standart ist HTML, natürlich haben auch Latex und vielleicht auch groff ihre Daseinsberechtigung, zu versenden ist das aber in einen HTML-kompatiblen Zustand, PDF macht noch Konkurrenz (Umstiegssache), wird aber sicher auch bald verschwinden, der Artikel erinnert mich an die lustigen Zeiten, in denen DAUs .doc für'n Standart hielten.
Das offiziell von Microsoft und dann noch BSD-Lizenz! Lasst es euch auf der Zunge zergehen!!!
What a nice day...
OT:
Nichtsdestotrotz gefällt mir das neue Office richtig gut. Die Bedienung ist klasse. Den Schritt hätte OO.org2 schon wagen sollen. Jetzt stehen sie wieder als die größen Nachahmer ohne eigene Ideen da.
MS hat dies nur auf Druck hin gemacht, da es sonst Add-ins von Drittanbietern geben würde und genau das wird passieren, wenn MS die Formatierungen mit den Eigenen Tools zerschießt.
Ja und? Wenn es nicht als SRC veröffentlicht wird, kannste nich draufschauen. M$ benutzt schon längst andere BSD-Tools.
> nach ODF die gesamte Formatierung zerschossen wird
Aber das macht ja nichts. Schließlich ist es OpenSource, also kann es jeder, der von diesem Problem betroffen ist, selber fixen.
> gut. Die Bedienung ist klasse. Den Schritt hätte
> OO.org2 schon wagen sollen. Jetzt stehen sie wieder
> als die größen Nachahmer ohne eigene Ideen da.
Wer hatte denn zuerst ein XML-basiertes Dateiformat?
http://www.php4you.de/against_icq.html
http://forum.php4you.de/
Ging es nicht nur um import?
IMHO liegt die Keule im Patent auf die Nutzung des M$ XML Formates.
ich
Es müssen nicht die Endverbraucher Lizenzen für Patente zahlen (was "fair" wäre), sondern die Entwickler, die mit dem Code arbeiten.
Also erst mal ist das Ding in C# (für Windows) programmiert ob das ohne anpassung wirklich in mono läuft? Dürfte man das jetzt nach C portieren und unter die GPL stellen??
Also so sehr ich doch für Plattformunabhängigkeit bin, in diesem Fall ist das wirklich unnötig. Das ganze ist doch ein Plugin für MS-Office, wenn ich den Artikel richtig verstanden habe. Und das läuft doch sowieso nur unter Windows.
Oder willst Du MS-Office unter Wine starten, um dann per Export-Filter ODT-Dateien zu erzeugen, die mit OpenOffice etc. nativ zu öffnen sind?
Das wäre glaube ich etwas umständlich.
Trotzdem habe ich noch so meine Zweifel, was die korrekte Funktion dieses Exporters angeht. Es gibt ja genügend Beispiele. Visio (ich weiß, ist ursprünglich nicht von MS, wurde aber gekauft und von ihnen weiterentwickelt) exportiert theoretisch (!) auch nach SVG. Praktisch kommt aber nur Schrott dabei heraus.
Frohes schwitzen noch! :-)
Christian
Ich dachte eigentlich daran den Konverter ganz ohne Word zu verwenden, so dass z.b.
mswd2odf meinedatei.doc
mir die doofe word datei unter linux umwandelt ohne das ich ein ganzes office dafür starten muss, odf wäre eben praktischer wegen thumbnails und volltextsuche. Natürlich geht das auch über OO oder abiword, aber kleiner und feiner wäre halt besser. Es gab da glaub ich mal was, aber leider lief das nie so richtig.
Mach damit einfach mal ein ERD, dann siehste was ich meine.
Wenn man sich die Quellen mal anguckt, wird der Groesste Teil der Konvertierungsarbeit über XSLT geleistet und ist als solches nicht an die Windows- oder .NET-Plattform gebunden.
ich hau mich weg.
Soll doch wohl beides zur Speicherung von Office-Dokumenten beutzt werden.
Ok, Open XML mag etwas schneller zu parsen sein, weil es keinen mixed content erlaubt, aber ansich finde ich diese Aussage sehr witzig.
Wieso? ODF wurde mit der Anforderung entwickelt, möglichst viele Produkte zu haben, die es implementieren. OpenXML wurde mit der Anforderung entwickelt, die Kunden von MS Office weiter an das Produkt MS Office zu binden.
Mich beschleicht aber wieder mal der Verdacht, dass es sich mal wieder nur um einen Marketingschachzug handelt, und der Konverter, wenn man genug Leute vom Wechsel zu OpenOffice.org abgehalten hat, ganz schnell wieder unwirksam gemacht wird, indem Microsoft mal wieder einige propietäre "Verbesserungen" an ihrem Office-Paket vornimmt, die dann natürlich nur das eigene Office-Paket nach ODF konvertieren kann.
Könnte man natürlich abschließend noch die Frage stellen: Was ist mit Metro? In der Versenkung verschwunden?
> sich der Sache nicht selbst annimmt, sondern dies wieder
> mal von externen Dienstleistern machen lässt.
Tja, wenn man sich einen Dienstleister leisten kann, dann leistet man sich halt hier und da einen
Besonders lustig finde ich übrigens, dass Du das lustig findest. Gewisse andere Betriebssystemhersteller lassen nämlich auch vieles von externen "Dienstleistern" erledigen, bezahlen diese "Dienstleister" aber nicht mal dafür.
> Die BSD-Lizenz für den Konverter, naja... Da Microsoft den
> Konverter ja in das eigene Office-Paket einbauen will,
> andererseits auch unbezahlte Mitarbeiter gelockt werden
> sollen, ist das wohl ein Kompromiss.
Die BSD-Lizenz dient nicht dazu, "unbezahlte Mitarbeiter" zu "locken" (dieses Vorgehen pflegen Linux-Distributoren und nicht Microsoft), sowas hat ein Konzern mit einem zweistelligen Milliardenbetrag in der Portokasse nämlich gar nicht nötig.
Ich glaube nicht, das liegt bestimmt am niedrigen Niveau hier im Linux-Forum.
> Linux-Distributoren und nicht Microsoft), sowas hat ein Konzern mit einem zweistelligen Milliardenbetrag
> in der Portokasse nämlich gar nicht nötig.
LOL.
Also ohne Addons von Drittanbietern ist der Microsoft Flight Simulator absoluter Schrott und
nicht zu gebrauchen.
Insbesondere was die Flugzeuge und deren Simulierung anbelangt.
meiner meinung kommt die offizelle unterstützung aufgrund des drucks diverser behörden.
für MS ist es vor allem wichtig marktanteile zu halten. auf den ersten blick war es deshalb sinnvoll ODF nicht zu unterstützt, damit hätte man die mirgation nach OOo oder anderen ODF-kompatiblen programmen nur erleichtert. bei den aktuellen marktanteilen ist es sinnvoller zu anderen programmen inkompatibel zu sein.
wie man in den vergangenen wochen aber gelesen hat, streben viele behörden aus unterschiedlichsten teilen der welt an offene formate zu verwenden. teilweise will man ODF sogar zum einzigen format machen, über welches behörden dokumente austauschen. würde MS office also nicht mit ODF zurecht kommen, würde es schon mal bei den behörden schon mal nicht zum einsatz kommen. leute die mit diesen behörden dokumenten austauschen müssen wären noch gezwungen OOo zumindest zusätzlich zu installieren. was aber unter umständen auch den ein oder anderen anwender veranlassen könnte gleich ganz umzusteigen.
kurz gesagt: durch die aktuellen entwicklungen ist es für MS wohl das kleinere übel ODF zu unterstützten.
> annimmt, sondern dies wieder mal von externen Dienstleistern machen lässt.
Ich denke, das war Microsoft einfach zu heiß. Der Quellcode soll ja offen sein, d.h. man muss sich schon ein wenig Mühe geben, um sich nicht zu blamieren. Ob da die MS-Code-Knechte schon drauf eingestellt sind, wage ich zu bezweifeln.
Dass das nicht stimmt, weis ja wohl jedes Kind.
Ausserdem bin ich der Meinung des Vorposters, dass MS eigene proprietäre Erweiterungen einbaut, die das ganze wieder unbrauchbar machen.
Nee, weis schon warum ich kein MS benutze.
Al
> proprietäre Erweiterungen einbaut, die das ganze wieder
> unbrauchbar machen.
Aber das macht doch nichts. Schließlich ist es OpenSource, also kann jeder diese proprietären Erweiterungen, die Deiner "Meinung" nach eingebaut werden, direkt im Quelltext ausfindig machen und selbst entfernen.
1. ODF ist ein standardisiertes ISO-Format, d.h. anders als HTML, das man nach Belieben verwässern konnte, darf MS den ODF-Standard nicht einfach verwässern und inkompatibel machen. Ein Format das nicht mehr kompatibel ist zum ISO-Standard, darf nicht mehr ISO-konform beworben werden und bei entsprechender Gesetzeslage nicht mehr eingesetzt werden (z.B. in Behörden, usw.).
2. Die Tools die MS gerade entwickelt, stehen alle unter einer BSD-Lizenz. Jeder kann also die Tools nehmen und verbessern. Wenn MS sich entschliesst ein inkompatibles ODF-Format zu erstellen, bedient sich halt jemand an den BSD-Quellen der Tools und macht einen wieder-kompatiblen Fork auf.
Ich glaube der einzige Grund warum MS jetzt kleinbei gibt, ist folgender :
Wenn ein Land dazu entschliesst für die behördliche Kommunikation nur noch ISO-konforme Dokumentenformate zu erlauben, würde sich MS sehr schnell selbst in Abseits manövrieren, wenn sie kein entsprechendes Produkt anbieten würden. Wenn ein Staat mal so etwas vorgeschrieben hat, müssen sich auch alle Firmen die Staatsaufträge wollen, daran halten. Und diese arbeiten mit anderen Firmen zusammen, usw.
Man versuche mal ein etwas komplizierteres ODF Dokument das in OO erstellt wurde mit Koffice zu öffnen.
Das erkennt man gar nicht mehr wieder ;-)
Ein mit MS-Office erstelltes Dokument wird sich nur mit erhebliche Abstriche mit OO öffnen lassen.
Ich vermute einmal so ähnlich wie OO heute schon MS-Word Dokumente öffnen und darstellen kann.
Oder glaubt jemand das OO plötzlich Visual-Basic Macros verstehen und verarbeiten kann?
ODF ist eine tolle Sache, aber es ist nicht die Lösung allen Übels im Officebereich!
Gruß
Mark
Abwarten. Mit jeder neuen Version werden die beiden kompatibler und immer mehr Software taucht auf, die den Umgang mit OD beherrscht.
> Oder glaubt jemand das OO plötzlich Visual-Basic Macros verstehen und verarbeiten kann?
Hat Novel da nicht vor kurzem einen größeren commit in OOo gelandet um die VB(A)-Unterstützung weiter auszubauen?
> ODF ist eine tolle Sache, aber es ist nicht die Lösung allen Übels im Officebereich!
Jedenfalls nicht, solange es nicht möglich ist damit Kaffee zu kochen
Ja, mag sein, ich wünsche es mir auf jedenfall sehnlichst.
Nur werden die Programme immer einen unterschiedlichen Funktionsumfang haben, deshalb wird Programm A eine beliebige Datei anders (oder fehlerhaft oder lückenhaft) als Programm B darstellen
> Hat Novel da nicht vor kurzem einen größeren commit in OOo gelandet um die VB(A)-Unterstützung weiter auszubauen?önnen.
Stimmt, aber die Unterstützung ist trotzdem minimal. Und ohne Nacharbeiten läuft fast nichts.
Diese Erweiterungen sind nicht dafür gedacht mal eben ein Visual Basic Macro abzuspielen.
Wie ich es verstanden habe ist nicht geplant den gesamten Umfang von VBA nutzbar zu machen.
Meiner persönlichen Erfahrung nach liegt OO im Bereich Makros Jahre bis Jahrzehnte hinter MS-Office.
Eine beliebige Datei? Komisch nur, daß ich hier bereits heute einige dutzend ODTs rumfliegen habe, die sich ohne Probleme zwischen Abiword, KWord und OOo-writer austauschen lassen. Mit zunehmender Zeit dürften wohle auch die Unterschiede schwinden.
Jene Tags die nicht zu den Grundfunktionalitäten (MUST, REQUIRED, SHOULD und RECOMMEDED) gehört mag in Anwendungen lückenhaft oder überhaupt nicht implementiert sein (jedenfalls solange kein Bedarf besteht), mindert die Editier- und Verarbeitbarkeit jedoch nicht. Schließlich werden nicht implementierte Tags einfach iggnoriert und beim zurückschreiben wieder übernommen.
> Meiner persönlichen Erfahrung nach liegt OO im Bereich Makros Jahre bis Jahrzehnte hinter MS-Office.
Im Bereich propitäre MS VBA-Makros sicherlich. Bei Java und Python hat OOo gegenüber MS-Office wohl Jahre bis Jahrzente Vorsprung
Was ich eigentlich sagen wollte ist das kompliziertere Dokumente große Probleme machen könnten.
In Sachen Editierbarkeit muss ich dir allerdings wiedersprechen. Ein Dokument das nur teilweise angezeigt werden kann ist selbstverständlich nicht Editierbar. Es sei denn man hat das große Glück das genau der nicht dargestellte Bereich völlig unwichtig ist. In der Praxis kommt so etwas allerdings nicht allzu häufig vor. Die Qualitätssicherung in Firmen wird einem auch den Kopf abreißen :-)
Beispiel:
Gebrauchsanweisung zur Haltung von Würgeschlangen.
Würgeschlangen essen keine Menschen.
(Nun der nicht darstellbare Bereich)
Es sei denn sie haben großen Hunger!
Könnte zu Problemen mit der werten (Ex)Kundschaft führen ;-)
Im Endeffekt muss man sich doch wieder auf ein bestimmtes Programm einigen.
Gruß
Mark
Jaein. Sicherlich werden umfangreiche Dokumente mit Formularmasken hinter denen eine ausgefeilte Geschäftslogik steckt, auf absehbarer Zeit wohl stets an genau einem Programm und ggf. sogar an genau eine Version einies Programmes gebunden sein.
Der größte Teil an im Internet zu findenden Dokumenten nutzt jedoch gerade mal wenige Prozente der Gesamtfunktionalität die beispielsweise durch einen Word-Processor zur Verfügung gestellt werden. Diese Grundfunktionalität wird ohne Zweifel entsprechend abgedeckt und ist damit transportabel.
Um dein schönes Beispiel aufzugreifen: Der Verfasser des "(Nun der nicht darstellbare Bereich)" müßte eben jenen Absatz schon in einer Weise eingebracht haben (z.B. durch einen dynamischen onload-StarBasic-hock oder durch Einbettung von OLE), die nicht durch OpenDocument abgedeckt wird und genau das soll mit der Stanardisierung ja vermieden werden.
Die Geschichte von HTML und der Kompatibilität der Browser zeigt hier wohl relativ gut, was möglich ist. Sicherlich gibt es immer den einen oder den anderen Browser, der die eine oder die andere Seite anders darstellt. Komplett fehlerhafte/andere Darstellungen von Inhalten bei betrachten derselben Seite mit z.B. Opera und ff sind jedoch eine Seltenheit. Mit dem Resultat, daß der Anwender die Wahl hat, welchen Browser er den zu nutzen wünscht.
Denn diejenigen die ODF einsetzen werden, werden natürlich in ihren Ausschreibungen hineinschreiben: Bürosoftware die die Dateiformate des ISO 26300 Standards sowohl lesend als auch schreibend unterstützt.
Wenn dann MS Office keine ISO 26300 -konforme Dateien schreiben kann fällt es automatisch aus, selbst wenns gratis wäre.
Nönö, das Nebengleis auf dem MS Office bisher unterwegs war nähert sich sehr schnell dem nächsten großen Verschubbahnhof, von wo aus man in alle Richtungen gelangen kann.
Und was machen wir? Wir haben mit OpenDocument ein Format, das genau den Ansprüchen gerecht wird, die wir uns immer gewünscht haben. Darüber sollte man sich freuen und auch Microsoft willkommenheissen, wenn sie sich mit ins Boot setzen.
lg
Erik
Also alles wie vorher, nur mit OpenXML statt XLS und DOC. Danke Microsoft. Ihr wisst schon warum ihr nicht einfach einen normalen Importfilter liefert.
Andererseits könnten ja auch andere Programme(z.B. OpenOffice) diesen Konverter benutzen, was ja vielleicht gar nicht so schlecht ist.
Somit werden viele bisherige .doc-Verwender den Export einmal testen, aber aufgrund mangelnder Zufriedenheit gleich wieder ad acta legen. Wobei im typischen Büro ohnehin die Endung .doc als Synonym für Textverarbeitung steht und so gut wie niemand weiß, dass es überhaupt andere Dateiformate gibt. Wobei eingehende Dokumente im ODF-Format ja kein Problem darstellen werden - der Import wird ja zu 100% klappen.
Fazit: vielleicht ändert sich was in der Verwaltung von Massachusetts, aber das war's auch schon. Der Einbau des ODF-Imports wird die Marktposition von MS zementieren, da auch künftig kein MS-Office-Anwender (egal welche Version) ein Problem bei Import von ODF bekommen wird.
Das kann sich MS nicht erlauben. Glücklicherweise wird in der Industrie nach ISO-Standards gefragt. Ein halbfunktionierender Exportfilter wäre kontraproduktiv für die Marktposition von MS Office.
> Der Einbau des ODF-Imports wird die Marktposition von MS zementieren
Wo ist denn dann noch das Problem, wenn jeder mit MS Office meine ODFs lesen und ändern kann? Wenn MS Office diese Anforderungen erfüllt und nebenbei ein gutes Office ist, dann haben sie sich das Geld verdient, das man ihnen bezahlt.
lg
Erik
komische Möchtegernstandards hätten Zukunft!!-:)
Standart ist HTML, natürlich haben auch Latex und vielleicht auch groff
ihre Daseinsberechtigung, zu versenden ist das aber in einen HTML-kompatiblen Zustand,
PDF macht noch Konkurrenz (Umstiegssache), wird aber sicher auch bald verschwinden,
der Artikel erinnert mich an die lustigen Zeiten, in denen DAUs .doc für'n Standart hielten.