Vielen Dank an alle, die Interesse an meinem Projekt bekundet haben. Da sich daraus jedoch leider kein stabiles Zusammenwirken entwickelt hat, habe ich mich nun dazu entschlossen, den Status des Projektes zu ändern.

Es bleibt weiter ein offenes, auch quelloffenes Projekt, nur suche ich nicht länger nach jemandem, der dabei mitwirken möchte. Und da es keinen Sinn macht, ein halbfertiges Projekt zum Download anzubieten, wenn man nicht jemanden sucht, der dabei mitwirken möchte, arbeite ich fürs erste heimlich an dem Projekt weiter. Herunterzuladen wird es dann also erst etwas geben, wenn dies einen "fertigen" Status erreicht hat.

Auch das Wiki, das ich auf der Projektseite angelegt hatte, ist auf Mitarbeit ausgerichtet. Es wird über kurz oder lang verschwinden. Allerdings überlege ich noch, eine Form zu finden, den Inhalt der Datenbank ins Netz zu stellen. Anders als beim bisherigen Wiki sollte dies jedoch in einer Form geschehen, die kein paralleles Arbeiten an der Datenbank des Projektes und am Wiki erfordert (vielleicht eine Lösung in PHP?). Ich habe allerdings keine Ahnung, wann ich dazu komme, das umzusetzen. Im Moment hat das eine eher geringe Priorität für mich.

Hallo DonStivino,

was das WYSIWIG angeht, so kann ein Text ja einfach in eine RichTextBox eingegeben werden. Für mein Projekt habe ich mithilfe des Pakets nrtftree einen Wrapper von RTF zu iTextSharp geschrieben. Solch ein Wrapper läßt sich sicherlich auch für eine LaTeX-Ausgabe erstellen. Allerdings erlaube ich nur eine äußerst begrenzte Funktionalität bei der Texteingabe zu nutzen. Einen umfassenden Wrapper von RTF ist sicherlich keine triviale Aufgabe. Da macht das RTF-Format allerdings deutlich mehr Schwierigkeiten als LaTeX. Aber möglich ist sowas schon.

Gruß

Gradivus

Das klingt wirklich vielversprechend.

Wenn Du schon eine Bachelor-Arbeit in LaTeX geschrieben hast, dann kennst Du ja den typischen Arbeitsprozeß:*Eine tex-Datei wird erstellt. *Sie wird kompiliert, was mehrere Durchgänge erfordert, da LaTeX erst einmal die Daten generieren muß, um die Feinheiten des Layouts zu erstellen. *Dann schaut man sich das Ergebnis an und sieht, daß trotz aller Einstellungen der Text strotzt vor lauter Schusterjungen und Hurenkindern und all dem, was ansonsten noch unschön sein kann. *Also paßt man den Text noch einmal von Hand an und beginnt den Prozeß von Neuem.

Wenn der Prozeß automatisiert ist, fällt der dritte Punkt unter Umständen weg, weil man auf den keinen Einfluß mehr hat. Ich bezweifle etwas, daß man Word-User an LaTeX heranführen kann. Entweder man mag es, einen Text im wahrsten Sinne des Wortes zu "programmieren", oder man will ihn einfach nur mit möglichst wenig Aufwand verfassen.

Wenn einfach nur die Grundfunktionen gefragt sind, die sind ja schnell erklärt:

Am Anfang der TeX-Datei werden die Pakete eingebunden und die Ränder werden gesetzt. Da steht dann auch schon die Entscheidung, ob das Dokument eine größere Struktur braucht: \documentclass[a4paper,twoside]{book} oder es sich eher um ein kleineres Dokument handelt: \documentclass[a4paper,twoside]{article}.

Beide Versionen unterscheiden sich vor allem dadurch, daß die 'book'-Variante '\part' und'\chapter' kennt, wohingegen es bei der 'article'-Variante erst mit 'section' losgeht.

Wenn einem allerdings nicht gefällt, wie LaTeX eine Kapitelüberschrift gestaltet, so wird man kaum drumherumkommen, sich auf die Ebene des Makropakets 'book' herabzubegeben. Denn so einfach läßt sich der entsprechende Befehl vom Dokument aus nicht ändern.

