doc: Fix typos

1 files changed, 41 insertions, 42 deletions

diff --git a/projekt_doku.asciidoc b/projekt_doku.asciidoc
index 1d28387..8a6757b 100644
--- a/projekt_doku.asciidoc
+++ b/projekt_doku.asciidoc
@@ -9,55 +9,54 @@ Philips TV-Remote unter Linux
 == Aufgabe
 Ziel dieses Forschungsprojektes ist die Programmtechnische Umsetzung
 der Nutzung der Philips TV-Firmware als Netzwerkbasierter-Infoscreen.
-Als Platform ist dabei GNU/Linux zu verwenden und Lösungsmöglichkeiten für
-die Probleme der aktuellen Konfiguration mit dem Windows Client Pluggit
-sind zu evaluieren.
+Als Plattform wird dabei GNU/Linux verwendet.
+Es werden im weiteren Lösungsmöglichkeiten für die Probleme der aktuellen
+Konfiguration mit dem Windows Client Pluggit evaluiert.
 
 == Grundlagen
 
 *DirectFB*
 
-'DirectFB' ist eine kleine Bibliothek, die als Hauptaufgabe
-Beschleunigung durch Grafik-Hardware bereitstellt. 
+'DirectFB' ist eine Bibliothek, die als Hauptaufgabe Beschleunigung durch
+Grafik-Hardware bereitstellt. 
 Außerdem werden auch Eingabegeräte unterstützt, und es enthält ein
 integriertes Fenster-System.
-Dementsprechend kann DirectFB als Hardware-Abstraktions-Schicht bezeichnet
-werden.
+Auf Grund der genannten Eigenschaften kann DirectFB als
+Hardwareabstraktionsschicht bezeichnet werden.
 
 *DirectFB Voodoo*
 
 'DirectFB Voodoo' ist ein Aufsatz bzw Proxy-Kanal für DirectFB.
 Es besteht aus einer Client-Server Architektur.
 Der Server ist dabei das Anzeige Gerät und bietet über den Voodoo Kanal
-zugriff auf den eigenen Framebuffer.
+Zugriff auf den eigenen Framebuffer.
 
-Die Client-seitige Implementierung leitet 'DirectFB'-API-Aufrufe per 
+Die clientseitige Implementierung leitet 'DirectFB'-API-Aufrufe per 
 'DirectFB-Voodoo' an den Server weiter, auf dem diese dann ausgeführt werden.
 
 'DirectFB-Voodoo' ist demzufolge eine Remote-Rendering Infrastruktur
 die das Zeichnen von Primitiven wie Rechtecken und Kreisen ermöglicht,
 aber auch das übertragen von ganzen Bildinhalten.
 
-*JointSpace*
-
+*JointSpace* 
 'JointSpace' ist ein Framework und API für Fernseher von Philips.
 Es ermöglicht das Fernseher über das API gesteuert werden können,
-und eine Bildübertragung über das Netzwerk.
-Das API zur Steuerung der Fernseher basiert auf einem REST-full
+und eine Bildübertragung per Netzwerkverbindung.
+Das API zur Steuerung der Fernseher basiert auf einem REST-Full
 HTTP-Protokoll.
 Für die Bildübertragung wird 'DirectFB Voodoo' eingesetzt.
 
 == Ist-Zustand
 
-Verwendet werden Fernseherer der 7000er Serie von Philips, auf die eine,
+Verwendet werden Fernseher der 7000er Serie von Philips, auf die eine,
 direkt vom Hersteller erweiterte Firmware geladen wird. Diese beinhaltet die
-'JointSpace' erweiterung.
+'JointSpace' Erweiterung.
 
 Als Datenquelle dient eine Windows-Installation in einer virtuellen Maschinen,
 welche das ebenfalls vom 'JointSpace' bereitgestellte Programm 'Pluggit'
 verwendet.
 
-Die einzelnen Fernseher sind alle in eigenen Netzen, da zum Verbindungaufbau
+Die einzelnen Fernseher sind alle in eigenen Netzen, da zum Verbindungsaufbau
 ein Netzwerk-Broadcast genutzt wird und sich so die Fernseher gegenseitig
 stören würden, wenn in einem Netzwerk enthalten.
 
@@ -65,8 +64,8 @@ Der Firefox-Browser wird für die Darstellung im Vollbildmodus eingesetzt, da
 er unter Windows einer der stabilsten und ausgetestetsten, standardkonformer
 Browser ist.
 
