freiesMagazin 04/2011 erschienen

freiesMagazin 04/2011 Titelseite

Heute ist die Aprilausgabe von freiesMagazin erschienen und bringt viele spannende Artikel aus den Bereichen Linux und Open Source mit.

Inhalt der Ausgabe 04/2011

  • Debian GNU/Linux 6.0 „Squeeze“
  • Test: OpenDocument-Format für den Datenaustausch
  • Der März im Kernelrückblick
  • Eine Einführung in die Programmiersprache Pike
  • SpaceChem – Atome im Weltall
  • Rezension: Durchstarten mit HTML5
  • Rezension: Essential SQLAlchemy
  • Veranstaltungskalender

Downloads

Unter der Adresse http://freiesmagazin.de/mobil/ finden Sie immer die aktuelle und alle bisher erschienenen Mobil-Ausgaben. Über den Tab Magazin können die letzten drei Ausgaben von freiesMagazin abgerufen werden, ältere Ausgaben finden Sie in unserem Archiv.

Kontakt

Wer jeden Monat an die neue Ausgabe erinnert werden will, kann auch den RSS-Feed abonnieren. Leserbriefe mit Lob, Kritik, Anregungen oder Fragen und neue Artikelvorschläge können an die Redaktion geschickt werden.

Pingback

[...] ist die Aprilausgabe von freiesMagazin erschienen und bringt viele spannende Artikel aus den Bereichen Linux und Open Source mit. Inhalt [...]

Pingback

[...] ist die Aprilausgabe von freiesMagazin erschienen und bringt wieder viele Artikel aus den Bereichen Linux und Open [...]

OpenDocument-Format im Test

Der Bericht öffnet einem die Augen und ist ernüchternd, was mir aber doch noch fehlt sind MS Office 07 und 10 (böses Word), denn die werden am meisten in Unternehmen und Privat genutzt. Da offiziell MS Office ab Version 2007 ODF unterstützt wäre das noch interessant. Das würde zumindest OpenOffice / LibreOffice für den Alltag in Unternehmen prüfen und man hätte den Test, der über den freien Software Tellerrand hinwegseht. Ich weiß, dass OpenOffice schon in Unternehmen und Behörden eingesetzt wird aber dennoch und Ich weiß was das Magazin sich zum Ziel gesetzt hat aber in der Praxis spielt meistens die proprietäre und die freie Software nebenher und sogar miteinander.

Re: OpenDocument-Format im Test

Ich hätte es gerne auch getestet, aber woher nehmen und nicht stehlen? Selbst an der Arbeit haben wir kein MS Office 2007 (sondern eine ältere Version), sodass ich nicht einmal in meiner Pause den Test dort hätte machen können.

Da die ODF-Dateien aber zum Download angeboten werden, kannst Du vielleicht zumindest den Test mit dem Öffnen der Dateien unter MS Office 2007 vornehmen und das Ergebnis hier mitteilen.

Dominik

Re: Re: OpenDocument-Format im Test

Ich habe die ODF Dateien mal kurz getestet und bin zum folgenden Ergebniss: Bloss das mit OpenOffice erstellte Dokument ist vertretbar, auch hier versagen die Exoten (MS wird es wahrscheinlich auch nur auf OOo Optimiert haben). Es werden Kopf und Fusszeile sowie die Tabelle werden übernommen als auch die Feldbefehle Datum, Seite und Anzahl Seiten. Optisch ist das Dokument absolut vertretbar.

OpenDocument-Format im Test

Das ist also der Grund, warum im professionellen Bereich nur PDF und eigenes XML/SGML zum Satz benutzt werden.

Pingback

[...] Verbesserungsvorschläge und Hinweise zu Artikeln per E-Mail an die Redaktion Redaktion oder als Kommentare. root's [...]

Programmiersprache Pike

Schon interessant, was es so alles gibt in den Weiten des WWW :-)

Ich bin neulich über die Sprache "Squirel" gestolpert, die einen ähnlichen Ansatz verfolgt. Sie wird im Spiel OpenTTD für die Erstellung von neuen KIs und anderen scriptbaren Dingen verwendet.

