kein OpenOffice.org 2.0 in Aqua !

[Mauki]

Ich nehme aber an das es sich dabei, wie beim .key Format das Keynote verwendet, um XML handelt.

scheint kein XML zu sein, habe ich gehört ?

 

[Magicq99]

scheint kein XML zu sein, habe ich gehört ?

Ich weiss es nicht genau. Aber das Dateiformat das Keynote 1 verwendet ist XML.
Ich nehme an das Keynote 2 das gleiche, bzw. ein erweitertes Format verwendet und das Pages darauf aufbaut.

Aber das ist auch nur eine Vermutung, es macht aber Sinn. Wieso sollte Apple für Keynote ein XML Format verwenden und für Pages nicht? Das sind ja immerhin 2 Dateiformate die Apple in den letzten Jahren entworfen hat, die werden an beide sicher auf die gleiche Art und Weise heran gegangen sein.

 

[RETRAX]

@Magic99

also ich kann hier ein iWork Pages Dokument als auch ein iWork Keynote Dokument weder mit SubEthaEdit noch mit TextEdit öffnen. Von daher gehe ich davon aus dass es kein XML Derivat ist.


Gruss

Retrax

 

[HAL]

also ich kann hier ein iWork Pages Dokument als auch ein iWork Keynote
Dokument weder mit SubEthaEdit noch mit TextEdit öffnen. Von daher gehe
ich davon aus dass es kein XML Derivat ist.

tja, soweit zu den offenen standards auf die apple angeblich setzen wollte.

 

[Magicq99]

@Magic99

also ich kann hier ein iWork Pages Dokument als auch ein iWork Keynote Dokument weder mit SubEthaEdit noch mit TextEdit öffnen. Von daher gehe ich davon aus dass es kein XML Derivat ist.


Gruss

Retrax

http://www.xml.com/pub/a/2004/01/07/keynote.html
Also die Keynote 1 Dokumente sind, ähnlich wie Programme, Ordner. Das heißt Du lässt Dir im Finder die Inhalte der .key Datei anzeigen.

Darin befinden sich dann die ganzen Bilder und sonstige Daten, aber eben auch ein XML file (mit der Endung apxl) das sich öffnen lässt.

Probier das mal aus.

 

[RETRAX]

@Magic99

ok so passt es.

Mit Paketinhalt anzeigen bekomme ich einen Folder "Contents", "thumbs" und ein index.apxl.gz File. Wenn ich das entpacke erhalte ich ein index.apxl welches ich dann mit einem TextEdito öffnen kann. Da ist dann die XML Doctype in der ersten Zeile enthalten:

<?xml version="1.0"?>
<key:presentation xmlns:sfa="http://developer.apple.com/namespaces/sfa" xmlns:sf="http://developer.apple.com/namespaces/sf" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:key="http://developer.apple.com/namespaces/keynote2" sfa:ID="BGShow-0" key:play-mode="interactive" key:kiosk-slide-delay="5" key:kiosk-build-delay="2" key:mode="once" key:version="2004102100"><key:size sfa:w="800" sfa:h="600"/><key:theme-list sfa:ID="NSMutableArray-0"><key:theme sfa:ID="BGTheme-0" key:name="Theme" key:decimal-tab="."><key:size sfa:w="800" sfa:h="600"/><key:stylesheet sfa:ID="SFSStylesheet-0"><sf:styles><sf:table-

und in einem Pages Dokument:

<?xml version="1.0"?>
<sl:document xmlns:sfa="http://developer.apple.com/namespaces/sfa" xmlns:sf="http://developer.apple.com/namespaces/sf" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sl="http://developer.apple.com/namespaces/sl" sfa:ID="SLPublicationModel-0" sl:version="2004093000" sl:generator="slingshot" sl:app_build_date="Dec 21 2004, 16:41:21"><sl:version-history><sl:number sfa:number="2004042200" sfa:type="i"/><sl:number sfa:number="2004060800" sfa:type="i"/><sl:number sfa:number="2004061600" sfa:type="i"/><sl:number sfa:number="2004062200" sfa:type="i"/><sl:number sfa:number="2004062900" sfa:type="i"/><sl:number sfa:number="2004072200" sfa:type="i"/><sl:number sfa:

Gruss

Retrax

 

[Magicq99]

Na also,
es hätte mich auch stark gewundert wenn Apple dies geändert hätte.

 

[RETRAX]

Na also,
es hätte mich auch stark gewundert wenn Apple dies geändert hätte.

bedeutet das jetzt, daß es sich hierbei um ein offenes Format handelt, welches jeder andere Hersteller native in seinem Programm unterstützen könnte, so daß man einen nativen Im/Export hätte?


Gruss

Retrax

 

[HAL]

