Hallo!
Gerhard Brauer schrieb:
Das Tiff-Komprimierungsformat hat aber IMHO nichts mit den Fax-Klassen (Analog, ISDN) zu tun, sondern lediglich wie optimiert das daraus generierte Fax f�r das verwendete Transportmedium und die Gegenstelle ist. Bin mir aber da nicht 100% sicher.
Gut, da bin ich mir auch nicht sicher, ich hatte so verstanden.
Danach funktioniert es bei mir sowohl vom Server, als auch �ber SambaFax einwandfrei (Linux-Clients habe ich keine). W�re interessant ob das nur bei mir funktioniert oder auch bei Euch?!
Ja, diese "harte" Konfiguration funktioniert hier auch mit Linux-Clients.
Das ist sch�n, aber ja leider keine endg�ltige L�sung.
Das gleiche Verhalten kannst du mit sendfax durch die Parameter -1, -2 oder -3 erreichen. -1 entspricht der Verwendung von tiffg3. Siehe auch man sendfax. D.h. mit sendfax -1 funktioniert es auch ohne die Verwendung des globalen Parameters Use2D: no.
Damit ist es f�r mich wenigstens f�r den Moment gel�st - ich hab einfach den -1 Schalter in das sambafax-script eingebaut und konnte die �nderung am ps2fax script damit r�ckg�ngig machen.
Wann von ps2fax welcher Parameter verwendet wird, ist IMHO etwas undurchsichtig. Laut Manpage w�rde er aufgrund des verwendeten Faxdevices (Modem,ISDN-Karte) und das, was die Gegenstelle kann, ermittelt. Letzteres kann sein, es gibt die M�glichkeit ein Log �ber die Gegenstelle zu f�hren. Vor dem Verbindungsaufbau ist das ja nicht m�glich.
Ich hab gerade nochmal mehr zum Thema Modems gelesen und in der hylafax-Doku einen Hinweis �ber sog. Class2Liars gelesen. Dort steht dass das Modem selbst angeben kann ob es tiffg4 unterst�tzt oder nicht. Mir ist allerdings nicht ganz klar, ob hylafax das im Fall von capi4hylafax �berhaupt abfragt bzw. ob es eine Antwort bekommt. (Siehe http://www.hylafax.org/setup-advanced.html#Class2Liars)
Ich hatte zu diesem fehler ja einen Bugreport geschrieben, #296302. Und auch mit dem Maintainer noch einige Tests durchgef�hrt. Dieser Bug wurde dann an capi4hylafax weitergeleitet, da die von hylafax generierten Ausgangsdateien (also das PS und das Tiff) in Ordnung sind. Weiter konnte der Maintainer aufgrund fehlender CAPI-Umgebung nicht testen.
Ich bin dar�ber momentan nicht sehr gl�cklich, weil deine Tests ja jetzt auch gezeigt haben das die Ursache in der ps2fax liegt. Jetzt ist halt nur die Frage wer ruft wann dieses Skript auf und wie wird bestimmt welcher Parameter (-1,-2,-3) f�r die Fax/Tiff-Erstellung verwendet wird. Wenn es dir recht ist, schreibe ich deine Erkenntniss dem Maintainer noch mal, mit dem ich mittlerweile "ganz gut kann". W�re das OK?
Ja logisch, gerne!
Ich sehe das momentan als irgendetwas sehr Verzwicktes an, woraus halt ersichtlich ist das Sarge noch nicht stable ist.
Das stimmt ganz gewiss :-)
a) Modem-Benutzer haben scheinbar dieses Problem nicht. Hei�t das, das bei denen z.B. immer -1 als Parameter an ps2fax mitgegeben wird? Wenn ja, warum?
Ich vermute das kommt daher, dass eben wie oben beschrieben das Modem gefragt wird welche TIFF Formate es unterst�tzt. Und wenn die Modems funktionieren und keine "liars" sind dann wird entweder -3 nicht verwendet oder das Modem unterst�tzt es eben.
b) Wie war das "damals", als es noch funktionierte? Wenn da auch schon per Default mit dem Parameter -3 (tiffg4) gearbeitet wurde, dann konnte scheinbar capi4hylafax das durchaus. Dann w�re die Ursache doch bei capi4hylafax zu suchen. Oder hat sich in ghostscript etwas ge�ndert, das ps2fax veranla�t jetzt die g4-Kompression zu nutzen und dann f�llt capi4hylafax auf die Schnauze.
Der -3 Schalter zum ps2fax script wurde mit Version 1.2 dieser Datei im hylafax-CVS eingef�hrt und das war am 09.02.03 und damit nach dem Release der Version 4.1.3, die in Debian stable verwendet wird (laut hylafax Pressemitteilungen und Dateidatum 29.07.2002). Daher hat es auf jeden Fall mit Debian stable und vermutlich bis einschlie�lich Version 4.1.5 von hylafax funktioniert.
Siehe dazu CVS-Web von hylafax: http://www.hylafax.org/cgi-bin/cvsweb.cgi/util/ps2fax.gs.sh.in?hideattic=1&sortbydate=0#diff http://www.hylafax.org/cgi-bin/cvsweb.cgi/util/ps2fax.gs.sh.in.diff?r1=1.1&r2=1.2&hideattic=1&sortbydate=0&f=h
Und das Source-Release-FTP-Verzeichnis ftp://ftp.hylafax.org/source/
c) Es hat ja (bei mir und ich denke auch bei anderen, die Sarge verwenden) auch funktioniert. Aber es gab sowohl 1-2 hylafax(server, client) updates, IMHO auch f�r capi4hylafax und auch von ghostscript. Und der Zeitraum, ab dem die ersten Probleme auftraten d�rfte so 4-5 Wochen sein.
Das wiederum passt zu meinen Beobachtungen nicht so ganz, Erkl�rungen w�ren:
a) Es werden modem-capabilities von capi4hylafax abgefragt und die sind seit neuestem falsch (es wird angegeben dass tiffg4 unterst�tzt wird, was es laut der LIESMICH.html in der capi4hylafax-Distribution im Abschnitt 4 aber definitiv nicht wird) Allerdings gibt es in den capi4hylafax sourcen keinen Hinweis auf eine capabilities-Abfrage, daher halte ich das f�r unwahrscheinlich.
b) Es wurde etwas in hylafax ge�ndert wodurch nun der Schalter -3 erst seit neuestem verwendet wird. Zum Beispiel ein default nun nicht mehr auf -1 eingestellt ist, wenn es keine capabilities mehr gibt sondern auf -3. Aber das sind nur Spekulationen.
BTW: Wenn jemand, der hylafax+capi auf stable verwendet vielleicht mal testen k�nnte ob ein: sendfax -3 <�bliche Optionen> /etc/motd auch zu dem Fehler (nur Kopfzeile im Fax) wie in Sarge f�hrt.
Den Schalter gibts da vermutlich gar nicht (siehe oben)...
Viele Gr��e,
Markus
--
Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
