Es funktioniert zwar immer mit ps-Grafiken, aber nicht immer mit eps-Grafiken.

Die Seitengröße ist zwar bei der Auswahl von eps deaktiviert, muss aber trotzdem auf einem Wert wie ISO A4 stehen, nicht auf so großen Formaten wie ISO A0.

Man beginne alle Pfade relativ zum Home-Verzeichnis des aktuellen Benutzers, d.h. mit einem Datei- oder Verzeichnisnamen in diesem Home-Verzeichnis. Das führt dazu, dass die in der Datei eingebundenen Bilder angezeigt werden können. Beim Export muss man dann allerdings so exportieren, dass »Current Dir« auf diesem Homeverzeichnis steht, denn darauf beziehen sich ja die Pfade. Auch beim Öffnen muss aufgrund eines Fehlers »Current Dir« das Homeverzeichnis sein; man gibt es einfach in das Editfeld ein, nachdem man vorher ins Verzeichnis der fig-Datei gewechselt hat. Es hat wohl aufgrund eines Fehlers in xfig nichts mit dem Verzeichnis zu tun, in das die Datei exportiert wird; dieses ist nämlich immer das, dessen Inhalt im Exportfenster angezeigt wird.

find wird aufgerufen, wenn cron das Skript /etc/cron.daily/aaa_base_updatedb startet, um die locate-Datenbank zu erneuern. Woran find scheitert, kann man an der letzten Ausgabe eines find / -print sehen. In einem Fall war es ein defektes Dateiobjekt in einem Verzeichnis, dessen Name aus wilden Sonderzeichen bestand und dessen Informationen über Größe usw. auch von ls in diesem Verzeichnis nicht angezeigt werden konnten. Wenn versucht wurde, mit konqueror diese Datei zu löschen, verbrauchte kdeinit den gesamten Hauptspeicher beim Versuch, die Informationen dieser Datei aufzulisten. Da nicht bekannt ist, wie solche defekten Dateiobjekte gelöscht werden können, ist es die einfachste Lösung, alle sonstigen Dateien aus dem Verzeichnis mit der defekten Datei zu entfernen und dieses Verzeichnis in /usr/bin/updatedb zur Variable $PRUNEPATHS hinzuzufügen, damit find hier kein Verzeichnislisting versucht. Indem man nur noch root erlaubt, das Verzeichnis mit der defekten Datei zu lesen, können andere Benutzer keine Abstürze mehr verursachen, indem sie dieses Verzeichnis ansehen wollen.

Bei Ausdruck über gs wird der Inhalt der gesamten Seite immer (wie kann man das vermeiden?) um 2,5mm nach rechts verschoben, egal wie die Seite in der Druckvorschau aussah. (Gilt dies nur für den Drucker EPSON EPL-7100 oder auch für andere?). Dadurch entsteht zwischen Vorder- und Rückseite ein Unterschied von 5mm. Wenn dies stört, so verschiebt man in der Quelldatei den Inhalt der Vorder- oder (!) der Rückseite um 5mm nach links.

Angegeben wird die Verschiebung gegenüber der ursprünglichen Position nach oben (pos. Y-Offset), unten (neg. Y-Offset), rechts (pos. X-Offset) oder links (neg. X-Offset). Die ursprüngliche Position ist »Centered« (Grafik auf der Seite vertikal und horizontal zentrieren) oder »Flush Left« (Grafik beginnen in dem Punkt, der 10mm vertikal und 10mm horizontal von der linken oberen Ecke des Papiers entfernt ist).

In xfig besteht ein Bug, aufgrund dessen beim direkten Export als PDF immer nur 2 Bilder mit exportiert werden. Acrobat meldet dann den Fehler »read less image data than expected«. Sowohl beim Export in PDF als auch EPS wird die Seite nur so groß wie die Grafik selbst, egal was für eine Papiergröße eingestellt wird.
Man exportiert daher als ps und wandelt dann mit ps2pdf in eine PDF-Datei um. Diese hat dann die eingestellte Seitengröße, außerdem tritt der Darstellungsfehler »rosa Unterlegung« in Acrobat Reader nicht auf, im Gegensatz zum direkten Export als PDF oder dem Weg über eine eps-Datei.