Das liegt daran, daß Leslie Lamport, der LaTeX Anfang der 1980er Jahre programmiert hat, einige Befehle von der Ebene des Anwenders abgekapselt hat. Das sind die Befehle mit einem @. Die lassen sich eigentlich nur in einem einzubindenden Paket (sty-File) verwenden.

Mir hat das nie gefallen, was Lamport als Kapitelüberschrift vorgesehen hat. War mir immer zu amerikanisch (andere Schriftsetzertradition). Also habe ich mir einfach eine eigene sty-Datei geschrieben. Ist recht einfach. Aber wie willst Du das mit einem Wrapper hinkriegen?

Also, ich denke, da mußt Du die Entscheidung treffen: Entweder Du bereitest einen Standard vor (letztlich eine Abart von LaTeX), und Leute, die das verwenden wollen, können sich auch nur exakt in diesem Rahmen bewegen. Dann hast Du tatsächlich sowas ähnliches wie HTML.

Oder Du willst dem Anwender die volle Freiheit geben. Dann wird der Umfang aber entsprechend zunehmen und es wird immer schwieriger werden.

Für mein Projekt habe ich mich für iTextSharp entschieden (und ich hasse das Teil). Wenn es ein halbwegs funktionsfähiges LaTeX-Modul gäbe, wäre ich sofort dabei (wenn es nichts kosten würde 😄).

Hallo DonStivino,

bei LaTeX handelt es sich um reine Testdateien. Insofern ist das einzige Modul, was Du zu deren Erstellung brauchst, der TextWriter.

Bei LaTeX handelt es sich um ein Macropaket, welches auf das Satzsystem TeX aufsetzt, das noch vor den Zeiten des Wysiwyg entwickelt wurde. Im Prinzip arbeitet es im Kern immer noch mit 7-Bit ASCII. Allerdings lassen sich mittlerweile Pakete einbinden, so daß auch 8-Bit Zeichensätze und vermutlich auch bereits Unicode verarbeitet werden können.

Grundprinzip LaTeXs ist, daß das Satzsystem anhand einiger Vorgaben das komplette Layout übernimmt. Insofern ist die Struktur im Prinzip recht übersichtlich. Es gibt einige Seiten, auf denen LaTeX erklärt wird (auf die Schnelle gefunden: hier oder hier).

So einfach LaTeX daherkommt, so mächtig ist es durch seine Erweiterbarkeit. Anders als bei HTML, bei denen die Markups letztlich beschränkt sind, können in LaTeX alle möglichen Pakete eingebunden werden (z. B. ein mächtiges Grafikpaket: TikZ).

Diese Erweiterbarkeit macht es andererseits kaum sinnvoll, einen Wrapper einzuschalten, um eine LaTeX-Datei zu erstellen. Bei all den Paketen, was soll der Wrapper alles berücksichtigen?

Und last but not least: Eine TeX-Installation braucht Platz, viel Platz. Ich persönlich benutze MikTeX. Laut deren Seite beinhaltet das in der aktuellen Version 2972 Pakete. Gerade wenn Du am Anfang nicht wirklich weißt, welche Du davon letztlich wirklich brauchst, empfiehlt sich eine Komplettinstallation. Bei mir belegt MikTeX 2,42 GB in 79.425 Dateien.

Ich persönlich nutze LaTeX seit Jahrzehnten gerne und es gehört mit zu den letzten Dingen, die ich von der Platte putzen würde. Aber wenn einfach nur ein PDF erstellt werden soll, ist es vielleicht doch leicht überdimensioniert. Vor allem, wenn das Programm nicht nur von einem selbst genutzt werden soll.

Gruß

Gradivus

Hallo zusammen,

weiß jemand zufällig, ob und wie es möglich ist, bei iTextSharp eine Tabelle mit Text umfließen zu lassen?

Bei Images wird das Alignment dazu einfach auf TEXTWRAP gesetzt. Leider steht bei Tabelen diese Option nicht zur Verfügung.

Ich habe bereits versucht, die Tabelle in eine temporäre PDF zu schreiben (memoryStream), die entsprechende Seite daraus wieder einzuladen und als Bild zu behandeln. Leider funktioniert das nur bis zu dem Zeitpunkt, da dann die zu erzeugende PDF geschlossen werden soll. Dann kommt die Fehlermeldung, auf eine geschlossene Datei könne nicht mehr zugegriffen werden. Die erzeugte PDF läßt sich nicht öffnen. Kann sein, es liegt daran, daß der entsprechende Memorystream dann bereits wieder freigegeben ist. Andererseits habe ich bereits Seiten eines anderen PDF auf diese Weise erfolgreich einbinden können. Insofern neige ich zu der Annahme, daß es doch an der Tabelle liegt.