-Die Fernseher bieten eine native Auflösung von 1920x1080 Pixeln,
-die Remote-Anzeige funktioniert aber nur bis zur Auflösung von 1280x720
+Die Fernseher bieten eine native Auflösung von +1920x1080+ Pixeln,
+die Remote-Anzeige funktioniert aber nur bis zur Auflösung von +1280x720+
 Pixeln.
 
 == Problemlösung & Implementation
@@ -95,17 +94,17 @@ Interface 'Source' implementiert.
 
 ==== Verbindungsaufbau
 
-Die DirectFB-Voodoo Platform nutzt als Standardmethode zum Verbindungsaufbau
+Die DirectFB-Voodoo Plattform nutzt als Standardmethode zum Verbindungsaufbau
 einen Broadcast Request, um verfügbare Anzeigegeräte zu finden.
 Dies ist für den Einsatz im Heimnetzwerk gedacht, bei dem der
 Verbindungsaufwand möglichst gering gehalten werden soll.
-Sind meherere der Fernseher in einem Netzwerk, so ist nicht eindeutig
+Sind mehrere der Fernseher in einem Netzwerk, so ist nicht eindeutig
 definiert, welcher zuerst auf den Broadcast antwortet, und dadurch für die
 Verbindung ausgewählt werden wird. 
 Aus diesem Grund ist eine sofortige Unicast-Verbindung nötig.
 
-Die Bibliothek bietet kein direktes API, um die Ziel-Addresse zu verabeiten.
-Die Initialisierungsmethode +DirectFB::Init()+ erwartet einen Argumentzähler
+Die Bibliothek bietet kein direktes API, um die Ziel-Addresse zu verarbeiten.
+Die Initialisierungsmethode +DirectFB::Init()+ erwartet einen Argumentenzähler
 und -vektor. Dieser Vektor bezieht sich auf die Kommandozeilen Argumente,
 im folgenden beispielhaft dargestellt:
 
@@ -126,8 +125,9 @@ Bricht die Verbindung ab -- z.B. durch Ausschalten des Fernsehers oder durch
 Auswählen einer anderen Quelle -- wird dies durch die DirectFB Bibliothek
 nicht an die Anwendung signalisiert.
 
-Im produktiven Einsatz ist es bei Remote-Steuerung deshalb nicht zu erkennen, ob die Verbidnung
-besteht. Im weiteren ist auch keine automatisierte Neuverbingung unmöglich.
+Im produktiven Einsatz ist es bei Remote-Steuerung deshalb nicht zu erkennen,
+ob die Verbindung besteht. Im weiteren ist auch keine automatisierte
+Neuverbindung unmöglich.
 
 //die Anwendung signalisiert.
 //Intern wird der Rückgabewert von +send(2)+ nicht auf einen Verbindungsabbruch
@@ -135,47 +135,46 @@ besteht. Im weiteren ist auch keine automatisierte Neuverbingung unmöglich.
 
 *Lösung:*
 
-Die Bibiliothek DirectFB wurde erweitert, das SIGPIPE signal vom Kernel zu
+Die Bibliothek DirectFB wurde erweitert, das SIGPIPE Signal vom Kernel zu
 empfangen. Pluggit installiert für DirectFB eine Signal Behandlungsroutine
 und bricht die Programmausführung ab.
-Ein Shell scripts das pluggit überwacht erkennt dies am Rückgabe-Status des
+Ein Shell-Script das 'Pluggit' überwacht, erkennt dies am Rückgabe-Status des
 Pluggit-Prozesses und startet diesen neu.
 
 //== Webbrowser-Rendering
 
 === Framebuffer Größenlimit
 Bei der Verwendung von 'Pluggit' unter Windows besteht das Problem, dass eine
-Maxmimale Auflösung von +1280x720+ Pixeln genutzt werden kann.
+maximale Auflösung von +1280x720+ Pixeln genutzt werden kann.
 Dieses Limit ist kein Fehler im Programm oder eine Einschränkung des