Ich persönlich tue mich damit jedoch schwer: Wenn jemand eine Scripting-API nutzen möchte, so will er sicherlich nicht unbedingt umlernen. Jedoch ist die Syntax doch wirklich nur ein relativ kleiner Aspekt einer Sprache. Die semantischen Möglichkeiten lernt man jedoch nicht von heut auf morgen, schon gar nicht die Idiome. Zudem kommt erschwerend hinzu, dass es imho genügend tolle Sprachen fürs Scripting gibt, die eine gewisse Popularität besitzen (Lua, JavaScript, für mächtigere (aber nicht sicher verteilbare) Sachen auch Python oder Ruby). Für die Hauptentwickler mag so ein Ansatz ja ok sein, wenn sie eh in C oder C++ fit sind. Ich persönlich denke mal, dass man mit einer solch unbekannten Scripting-Sprache keine neuen, externen Kontributoren gewinnen kann. Schließlich wollen potenzielle Interessenten nicht unbedingt für ein Projekt eine neue Sprache erlernen. Aber das muss ein Projekt natürlich selber entscheiden :-)

Ideal sind da natürlich Ansätze, wie sie das KDE Projekt bei ihrer Scripting-API SMOKE verfolgt.

Vielen Dank jedenfalls für den interessanten Artikel!

re: Programmiersprache Pike

Ich fürchte, du hast Recht.
Programmiersprachen können sicher noch so gut und fortschrittlich sein - nehmen wir z.B. Qore, was so auf den ersten Blick wie modernes Perl mit ein paar netten Extras aussieht. Scheint auch sehr sauber dokumentiert zu sein. Trotzdem kennt es fast keiner. Aber wenn ich mir so ansehe, wie eingegrenzt man z.B. auf manchen Smartphones ist, ist es doch recht nett, zumindest auf dem PC die Wahl der Werkzeuge zu haben.

Zu Smoke: Wenn ich den Overview-Teil richtig verstanden habe, ist Smoke so etwas ähnliches wie SWIG. Vielleicht ist es ganz gut so, dass KDE und Qt einen eigenen Binding-Generator haben, qmake etc ist ja schon sehr speziell.

Zu Smoke: Wenn ich den

Zu Smoke: Wenn ich den Overview-Teil richtig verstanden habe, ist Smoke so etwas ähnliches wie SWIG. Vielleicht ist es ganz gut so, dass KDE und Qt einen eigenen Binding-Generator haben, qmake etc ist ja schon sehr speziell.
Richtig. Besonders interessant ist aber, dass man eine Binding-Lib quasi out of the box generieren kann. Damit ist das Erstellen von Scripting APIs natürlich relativ einfach und schnell zu machen. Dort sehe ich den Vorteil gegenüber Swig.

Kross fand ich persönlich fast noch fortschrittlicher, da dort alles dynamisch abläuft, aber das führt wohl zu stark in die Dependecy-Hölle. Speziell auf anderen Plattformen als dem PC kommt man da wohl schnell ins Wanken.

Programmiersprache Pike

Ich persönlich denke mal, dass man mit einer solch unbekannten Scripting-Sprache keine neuen, externen Kontributoren gewinnen kann.