Aber vielleicht gibt es ja noch einen anderen Weg?

Gruß

Gradivus

P.S.: Hat sich erledigt, da ich den Fehler selbst gefunden habe. Nun funktioniert das mit dem Einlesen der Tabelle als Bild aus dem Memorystream. Hatte bei der Weiterverarbeitung das falsche Writer-Objekt verwendet.

Hallo herbivore,

am Anfang gab es das noch nicht. Aber ich mußte bald feststellen, daß in verschiedenen Quellen unterschiedliche Angaben zu finden sind. Es ist also noch komplizierter, als daß es sich mit einem einfachen Flag lösen ließe.

Jeder Hauptdatensatz enthält ein RTF-Feld, in dem ein Gegenstand beschrieben werden kann. Des weiteren ist vorgesehen, in diesem Feld Verweise auf Quellen hineinzuschreiben (insofern es sich um Links handelt, ist es möglich, aus der Datenbank diesen direkt aufzurufen). Die Quellen werden nummeriert (durch eine vorangestellte Zahl in Eckigen Klammern, also z. B.: [1] http://www.mycsharp.de/wbb2/addreply.php?threadid=114503.

Jedem Datenfeld (etwa der Angabe des Kalibers einer Waffe) ist ein weiteres Feld (NumUpDown) zugeordnet, das allerdings nur Zahlen zwischen Null und Neun akzeptiert. Die Null steht dabei für keine Quelle, also eine reine Schätzung. Zahlen von 1-9 verweisen dann auf eine Quellenangabe im RTF-Feld.

Wenn also dann hinter der Kaliberangabe eine Eins steht, im RTF-Feld oben angegebene Quellenangabe (dieser Thread), dann ist davon auszugehen, daß die Angabe aus der angegebenen Quelle bezogen wurde.

Bedauerlicherweise ist das Internet ein sich veränderndes Medium. Deswegen kann und ist es schon vorgekommen, daß dann auf einmal eine Seite verschwunden ist, von der eine Angabe bezogen wurde. Wenn so etwas auffällt, kann es eventuell korrigiert werden, ansonsten führt der Link eben ins Leere.

Intern gibt es natürlich eine Rangliste von Quellen. Wenn es gelingt ein Originaldokument zu finden. Etwa beim (VW-Kübelwagen) konnte ich im Netz das englischsprache technische Handbuch (TM 9-803) finden. Dort steht dann zum Beispiel drin, welche Steigfähigkeit das Fahrzeug hatte (eine Angabe, nach der ich mir schier einen Wolf gesucht habe).

Die nächste Qualitätststufe für Quellen sind dann Fachpublikationen. Dem entsprechen in etwa Internetseiten, die sich speziell einem Thema widmen.

Weiter unten finden sich dann Angaben auf dem Niveau des Hörensagens. Dazu zählt dann, wenn in irgendeinem Forum bei irgendeiner Diskussion mal fallengelassen wird, wie teuer denn z. B. ein solcher VW-Kübelwagen in seiner Zeit war. Wenn keine anderen Quellen verfügbar sind, ist das immer noch besser als eine reine Schätzung.

Wobei auch Schätzungen auf einer sachlichen Grundlage getroffen werden können. Insofern es solche Grundlagen gibt, sind diese ebenfalls in dem RTF-Feld unter der Überschrift Schätzungsgrundlagen anzugeben.

Da es sich um Angaben für ein Spiel handelt, ist nun einmal leider Vollständigkeit gefordert. Wenn bei einem Fahrzeug partout nicht zu finden ist, welche Kletterfähigkeit es besessen hat, bleibt letztlich nichts anderes übrig, als das Pi mal Daumen einzuschätzen. Dabei halte ich es ebenfalls für geboten, daß festgehalten wird, wo und wie geschätzt wurde. Wann immer eine bessere Quelle auftaucht, können dann Angaben korrigiert werden.

Gruß

Gradivus

P.S.: Ich rede gerne über mein Projekt und auch gerne viel. Ein wenig frustrierend ist es aber schon, wenn Fragen gestellt werden, die sich eigentlich leicht beantworten ließen, falls dem oben angegebenen Link gefolgt würde. Ich habe extra ein Wiki angelegt, welches die Angaben der Datenbank im Netz spiegelt. Es ist also noch nicht einmal nötig, sich die Programme herunterzuladen und zu installieren.

Es gibt auch ein Handbuch. Mit dem aktuellen hinke ich hinterher, aber die November-Version beschreibt vieles noch immer zutreffend. Wenn dann immer noch Fragen offen sind, beantworte ich diese gerne.

Ja.

Fein. 😃

Eilt überhaupt nicht. Melde Dich dann einfach per PN, wenn es soweit ist.

P.S.: Im Wiki einfach die Länderkennung (ISO 3166-1, zweistellig) anhängen. In der Datenbank des Projektes bildet sie den ersten Bestandteil der Bezeichnung, damit die Dinge dann nach Ländern sortiert sind. Aber das sah im Wiki nicht so gut aus, fand ich.

Hallo Runshak,

ich habe dennoch das Gefühl, daß Du mich nicht richtig verstanden hast. Vielleicht könnte es Dir weiterhelfen, wenn Du einmal dem oben angebenen Link folgst. Wenn Du dort auf 'Informationen' klickst, kommst Du zu einem Wiki. Dort findet Du z. B., wo Du von Geschwindigkeiten gesprochen hast, Daten zu Fernwaffen. Ich würde vorschlagen, Du klickst dort (oder auch hier) auf Karabiner 98k (DE). Unter der Überschrift 'Ordnonnanzwaffe' findest Du einen Abschnitt zu 'Munition'. Dort sind Schießtafeln zur 8×57 sS, IS, SmK und SmkH zu finden.

Wenn die dort gefundenen Angaben in etwa Deinen Ansprüchen zu 'korrekten Daten' entsprechen, bist Du herzlich eingeladen, weitere Daten beizusteuern. Die sind jederzeit herzlich willkommen. 😃

Eine Anmeldung in dem Wiki ist wegen der Bots nicht einfach möglich. Falls Deinerseits ein Interesse besteht, schreibe mir hier doch einfach eine PN. Übrigens sind alle Daten aus dem Wiki auch im Projekt enthalten. Und die Schießtafeln wurden mit dem ballistischen Rechner des Projektes erstellt.

Gruß

Gradivus

So, wie das Projekt angelegt ist, ist die Grenze zwischen Entwickler und Benutzer zumindest fließend, wenn nicht gar stellenweise aufgehoben.

Wer vom Gradivus-Projekt so etwas wie ein Schachspiel erwartet, bei dem ihm möglichst selbst auch noch abgenommen wird, die Figuren aufzustellen, der wird vermutlich enttäuscht werden. Es geht gerade darum, kein fertiges Spiel vorzusetzen, sondern den Benutzer mit in den Prozeß und die Entscheidungen einzubinden, wie das Spiel gespielt werden soll. Dabei soll es immer möglich sein, auf das zurückzugreifen, was andere bereits geleistet haben, also welche Daten sie z. B. angelegt haben. Aber das schlimmste, was dem Projekt passieren könnte, wäre, das in dieser Hinsicht alle Arbeit getan ist.

Das Gradivus-Projekt soll kein Spiel für Konsumenten sein, sondern eine Spielwiese, in der jeder Benutzer zumindest ein Stück weit auch zum Entwickler wird, und wenn er auch nur so eine Entscheidung trifft, aus welcher Epoche denn nun Ausrüstungsgegenstände verwendet werden dürfen. Aber wie gesagt, das Schlimmste wäre, daß irgendwann alles vorliegt und es dann nichts mehr zu tüfteln gäbe.

Taktik ist ursprünglich die Kunst, ein Heer in Schlachtordnung aufzustellen. Kann es in dieser Hinsicht etwas Öderes geben, als wenn die Bauern immer vorne stehen und die Türme in der Ecke? 😉

Hallo Runshak,

vornehmlich geht es um die Zeit des II. Weltkriegs. Heutige Waffen interessieren mich persönlich nicht so sehr, weil sie einfach zu nah dran sind. Das soll aber nicht heißen, daß solche Waffen nicht in die Datenbank eingetragen werden dürfen. In vierlerlei Hinsicht ist es bei heutigen Waffen, Fahrzeugen etc. einfacher, an die Daten ranzukommen.

Auf der anderen Seite habe ich die Kategorien, in die Waffen einzuordnen sind, schon so angelegt, daß auch Dinge aus wesentlich früheren Zeiten eingegeben werden können (Bogen, Armbrust, Muskete, Flinte, Einzellader oder auch Bogengeschütz und Katapult sind alles Kategorien, denen Fernwaffen zugeordnet werden können, die zur Zeit des II. Weltkriegs aber keine wirkliche Rolle mehr spielten).

Generell soll im endgültigen Spiel möglichst viel vom Anwender festgelegt werden dürfen. So gibt es zwar eine Epoche der alle Ausrüstung angehören muß, aber um welche Zeit es sich dann konkret handelt, das kann jeder selbst bestimmen.

Es dürfte zwar jeweils eine Menge Arbeit machen, Einheiten für eine komplett andere Zeit zu erstellen, aber es geht gerade darum, dies möglich zu machen.

Gruß

Gradivus

Seit nunmehr über einem Jahr arbeite ich an meinem Projekt, das einmal ein Strategiespiel werden möchte. Damit habe ich es allerdings nicht besonders eilig. In erster Linie ist das Projekt als Spielwiese für die Entwicklung gedacht. Mir persönlich liegen insbesondere jene Kleinigkeiten am Herzen, die in der Regel bei anderen Strategiespielen unterhalb der notwendigen Abstraktionsebene verschwinden.

Innerhalb der bereits verstrichenen Zeit sind mehrere Programme entstanden, dessen gemeinsame Basis eine SQLite-Datenbank bildet.

Im ersten Programm können Daten zu Fortbewegungsmitteln, Waffen, Munition und Ausrüstungsgegenständen eingegeben werden. Hierbei soll historische Genauigkeit im Vordergrund stehen. Allerdings ist es größtenteils gar nicht so einfach, dabei an verläßliche Informationen zu kommen. Beschreibende Texte zu den einzelnen Gegenständen können in RTF-Eingabefeldern eingegeben werden. Es ist auch vorgesehen, zu möglichst allen Angaben Quellen zu nennen.

Um insbesondere die Daten über die Fernwaffen lebendig werden zu lassen, habe ich ein ballistisches Modul geschrieben und integriert, über das Schießtafeln ausgegeben werden können. Mit diesem Modul soll dann auch im Spiel die Wahrscheinlichkeit errechnet werden, mit der ein bestimmtes Ziel mit einer bestimmten Waffe getroffen werden kann.

Eine Ausgabe der Daten wird über iTextSharp in ein PDF realisiert. Die Ausgabe der RTF-Texte (inklusiver darin eingebetteter Bilder) ist mir mithilfe des Pakets nrtftree gelungen.

Dinge müssen bezahlt werden. Statt Preise willkürlich festzulegen, habe ich mich für die historischen Preise entschieden (was leider doch darauf hinausläuft, Preise oft willkürlich festlegen zu müssen, da es nicht so einfach ist, da überall Informationen zu finden). Um die verschiedenen Preise vergleichbar zu machen, habe ich mich für die Kaufkraft der seligen DM im Jahre 2000 entschieden (Millenniummark). Ein kleines Programm ist vorhanden, welches historische Preise anhand der Inflationsdaten in eben die Kaufkraft der DM im Jahre 2000 umrechnet.

In einem weiteren Programm wird festgelegt, welche der im ersten Programm definierten Gegenständen ein Soldat so mit sich trägt. Auch hierbei geht es ein Stück weit noch um historische Genauigkeit, aber hier ist schon möglich und vorgesehen, mit den Angaben zu spielen. Das heißt, jeder kann sich Soldaten so ausrüsten, wie er das gerne möchte.

Soldaten sind allerdings nicht die Einheiten, mit denen gespielt wird. Das geht mit Trupps los. Ein Trupp ist dabei als Funktionseinheit zu verstehen, die ausnahmsweise auch schon mal aus einem einzelnen Soldaten bestehen kann (ein Melder stellt z. B. eine Funktionseinheit dar, die selbstständig agiert, darum als Meldetrupp angesehen wird, auch wenn es sich nur um einen einzelnen Mann handelt).

Mit demselben Programm lassen sich Soldaten mit Fahrzeugen und schwereren Waffen zu Trupps zusammenfassen. Auch hier gilt wieder: Es kann historisch korrekt sein, es darf aber auch nach eigenem Gutdünken zusammengestellt werden.

Höhere Einheiten sind Trupps, denen andere Trupps unterstellt sind. Wenn ich z. B. einen Kompanieführungstrupp definiere, dem mehrere Trupps unterstehen, die Züge darstellen, und denen wiederum Gruppen unterstehen, die sich aus mehreren Trupps zusammensetzen, kann ich eine Kompanie darstellen. Auf dieser Ebene hört das aber keineswegs auf. Letztlich kann damit eine komplette Streitkraft dargestellt werden. Auch diese Struktur kann als PDF ausgegeben werden.

Damit eine derart aufgebaute Struktur funktionieren kann, ist es möglich, jedem einzelnen Trupp (was auf dieser Ebene noch kein tatsächlicher Trupp ist, sondern lediglich das Schema eines Trupps), ein Skript zuweisen.

Ich hätte liebend gerne zur Realisierung der KI (die allerdings noch weit davon entfernt ist, überhaupt begonnen zu werden), eine speziell dafür konzipierte Skriptsprache mit eingebunden, etwa SOAR oder CLIPS, aber wenn es davon überhaupt eine Version für .NET gibt, so ist diese höchst unzureichend dokumentiert, veraltet und höchstens teilweise lauffähig. Vielleicht ergibt sich in dieser Hinsicht noch was.

Bis dahin und auch, um Skripte an anderer Stelle einsetzen zu können, habe ich mich für IronPython als Skriptsprache entschieden. Für die Erstellung solcher Skripte habe ich einen eigenen kleinen Editor geschrieben, in dem die Skripte auch ausprobiert werden sollen (wenn denn einmal die entsprechenden Schnittstellen festgelegt worden sein sollten). Dank ScintillaNET gibt es wenigstens ein wenig Unterstützung bei der Skripteingabe. Skripte werden in der Datenbank gespeichert.

Schließlich lassen sich mit dem Programm auch noch taktische Symbole generieren. Dies geschieht als PDF, weshalb Ghostscript auf dem System vorhanden sein muß. Symbole können aus Elementen zusammengesetzt werden. Vor allem das NATO-System ist vorhanden, ich habe vor, allerdings auch noch andere taktische Symbolsysteme mit zu berücksichtigen.

Als nächstes steht bei mir das Programm zur Gestaltung des Spielfeldes auf dem Plan. Gespielt wird auf 10 mal 10 Metern großen Feldern (Ar). Diese sind zu je 100 zu einem Hektar zusammengefaßt. Ein Spielfeld hat eine Kantenlänge von mindestens 20 und höchstens 80 km. Es geht also um mindestens 40.000, maximal 640.000 Hektar. Jedes Spielfeld wird als eigene SQLite Datenbank angelegt. Momentan büffele ich OpenGL, um eine 3D-Darstellung hinzubekommen.

Ja, die möglichst kurze Darstellung ist dann doch recht umfangreich geworden. Wer hofft, mit dem Projekt bald spielen zu können, den muß ich enttäuschen. Das wird vermutlich noch Jahre dauern.

Zur Zeit arbeite ich allein an dem Projekt. Das ist ok, muß aber keineswegs zu bleiben. Jeder, dem das oben Dargelegte Appettit gemacht hat, ist herzlich eingeladen, in das Projekt einzusteigen. Es handelt sich wirklich um ein sehr vielfältiges Projekt. Es sind Daten zu recherchieren und einzugeben, Programme zu schreiben, Uniformteile und Abbildungen zu erstellen, irgendwann Spielfelder zu gestalten, Skripte für die KI auszubaldowern usw.

Auf jeden Fall handelt es sich um ein quelloffenes Projekt. Was bisher geschrieben ist, steht sowohl als Programm (unter .NET 4.0, Ghostscript muß installiert sein) als auch als Quellkode zur Verfügung.

Mit der Pflege des Handbuchs hinke ich immer etwas hinterher. Das Datenformat ändert sich auch immer noch mal. Für die Datensicherung und auch zur Ausgabe des Datenbankinhalts als PDF steht ein spezielles Programm zur Verfügung.

Ach ja das ganze Projekt ist übrigens unter der Adresse www.gradivus.de zu finden.