Damit die Ränder in der PDF-Datei nicht zu schmal werden, darf der Seiteninhalt (die Grafik) höchstens 266mm hoch und 190mm breit sein. Ggf. verkleinert man also im Export-Dialog prozentual bis zu dieser Größe. Die notwendigen Seitenränder zum Ausdruck sind: oben, rechts und links mind. 10mm, unten mind 12mm, besser 21mm wie hier angenommen. Man stellt nun »Centered« ein und verschiebt mit einem positiven »Offset Y« soweit nach oben, dass hier die Mindestränder eingehalten werden. Zum Drucken der Datei mit gv (oder zuerst aus AcrobatReader in eine ps-Datei und dann mit gv) sollte ein positives X-Offset von 0.3cm angegeben werden, um die beim Drucken entstehende Randverschiebung auszugleichen.

Die Symptome sind:

• bei Aufruf im xterm Ausgabe »ERROR: KUniqueApplication: DCOP communication error!«
• gleichzeitig auf der Konsole Ausgabe »DCOP aborting call from ‘anoymous-990′ to ‘kmail’
• nach dem erfolglosen Aufruf funktioniert keine Anwendung mehr richtig. X kann zwar noch mit Strg-Alt-Backspace beendet werden, ein Emergency Sync (Alt-Druck-S) funktioniert jedoch nicht auf allen Platten, Strg-Alt-Entf funktioniert nicht, Einloggen funktioniert nicht. Ein Booten mit Alt-Druck-B führt also stets zu Fehlern aufgrund nicht sauber geunmounteter Platten.
• kmail startet unter anderen Benutzer (root) einwandfrei - es handelt sich also um einen Konfigurationsfehler.

Ansatz: wenn das Kommando »dir ~/Mail/« etwas wie »ls: Yąß?ßđ?^æ??: Datei oder Verzeichnis nicht gefunden« ausgibt, so weiß man, dass irgendwelche Dateileichen / defekten Dateien in diesem Ordner das Starten von kmail verhindern. Lösung:

Dann kopiert man noch die verloren gegangenen Dateien von seinem Backup hinzu, testet kmail und löscht dann den Ordner Mail.orig.

Wenn nach dem Öffnen eines Dokuments hineingezoomt und dann wieder herausgezoom wurde, entsteht dieses Problem. Schließen des Dokuments und erneutes Öffnen behebt das Problem. Eine weitere Möglichkeit zur Behebung ist es, so weit hineinzuzoomen dass das Dokument etwas breiter als das Sichtfenster darauf ist und dann mit der Maus das Dokument mehrmals ganz nach rechts und dann wieder ganz nach links innerhalb des Sichtfensters zu verschieben.

Die Symptome: Netscape startet zwar und lädt die Anfangsseite, das Programm ist aber von Anfang an blockiert: Ein Klick auf die Startseite, um sie zu entfernen, oder ein Klick auf einen Menüeintrag sind die einzigen möglichen Aktionen, danach funktioniert nichts mehr; nach Klick auf einen Menüeintrag bleiben sogar Tastatur- und Mausfokus gefangen, so dass X mit Strg-Alt-Entf beendet werden muss, weil keine anderen Programme mehr gestartet werden können. Dieses Problem besteht unter allen Benutzern (es ist also kein Netscape-Konfigurationsproblem), eine Neuinstallation schafft keine Abhilfe. Andere Browser wie mozilla und konqueror fuktionieren, um Dateien auf dem lokalen System anzuzeigen. Jedoch funktioniert eine Internet-Verbindung über Modem nicht.
Grund: z.B. wenn vorher DSL über Netzwerkkarte genutzt wurde, ist die Defaultroute verstellt; Netscape fordert beim Start stets eine einstellbare Datei an, z.B. file:/home/matthias/Netscape. Im Gegensatz zu anderen Browsern nutzt Netscape auch für das file:/-Protokoll (zumindest zum Laden der eingestellten Startseite) die Default-Route; besteht keine DSL-Verbindung, so versucht Netscape vergeblich, innerhalb des Timeouts (ca. 100s) Daten zu empfangen, ebenso wie andere Browser. Deshalb ist Netscape für diese 100s blockiert. Ein weiteres Symptom ist, dass kppp bei der Einwahl etwa auf stderr ausgibt: kppp[1091]: not replacing default route to eth0 [192.168.1.99]. kppp ersetzt die /etc/resolv.conf-Datei durch eine temporäre eigene (andere Nameserver), jedoch nicht die DefaultRoute, die immer noch über das lokale Netz (eth0-Device) geht.
Lösung: Einfach die PCMCIA-Netzwerkkarte im laufenden Betrieb entfernen. Damit wird keine DefaultRoute für th0 mehr genutzt und Netscape, Internet und e-mail funktionieren wieder tadellos. Sauberer ist es natürlich, den default-Eintrag in /etc/route.conf zu löschen und nur bei Nutzung von DSL mit dem entsprechenden Route-Befehl oder in dieser Datei hinzuzufügen.