-Betriebsssystems, sondern das API erlaubt keine größe Auflösung.
-Bei Verwendung von z.b. einer +1920x1080+ Auflösung -- bei einem Fernseher,
+Betriebssystems, sondern das API erlaubt keine größere Auflösung.
+Bei Verwendung von z.B. einer +1920x1080+ Auflösung -- bei einem Fernseher,
 der diese Auflösung per HDMI unterstützt -- signalisiert das API
 einen Fehler, dass ein invalides Argument übergeben wurde.
 
 
 === Framebuffer Auslesen
 Das X11-Protokoll bietet die Möglichkeit den angezeigten Framebuffer
-über die Funtkion +XGetSubImage(3)+ auszulesen.
+über die Funktion +XGetSubImage(3)+ auszulesen.
 
 Darüber hinaus gibt es eine Anbindung an +shmget(2)+, sodass Unix
 Shared-Memory verwendet werden kann.
 Dies bietet den Vorteil, dass die Framebuffer-Daten nicht über den
 X11-Protokoll-Socket übertragen werden müssen, sondern direkt gelesen werden
 können.
-Es wird ein X11-Pixmap erzeugt, welchem ein auf XImage auf Shared-Memory Basis zu
-grunde liegt.
+Es wird ein X11-Pixmap erzeugt, welchem ein auf XImage auf Shared-Memory Basis
+zugrunde liegt.
 Zum Auslesen wird nun +XCopyArea(3)+ mit dem X11-Pixmap als Argument
 aufgerufen. Der X-Server schreibt in der Folge den angefragten Bildinhalt
 in den Shared-Memory, 
 
 
-
 === Multi-Client
 
 Teil der Anforderung ist, mehrere Fernseher gleichzeitig mit unterschiedlichen
 Bildern zu beliefern.
 
-Um mehrere Fenster darzustellen, wird ein großer Anzeigebreich benötigt.
+Um mehrere Fenster darzustellen, wird ein großer Anzeigebereich benötigt.
 Mit 'XRandR' wird dies durch folgenden Aufruf erreicht:
 
 [source,sh]
@@ -198,12 +197,12 @@ Firefox-Browser.
 Dieser kann nur im Vollbild-Modus so konfiguriert werden, dass nur der Inhalt
 im X11-Fenster -- welches ausgelesen werden soll -- angezeigt wird, Menus und
 Scrollbars sind im normalen Floating-Modus immer vorhanden.
-Ein weiteres Problem stellt die eindeutige Addressierung der Window-ID, bei
-Verwänderung mehrerer Firefox-Fenster.
-Es gibt keine direkte Möglichkeit die Window-ID zu erhalten, nur über Matching
+Ein weiteres Problem stellt die eindeutige Adressierung der WindowID, bei
+Veränderung mehrerer Firefox-Fenster.
+Es gibt keine direkte Möglichkeit die WindowID zu erhalten, nur über Matching
 des Titels des Firefox-Fensters.
 Die Verwendung für mehrere Infoscreens würde es nötig machen den Titel des
-Angezeiten Inhalts zu wissen, und in der Programmlogik zu berücksichtigen.
+angezeigten Inhalts zu wissen, und in der Programmlogik zu berücksichtigen.
 Eine Veränderung des Inhalts würde damit auch eine Anpassung des Programms
 erfordern.
 
@@ -212,11 +211,11 @@ Website im X11-Fenster darzustellen.
 Der Browser 'Surf' footnote:[http://surf.suckless.org] von 'suckless.org' ist
 mit dem Prinzip erstellt worden, in andere Programme über das X11-XEmbed
 Protokoll eingebettet zu werden, z.b. um mehrere Instanzen in einem
-Tab-Manager zu embedden.
+Tab-Manager zu einzubetten.
 
 Dies ermöglicht per Design zwei Vorteile:
 
- - Die Window-ID wird auf +stdout+ ausgegeben. +
+ - Die WindowID wird auf +stdout+ ausgegeben. +
    (Kann demzufolge als Parameter an Pluggit übergeben werden.)
  - Keine Bedienelemente vorhanden, denn der Browser wird über X11-Properties
    gesteuert -- das erlaubt Scripting.
@@ -287,8 +286,8 @@ wenn directfb verändert wird.
 benötigten Stellen.
 
 
-Für die Übersetzung von DirectFB und Pluggit muss also nur folgender Befehl im
-Quellverzeichnis des Projekts ausgeführt werden:
+Für die Übersetzung von DirectFB und Pluggit muss also außschließlich
+folgender Befehl im Quellverzeichnis des Projekts ausgeführt werden:
 
 [source,sh]
 ------------