Na also,
es hätte mich auch stark gewundert wenn Apple dies geändert hätte.

*wheeew* mich allerdings auch.

 

[Mauki]

bedeutet das jetzt, daß es sich hierbei um ein offenes Format handelt, welches jeder andere Hersteller native in seinem Programm unterstützen könnte, so daß man einen nativen Im/Export hätte?

das glaube ich nicht, das andere Programm mit dem Format was anfangen können. Word und NeoOffice können mit der XML Datei nichts anfangen, sie zeigen nur den XML-Code an.

 

[deichkind]

Ist ja wohl klar das ältere Programme nich direkt das Format eines ganz neuen öffnen können, wenns auch noch von nem anderen Hersteller ist.
Durch die verwengung von XML-konformen dateiformaten sollten aber import/export filter deutlich leichter zu schreiben sein als für z.B. die MS Office Dateiformate.

 

[pdr2002]

Was hebt Ihr eigentlich alle auf dieses blöde XML-Format ab? Nur weil es ein offner Standard ist Na toll! Euch ist schon bewußt das XML als Nachfolger von html entwickelt wurde um dynamische Textseiten darzustellen? Euch ist auch klar das html, eben weil es ein offener Standard ist und von jeden nach eigenem ermessen geändert werden kann. Nun sagt nicht, das man das nicht tun sollte, aber es wird ständig gemacht, oder glaubt ihr die ganzen Internet-Browser hätten sonst solche Schwierigkeiten habe alle Internetseiten korrekt darzustellen.
XML ist für auomatiesierungszwcke ganz nützlich, aber in einer Textverareitung hat dies meines erachtens nichts als Standardformat zu suchen. Davon abgesehen gibt es hier bereits einen funktiuonierenden Standard, mämlich RTF. Heutige Textverarbeitungssysteme sollten sich aber lieber an PDF halten. Dieses Format ist perfekt für jedes Medium, egal ob Papier, Internet, oder auch für die Archivierung geeignet, ist ebenfalls für Entwickler offen, d.h. Der Entwickler kann es als Format für sein Produkt benutzen, es sind keine geheimen Sachen enthalten wie das .doc Format und man kann sich darauf verlassen daß es nicht von jedem xbeliebig geändert wird. Weiterverarbeitung sollte auch eigentlich kein Problem sein, selbst ein so "billiges" Tool wie die Vorschau von OSX kann den Text eines PDF extrahieren, wenn es vom Autor erlaubt ist. Also sollte es für heutige Textverarbeitungen auch kein Problem darstellen, PDFs bearbeiten zu können.

 

[Mauki]

Also sollte es für heutige Textverarbeitungen auch kein Problem darstellen, PDFs bearbeiten zu können.

ne Textverarbeitung die PDFs bearbeiten kann wäre schon genial. Speichern kann ja jeder, aber ein PDF öffnen und dann noch bearbeiten. Das wäre eigentlich das ideale Format.

Dafür würde ich auch auf XML und OASIS verzichten.

 

[Magicq99]

bedeutet das jetzt, daß es sich hierbei um ein offenes Format handelt, welches jeder andere Hersteller native in seinem Programm unterstützen könnte, so daß man einen nativen Im/Export hätte?

Das bedeutet erstmal das die Struktur der Dokumente sich nach dem XML Standard richtet. Dadurch fällt es Drittanbietern leichter Im/Export Filter für ihre Anwendungen zu schreiben.

XML kann man sehr wohl für so etwas verwenden. Es ist auch dafür gedacht:

The Extensible Markup Language (XML) is a W3C recommendation for creating special-purpose markup languages. It is a simplified subset of SGML, capable of describing many different kinds of data. Its primary purpose is to facilitate the sharing of structured text and information across the Internet. Languages based on XML (for example, RDF, RSS, MathML, XSIL and SVG) are themselves described in a formal way, allowing programs to modify and validate documents in these languages without prior knowledge of their form.

Es beschränkt sich damit nicht nur auf Webseiten oder andere Online Inhalte:

XML is also heavily used as the format for document storage and processing, both online and offline

http://en.wikipedia.org/wiki/Xml

Ich verstehe nicht wieso man XML nicht für so etwas verwenden sollte.

 

[der grimm]

XML ist ja eben gerade für soetwas geeignet. Und mit HTML kann man XML so direkt überhaupt nicht vergleichen, da HTML doch viel mehr schon eine Ausprägung für einen bestimmten Verwendungszweck ist - und das ist XML nicht. XML ist einfach dazu da, "strukturiert" Daten zu speichern.
Es geht damit einfach viel besser als z.B. mit einem "wurschteligem" Binärformat, wie es MS Word verwendet, und mit dem Microsoft scheinbar selbst nicht richtig klar kommt. Das hat also ganz und gar nichts mit einem "Abheben" auf das XML-Format zu tun...