das is irgendwie eine argumentation im kreis. ohne externe kontributoren kann eine sprache kaum bekannter werden, es sei denn man hat ein marketing budget wie sun (java) oder mircosoft (c#). meisstens is es ein tolles programm das eine sprache bekannt macht (wie rails bei ruby). bei pike ist dieses tolle program roxen gewesen das leider zu sehr kommerzialisiert und zu wenig unter entwicklern verbreitet wurde.

bleibt also nur zu hoffen das doch noch mehr leute die vorteile von pike entdecken und sie einsetzen. wie zum beispiel opera für den opera-mini server:
http://www.himanshurockat.com/2010/04/opera-mini-server-must-know-where-...

gruss, eMBee.

OpenDocument-Format im Test

Ihre Argumentation lässt sich problemlos auf PDF adaptieren.
Man sagt, PDF sei standardisiert und sehe überall gleich aus. Sobald sich ein Programm findet, bei mindestens ein Pixel anders gefärbt ist, wäre die These widerlegt.
Und ich bin überzeugt davon, dass sich so ein Programm finden lässt, Fehler gibt es immer. Dass die Fehler in ODF grösser sind, liegt einzig am viel komplexeren Format.

Nun sind Sie folgender Aussage im Lead, die ja die Leitfrage darstellt, gar nicht weiter nachgegangen: "Sprich, das Problem wie bei Microsoft Office, dass ein Dokument (auch bei gleicher MS-Office-Version) auf jedem Rechner anders aussehen kann, gibt es angeblich nicht."

Wir sind uns einig, dass von den zahlreichen gesteten Office Suiten allein [Open|Libre]Office fähig ist, das ODF in vollem Umfang auszureizen. Um der These nachzugehen, müsste man somit nur verschiedene Versionen von OpenOffice betrachten. Was dabei herauskommt, weiss ich nicht, es wird aus dem Artikel auch nicht ersichtlich.

Re: OpenDocument-Format im Test

Die These, dass ein Dokumentenstandard - egal welcher - in verschiedenen Programmen nicht immer gleich aussieht, ist eigentlich keine These, sondern können wir beinahe als Fakt abtun. Es gibt natürlich auch Ausnahmen, aber nur selten beherrscht bei einem komplexen Format ein Lese- oder Schreibprogramm alle Funktionen.

Gleiches gilt natürlich auch für PDF, welches nicht immer überall gleich aussieht. Glücklicherweise hält sich das in Grenzen. Bei Yalm war es früher bei mir z.B. Standard, dass der PDF-Reader die falsche Schriftart oder -formatierung genommen hat. Siehe dazu auch Kein PDF/A. Aber wie Sie auch festgestellt haben, ist PDF etwas einfacher als ODF. Ich denke aber auch, dass es „besser“ standardisiert ist und schon länger existiert, weswegen die meisten PDF-Reader wenig Probleme haben.

Die Leitfrage war darüber hinaus ja nicht, ob die MS-Dokumente wirklich auf verschiedenen Rechnern immer anders aussehen (auf einem standardisierten Firmenrechner sehen sie in der Regel nämlich gleich aus), sondern ob es bei ODF wirklich überall gleich ausschaut, egal welches Programm ich nutze (was manch einer gerne als Argument pro ODF anbringt). Und da war das Resultat ja, dass das Dokument nicht zwingend gleich ausschauen muss.

Ob es da noch Unterschiede macht, dass das ODF in OpenOffice.org 2.0 ggf. anders aussieht als in OOo 2.3, denke ich, kann man vernachlässigen, da man nur wenig Mehrwert erhalten würde. Sähe es gleich aus, wäre es gut und dennoch gäbe es genügend andere Programme, die es nicht gleich darstellen. Und gäbe es Unterschiede zwischen der Darstellung beider Versionen, wäre das nur ein weiteres Programm, was beim Test „durchgefallen ist”.

Also sicherheitshalber, falls es nicht klar im Artikel herausgekommen ist: Es sollte getestet werden, ob ein ODF-Dokument, welches in Programm A erstellt wurde beim Öffnen mit Programm B identisch (oder zumindest ähnlich) aussieht oder nicht.

PS: Zur Aussage des Ausreizens bin ich nicht ganz sicher. Der Funktionsumfang von der SoftMaker-Suite sieht wirklich nicht schlecht aus und kann u.U. OpenOffice.org das Wasser reichen. (Das habe ich aber nicht getestet.)

Pingback

[...] next category is office. Here are some PDF from different journals and office files from LibreOffice and Microsoft’s Office (special thanks to @chschmelzer for providing MS files). The complete [...]

OpenDocument-Format im Test

Hi,

ist die Autoreninfo zu diesem Artikel korrekt?

"Dominik ist zwar Verfechter freier Software..."

Verfechter?

Falls das stimmt passt IMHO der Teil danach nicht "...findet aber auch...".

Gruß, Jochen

Re: OpenDocument-Format im Test

Inwiefern? Du weißt ja, es ist wie in der Schule: Immer eine Begründung mit abliefern. ;)

Wenn Du Dich am Wort „Verfechter“ störst, setze eine Begriff ein, der umschreibt, dass ich Freie Software sowohl finanziell als auch von der Ideologie unterstütze und versuche Werbung dafür zu machen. Dabei versuche ich auch die Vorteile gegenüber proprietärer Software aufzuzeigen und darzustellen.

Hallo, entweder bin ich zu

Hallo,

entweder bin ich zu blöd, dass richtig zu verstehen... oder es stimmt wirklich nicht.

Wenn man "Verfechter" durch" Befürworter" ersetzt (also das Gegenteil), dann macht der Satz in sich IMHO erst Sinn...

Gruß, Jochen

Re: Hallo, entweder bin ich zu

Jetzt verunsicherst Du mich auch. Ich habe eben nachgeschaut und im Wahrig steht bei „verfechten“: „für etwas eintreten“. Ist also noch etwas stärker als Befürworter, da ein Befürworter etwas gut heißt, ein Verfechter aber auch gegen „Angriffe“ eine Sache vertritt.

OpenDocument-Format im Test

Danke für diesen aufschlussreichen Artikel!

Inhalt abgleichen