Heutige Textverarbeitungssysteme sollten sich aber lieber an PDF halten. Dieses Format ist perfekt für jedes Medium, egal ob Papier, Internet, oder auch für die Archivierung geeignet, ist ebenfalls für Entwickler offen, d.h. Der Entwickler kann es als Format für sein Produkt benutzen, es sind keine geheimen Sachen enthalten wie das .doc Format und man kann sich darauf verlassen daß es nicht von jedem xbeliebig geändert wird. Weiterverarbeitung sollte auch eigentlich kein Problem sein, selbst ein so "billiges" Tool wie die Vorschau von OSX kann den Text eines PDF extrahieren, wenn es vom Autor erlaubt ist. Also sollte es für heutige Textverarbeitungen auch kein Problem darstellen, PDFs bearbeiten zu können.

Wenn ich mich nicht irre, verfolgt PDF aber ein völlig anderes Ziel als das Dateiformat einer Textverarbeitung (oder auch einer Layoutanwendung etc.). PDF wäre für sowas gar nicht zu gebrauchen, da viele für eine Textverarbeitung benötigte Informationen in einem PDF nicht vorhanden sind. Es ist eben einfach für einen anderen Verwendungszweck erschaffen worden.. und somit für eine Textverarbeitung sinnlos (es müsste erweitert werden, um brauchbar zu sein).

XML ist da m.E. genau der richtige Weg. Und das Schreiben von Im-/Export-Filtern ist auch deutlich einfacher. Bei einem im XML-Format abgespeicherten Dokument kann man sich zumeist auch beim bloßen Anblick des Quelltextes des Dokumentes ein Bild dessen machen etc..

 

[Magicq99]

@Zeeke:
Danke, genau so sehe ich das auch.

 

[INTRU]

hmmmmm... apple könnte doch für eine native version sorgen...

aber wollen die wohl nicht (leider)

 

[Sym]

ne Textverarbeitung die PDFs bearbeiten kann wäre schon genial. Speichern kann ja jeder, aber ein PDF öffnen und dann noch bearbeiten. Das wäre eigentlich das ideale Format.

Dafür würde ich auch auf XML und OASIS verzichten.

Das wäre ein optimales Format, weil...

 

[Turm]

ne Textverarbeitung die PDFs bearbeiten kann wäre schon genial. Speichern kann ja jeder, aber ein PDF öffnen und dann noch bearbeiten. Das wäre eigentlich das ideale Format.

Dafür würde ich auch auf XML und OASIS verzichten.

PDF ist eigentlich eine Erweiterung von Postscript, und ehrr mit DVI Dateien zu vergleichen.

PDF ist ein vormat für die Druckvorstufe, nicht für eine Textverarbeitung.

Das ist so und meiner Meinung nach sollte es auch so bleiben. Denn es würden durch die Bearbeitung elementate Eigenschaften von PDF verloren gehen: Bei PFD ist das Layout konsistent, d.h. z.B. selbst wenn ich einen Text austausche (mit dem Acrobat geht das ja) bleibt mein übriges Layout unberührt, obwohl ich es ja eigentlich als Fließtext in meiner Textverarbeitung geschrieben habe.
Dadurch sind PDF Dokumente allerdings auch nur bedingt bearbeitbar, und i.d.R erstellt man ein PDF Dokument auch dazu, um ein Dokument nicht mehr bearbeiten zu lassen, oder als Formular höchstens ausfüllen zu lassen.

Zurück zum Thema Openoffice.
Für mich ist ein nicht Programmierbares Office kein richtiges Office. Vor allem bei einer Tabellenkalkulation ist es ganz entscheidend, mal einfach nen Dreizeiler für eine Berechnung zu Programmieren. Solange das Openoffice nicht hinreichend beherrscht, sehe ich keine Alternative zu Ms-Office, ob das nun native oder in-a-box läuft.

 

[Yarramalong]

Pages benutze ich seit drei Tagen und war bei einem etwas komplexeren Manuskript erfolgreich als in Word nach Jahren. Bei Word rutschen mir die Bilder über die Seitenkante, die Bildunterschriften wandern irgendwo anders hin etc. Bei Office X wurden eingesetzte Bilder nur am Seitenanfang geöffnet. Erst nach Monaten habe ich gelernt, wie man Bilder platziert. Souverän schaffe ich es immer noch nicht. Dabei kenne ich mich gut aus mit Quark, Framemaker, Ragtime & v.a.m.

Gegenüber Word ist Pages blitzschnell.

Warum man aber in Deutschland eine Textverarbeitung auf den Markt bringt, die keine Silbentrennung kann, werde ich nie verstehen.